How Does a PC Boot? From Power‑On to the First Linux Kernel Instruction

0x01 Overview

The article uses a panoramic diagram to illustrate every step from powering on a computer to the execution of the first line of Linux kernel code.

0x02 From Power‑On to the Boot Loader

When the machine is turned on, the UEFI firmware embedded on the motherboard starts executing. Firmware (or "firmware") sits between hardware and software and initializes the hardware before handing control to the UEFI boot manager.

The boot manager searches for a UEFI application, which is a PE32+ executable – the same format used by Windows programs. Linux kernels are also compiled as PE32+ so they can be launched directly by UEFI, although in practice a boot loader is inserted for flexibility.

Two mainstream boot loaders are mentioned: GRUB and systemd‑boot . The author prefers systemd‑boot because it is simpler to configure and is bundled with systemd , which is present on most modern Linux distributions.

UEFI stores many persistent variables. One key variable is BootOrder , which holds a list of identifiers such as Boot0004, Boot0003, etc. Each identifier points to another UEFI variable that contains the file path of the executable to launch (e.g., /boot/EFI/systemd/systemd-bootx64.efi).

The boot manager reads BootOrder, iterates through the listed identifiers, and for each uses EFI_BOOT_SERVICES.LoadImage() to load the program into memory and EFI_BOOT_SERVICES.StartImage() to start it. If these calls succeed, control transfers to the loaded program’s entry point.

On a real machine the efibootmgr command can list, add, modify, or delete these UEFI variables, and efivar can inspect or change them directly.

0x03 From the Boot Loader to the Linux Kernel

The chosen boot loader is systemd‑boot , whose source code is publicly available, making its inner workings easier to study. Its UEFI entry point is efi_main.

systemd‑boot performs the following actions:

Loads all .conf files from /boot/loader/entries/, each representing a boot entry.

Reads the global configuration file /boot/loader/loader.conf to determine the default entry (e.g., nixos-generation-292.conf).

Optionally displays a menu for the user to select a different entry.

Loads the initrd specified in the chosen entry into memory and binds it to a fixed EFI device path.

Uses EFI_BOOT_SERVICES.LoadImage() to load the Linux kernel image referenced by the entry.

Copies the kernel command‑line parameters from the entry into the kernel image’s metadata.

Calls EFI_BOOT_SERVICES.StartImage() to start the kernel.

The initrd is a compressed root‑filesystem image that the kernel extracts into an early userspace environment. The first user‑space program (the init program inside the initrd) mounts the real root filesystem and hands control over to the real init process, typically systemd . This two‑stage init design is explained later in the kernel boot sequence.

Because systemd‑boot uses the same EFI LoadImage and StartImage functions as the firmware itself, there is no fundamental difference between booting the kernel directly via UEFI and booting it through systemd‑boot; both ultimately transfer control to the kernel’s EFI entry point.

In summary, systemd‑boot acts as a lightweight UEFI boot manager that loads an initrd, passes kernel parameters, and starts the Linux kernel, while also being capable of launching any other UEFI application.