In the first part of our series, we established a four-stage framework for understanding any boot process. Now, we apply that model to the modern x86-64 PC and server, a world that has been reshaped by the move from the legacy BIOS to the Unified Extensible Firmware Interface (UEFI). This shift has driven a clear trend towards simpler, more secure, and more atomic boot processes.
From BIOS to a Filesystem-Aware Firmware
The legacy BIOS was a simple piece of firmware. After its Power-On Self-Test (POST), its only job was to read the first 512 bytes of a disk—the Master Boot Record (MBR)—and execute whatever code it found there. This tiny space forced a complex chain of loaders just to get to the point where a bootloader like GRUB could understand a filesystem.
UEFI is fundamentally different. It is a miniature operating system with its own drivers, shell, and, most importantly, the built-in ability to read standardized filesystems like FAT32. This capability led to the creation of the EFI System Partition (ESP), a dedicated FAT-formatted partition that acts as a universal, OS-agnostic hub for boot files. A bootloader is no longer a piece of code in a boot sector; it’s a standard executable file (e.g., grubx64.efi) that the firmware can find and run directly from the ESP.
Bypassing the Bootloader: EFI Stub and Unified Kernel Images (UKIs)
The power of UEFI opens the door to even simpler boot methods that can bypass a traditional bootloader entirely.
- Direct Kernel Execution (EFI Stub): The Linux kernel can be compiled with a feature called the “EFI stub” (CONFIG_EFI_STUB=y). This embeds a small UEFI-compliant program into the kernel binary itself, allowing the UEFI firmware to execute the kernel directly. Using the efibootmgr tool from a running system, an administrator can create an entry in the firmware’s NVRAM that points directly to the kernel file on the ESP, completely bypassing GRUB. However, this method can be fragile, as some firmware implementations have bugs that prevent them from correctly passing necessary command-line arguments to the kernel
- Unified Kernel Images (UKIs): The UKI is the modern solution to these challenges. A UKI is a single, self-contained UEFI application that bundles all necessary boot components—the EFI stub, the Linux kernel, the initramfs, and the kernel command line—into one file. This atomic approach offers three key advantages:
- Atomicity: The kernel and its critical dependencies are updated as a single unit.
- Robustness: Embedding the command line directly into the file bypasses firmware bugs related to passing arguments.
- Security: The entire UKI file can be cryptographically signed. UEFI Secure Boot then verifies this single signature, closing a major security hole where an attacker could modify an unsigned initramfs without being detected.
The nmbl Project: The Bootloader-less Philosophy in Practice
The nmbl (“no more bootloader”) project, championed by Marta Lewandowska, is a practical initiative to make the UKI-based, bootloader-less paradigm the default for mainstream distributions like Fedora. The project argues that traditional bootloaders like GRUB add unnecessary complexity, duplicate functionality already in the kernel (like filesystem drivers), and represent a significant and less-scrutinized attack surface. By replacing GRUB with a directly bootable UKI, nmbl aims to deliver a faster, more secure, and more maintainable boot process that leverages the robust and rapidly evolving Linux kernel as the bootloader itself.
The streamlined, secure, and atomic boot process of the modern PC stands in stark contrast to the resource-constrained world of embedded systems. In our next article, we’ll explore the multi-stage boot process of ARM and RISC-V devices.
