Linux - Linux Boot Process: From BIOS/UEFI to Kernel Initialization

The Linux boot process is the sequence of steps that takes a computer from the moment it is powered on to a state where the Linux operating system is fully initialized and ready for users and applications. Understanding this process is important for system administrators because many startup problems, such as bootloader failures, missing kernels, filesystem errors, or service failures, can be diagnosed by knowing which stage is responsible.

The boot process generally consists of these major stages:

Power-on and firmware initialization
BIOS or UEFI execution
Bootloader loading
Linux kernel loading
Initial RAM filesystem initialization
Kernel initialization
Starting the first userspace process
Starting system services and reaching the login interface

1. Power-On and Hardware Initialization

When the computer is switched on, the processor does not immediately start Linux. The CPU first begins executing instructions from firmware stored on the motherboard.

The firmware is responsible for performing basic hardware initialization. It detects and prepares components such as:

CPU
RAM
Keyboard
Storage devices
USB devices
Network hardware
Display hardware
Other essential peripherals

The firmware also performs diagnostic checks. In traditional systems, these checks are commonly associated with the Power-On Self-Test (POST).

At this stage, the Linux operating system has not yet been loaded into memory. The firmware's primary responsibility is to prepare the hardware and determine where the computer should continue its startup process.

2. BIOS and UEFI

Two important firmware technologies used during computer startup are BIOS and UEFI.

BIOS

BIOS, or Basic Input/Output System, is the traditional firmware interface used by older computers.

After completing hardware initialization, BIOS searches for a bootable device. This might be a hard disk, SSD, USB drive, or another supported storage device.

On systems using traditional BIOS booting, the firmware typically reads the boot code from the beginning of the selected disk. This area contains the Master Boot Record (MBR), which contains information needed to begin loading the bootloader.

BIOS-based booting has several historical limitations, including restrictions associated with traditional partitioning and older firmware interfaces.

UEFI

UEFI, or Unified Extensible Firmware Interface, is the modern replacement for traditional BIOS.

UEFI provides a more sophisticated boot environment and supports features such as:

GPT partitioning
Larger boot disks
Faster startup
Firmware-level applications
Secure Boot
Boot manager entries stored in firmware

Instead of depending on boot code stored in an MBR in the same way as traditional BIOS systems, UEFI can directly locate an executable bootloader file in the EFI System Partition (ESP).

The EFI System Partition is normally formatted with a FAT-based filesystem and contains boot-related files.

For example, a Linux installation might contain a bootloader file under a path similar to:

/EFI/<distribution>/

The exact directory structure depends on the Linux distribution and bootloader configuration.

3. Bootloader Stage

After firmware completes its work, control is transferred to a bootloader.

One of the most widely used Linux bootloaders is GRUB, the GRand Unified Bootloader.

The bootloader has several important responsibilities. It can:

Display available operating systems
Display different Linux kernel versions
Allow the user to select a boot option
Pass parameters to the Linux kernel
Locate the Linux kernel
Locate the initial RAM filesystem
Load these components into memory
Transfer control to the kernel

A typical GRUB menu might provide options such as:

Linux
Advanced options for Linux

The advanced options may contain multiple installed kernel versions.

This is particularly useful when a newly installed kernel has a problem. An administrator may be able to select an older kernel and boot the system successfully.

4. Loading the Linux Kernel

Once the bootloader has determined which Linux kernel should be started, it loads the kernel into memory.

The Linux kernel is the central component of the operating system. It manages and coordinates hardware and provides essential services to userspace programs.

The kernel is responsible for areas such as:

CPU scheduling
Memory management
Device management
Process management
Networking
Filesystem support
Security mechanisms
System calls

The kernel image is commonly stored in the /boot directory.

A typical Linux system may contain files resembling:

/boot/vmlinuz-6.x.x

The exact filename and version depend on the Linux distribution and installed kernel.

The bootloader also supplies kernel parameters, which influence how the kernel starts.

For example:

root=/dev/sda2
ro
quiet

The root= parameter tells the kernel where the root filesystem can be found.

Kernel parameters are particularly useful for troubleshooting because administrators can modify them temporarily from the bootloader menu.

5. The Initial RAM Filesystem

A Linux kernel cannot always access everything it needs immediately after being loaded.

For example, the root filesystem might be located on:

An encrypted disk
RAID storage
Logical volumes
Network storage
A filesystem requiring additional drivers

To solve this problem, Linux commonly uses an initial RAM filesystem, often called initramfs.

The initramfs is a temporary filesystem loaded into RAM during early boot.

It contains tools, scripts, and kernel modules needed to prepare the actual root filesystem.

For example, it may provide support for:

Storage controllers
Filesystem drivers
RAID
LVM
Disk encryption
Hardware discovery
Root filesystem identification

The basic sequence is:

Firmware
   |
Bootloader
   |
Linux Kernel + initramfs
   |
Prepare real root filesystem
   |
Switch to real root filesystem

The initramfs is therefore an important bridge between the kernel being loaded and the actual Linux installation becoming available.

6. Kernel Initialization

After the bootloader transfers control to the kernel, the kernel begins its own initialization process.

The kernel first establishes the fundamental operating environment.

It initializes important subsystems such as:

CPU management
Memory management
Interrupt handling
Device drivers
Networking components
Storage subsystems
Filesystem support
Kernel threads

The kernel also detects hardware and loads the necessary drivers.

During this phase, information about the detected hardware and initialization activities can be viewed through kernel logging mechanisms.

For example:

dmesg

The dmesg command can display messages generated by the kernel, making it useful when investigating hardware and early boot problems.

7. Mounting the Root Filesystem

One of the most important tasks during early kernel initialization is making the root filesystem available.

Linux needs a root filesystem because it contains the directory hierarchy required for the operating system to function.

The root filesystem is represented by:

It contains important directories such as:

/etc
/bin
/usr
/var
/home
/dev
/proc
/sys

The exact arrangement can vary between distributions and filesystem configurations.

The initramfs helps locate and prepare the root filesystem. Once it is ready, the system transitions from the temporary environment in RAM to the actual root filesystem on the storage device.

This transition is sometimes referred to as switching root.

8. Starting the First Userspace Process

After the kernel has initialized sufficiently and the real root filesystem is available, Linux needs to start a userspace process.

This process traditionally has a process ID of:

PID 1

On many modern Linux distributions, PID 1 is managed by systemd.

You can check the process with:

ps -p 1 -f

A typical system may show something similar to:

UID    PID  PPID  CMD
root     1     0  /sbin/init

On a system using systemd, /sbin/init generally points to the systemd executable or is provided through a compatible interface.

PID 1 is extremely important because it becomes the parent or ancestor of many processes and is responsible for bringing the userspace environment into its required operating state.

9. Systemd and Service Initialization

Modern Linux distributions commonly use systemd to manage the remainder of the boot process.

Systemd starts and manages services according to dependencies and configured targets.

Examples of services that may be started include:

Networking
Logging
SSH
Time synchronization
Database services
Web servers
Desktop services
Scheduled-task services

You can inspect the system's current boot target using:

systemctl get-default

Common targets include:

multi-user.target
graphical.target

A system configured for a graphical desktop generally reaches a graphical target, while a server may commonly operate at a multi-user target without a graphical desktop.

10. Login Interface

Once the necessary system services have been initialized, the computer becomes available for normal use.

On a server, users may receive a text-based login prompt or connect remotely through SSH.

On a desktop installation, a graphical display manager may provide the login screen.

The overall sequence can therefore be represented as:

Power On
   |
BIOS / UEFI
   |
Bootloader
   |
Linux Kernel
   |
initramfs
   |
Kernel Initialization
   |
Mount Root Filesystem
   |
PID 1 / systemd
   |
System Services
   |
Login Interface
   |
User Applications

BIOS Boot vs UEFI Boot

The most important distinction between traditional BIOS and modern UEFI booting is how firmware interacts with the bootloader.

Feature	BIOS	UEFI
Technology	Older firmware interface	Modern firmware interface
Common partition style	MBR	GPT
Boot mechanism	Boot code from disk	EFI executable from ESP
Secure Boot	Not normally available	Supported
Boot environment	Limited	More capable
Large-disk support	More limited with traditional MBR	Better support through GPT

UEFI does not necessarily mean that GRUB is absent. A Linux system using UEFI can still use GRUB; the difference is how the firmware locates and launches the bootloader.

Understanding the Boot Process Through Logs

When Linux fails to boot, understanding these stages helps identify where the problem occurred.

For example, if the computer cannot find a bootable device, the problem may occur before Linux starts.

If GRUB appears but the kernel cannot be loaded, the problem may involve the bootloader configuration or kernel files.

If the kernel starts but cannot find the root filesystem, the issue may involve storage drivers, filesystem configuration, LVM, RAID, encryption, or initramfs configuration.

If the kernel starts successfully but a service fails, the problem is likely later in the userspace initialization stage.

Useful commands for investigating an already running system include:

dmesg

journalctl -b

systemctl status

journalctl -p err -b

The journalctl -b command is particularly useful because it can display messages associated with the current boot.

Why Understanding the Boot Process Matters

Linux administrators need to understand the boot process because startup problems can occur at several independent stages.

For example, a damaged bootloader configuration is fundamentally different from a missing kernel, and a missing storage driver is different from a failed system service.

By separating the process into firmware, bootloader, kernel, initramfs, root filesystem, PID 1, and services, troubleshooting becomes much more systematic.

A useful troubleshooting approach is therefore to ask:

Did the firmware start?
        |
Did the bootloader start?
        |
Did the kernel load?
        |
Did initramfs initialize?
        |
Was the root filesystem found?
        |
Did PID 1 start?
        |
Did required services start?
        |
Did the login interface become available?

This sequence provides a practical framework for diagnosing Linux startup failures without treating the entire boot process as a single problem.