Linux Boot Process: BIOS and UEFI Explained

The Linux boot process begins the moment a computer is powered on, transitioning control through a tightly orchestrated sequence from low-level motherboard firmware to the Linux kernel. This guide explains how firmware—either legacy BIOS or modern UEFI—initializes hardware components, locates the storage device, and executes the primary bootloader (typically GRUB) to load Linux into system memory.

1. Power-On and Hardware Initialization (POST)

When you press the power button, the computer's power supply stabilizes and signals the CPU to begin executing instructions. The CPU looks at a hardcoded memory address mapped to the motherboard's non-volatile ROM/flash memory, where the system firmware resides.

The firmware immediately runs the Power-On Self-Test (POST). During POST, the firmware checks vital hardware components, including the CPU, system RAM, storage drives, graphics adapters, and peripheral interfaces. If a critical component fails, the process halts, often signaling the error via motherboard diagnostic LEDs or a series of audible beeps.

2. Locating the Boot Media

Once POST succeeds, the firmware determines where to boot from by consulting a preconfigured boot device priority list (e.g., NVMe drive, SATA SSD, USB drive, network). How the system loads the bootloader from the selected drive depends on whether the system uses legacy BIOS or UEFI.

Legacy BIOS: The MBR Approach

1. Master Boot Record (MBR): The BIOS accesses the first 512-byte sector of the designated storage drive, known as the MBR.
2. Size Limitation: Because 512 bytes is too small to contain file system drivers and complex boot logic, this sector only holds the partition table and a tiny stage-1 bootloader code (such as GRUB's boot.img).
3. Execution Handoff: The BIOS copies this 512-byte payload into RAM at address 0x7C00 and transfers execution to it. This initial code then loads intermediate stages (like core.img) from the gap between the MBR and the first partition to eventually locate the full bootloader configuration.

Modern UEFI: The EFI System Partition (ESP)

1. NVRAM Boot Entries: Modern systems use UEFI (Unified Extensible Firmware Interface), which does not rely on boot sectors. Instead, UEFI maintains boot entries stored in motherboard NVRAM pointing directly to executable files.
2. EFI System Partition (ESP): UEFI reads storage drives partitioned with the GPT (GUID Partition Table) format and looks for a dedicated FAT32 partition known as the ESP.
3. Direct Execution: UEFI contains its own basic filesystem drivers. It directly executes 64-bit EFI binaries, such as /EFI/ubuntu/grubx64.efi or /EFI/systemd/systemd-bootx64.efi, bypassing the sector-based limitations of BIOS entirely. If Secure Boot is enabled, UEFI also cryptographically verifies the signature of the EFI binary before running it.

3. Executing the Bootloader (GRUB)

Regardless of the initialization path taken, control lands on the Linux bootloader, most commonly GRUB 2 (GRand Unified Bootloader).

• Configuration Loading: GRUB reads its configuration file (typically located at /boot/grub/grub.cfg).
• User Interface: If configured, GRUB displays an interactive menu allowing the user to select kernel versions or recovery modes.
• Loading Assets: Once an entry is selected, GRUB loads two essential files into RAM:
  1. The Kernel (vmlinuz): The compressed, executable Linux kernel binary.
  2. The Initial RAM Disk (initramfs or initrd): A temporary root filesystem containing minimal user-space utilities and kernel modules (such as device drivers for storage controllers and complex filesystems like LVM or LUKS) needed to mount the real root filesystem.

4. Transfer of Control to the Linux Kernel

With the kernel and initramfs loaded into memory, GRUB sets up the kernel execution parameters (passed as boot flags such as root=/dev/nvme0n1p2 ro quiet splash). Finally, the bootloader terminates its own execution and jumps directly to the entry point of the Linux kernel.

The Linux kernel takes exclusive control of the processor, uncompresses itself, initializes internal subsystems, mounts the initramfs, and ultimately launches the first user-space process (systemd or /sbin/init), completing the handover from firmware to the operating system.