>_ Operating systems & Linux

How Linux boots: UEFI, GRUB, kernel, initramfs and systemd

The stages of a Linux boot explained in order: UEFI firmware, EFI partition, GRUB, kernel, initramfs and systemd, plus commands for troubleshooting.

Only a few seconds pass between pressing the power button and seeing the login screen, but in that time at least five distinct stages follow one another, each handled by a different component. When a computer won't start, knowing which stage it got stuck in is half the solution: a firmware error is tackled in a completely different way from a service that fails to start.

Stage 1: the UEFI firmware

At power-on the processor runs the motherboard firmware. On computers built in recent years it is almost always UEFI, which replaced the old BIOS. The firmware checks the basic hardware, then consults a list of boot entries stored in the motherboard's memory and looks for the program to load.

With UEFI this program lives in the EFI system partition (ESP), a small FAT32-formatted partition, usually mounted on Linux at /boot/efi. It holds the bootloaders of every installed system, each in its own folder, for example EFI/ubuntu/ or EFI/Microsoft/. The efibootmgr command lists the boot entries registered in the firmware and their order.

If Secure Boot is enabled, the firmware only starts programs signed with recognised keys. The major distributions use a small signed intermediate program called shim, which in turn verifies GRUB and the kernel.

Stage 2: the bootloader

The bootloader's job is to load the kernel into memory. The most common is GRUB; some distributions use the simpler systemd-boot. GRUB shows the menu from which you choose the system or an older kernel version, and reads its configuration from /boot/grub/grub.cfg, an automatically generated file: changes belong in /etc/default/grub and are then applied with update-grub on Debian and Ubuntu or grub2-mkconfig on Fedora.

From the GRUB menu, pressing e on an entry lets you edit the kernel parameters for that boot only. It is a valuable diagnostic tool: for example, removing quiet splash shows the boot messages instead of the logo.

Stage 3: the kernel

The kernel decompresses itself, initialises memory, processors and device management, and loads the essential drivers. At this point, however, it has a problem: to mount the disk holding the system it might need a driver that sits on that very disk, or the disk might be encrypted or part of a RAID array.

Stage 4: the initramfs

The solution is the initramfs, a small compressed filesystem loaded into memory by the bootloader together with the kernel. It contains the minimal modules and tools needed to find and mount the root filesystem: controller drivers and support for LVM, RAID and LUKS encryption. This is where, with an encrypted disk, the passphrase prompt appears.

Once the root filesystem is mounted, the initramfs hands control over to the real system. If the initramfs is damaged or lacks the right driver, you end up in an emergency shell with messages such as «unable to mount root fs». It is regenerated with update-initramfs -u on Debian and Ubuntu or with dracut on Fedora.

Stage 5: systemd

The kernel starts the first process, with PID 1, which on most distributions is systemd. From here all services start in parallel: mounting the disks listed in /etc/fstab, networking, the system log, the graphical login manager. systemd groups services into targets, sets that represent a state of the system:

Target State
multi-user.target full system without a graphical interface
graphical.target full system with desktop
rescue.target recovery mode with minimal services
emergency.target emergency shell, almost nothing started

Adding systemd.unit=rescue.target to the kernel parameters from GRUB boots straight into recovery mode: useful when a service is blocking the normal boot.

Troubleshooting a problematic boot

A few indispensable commands, to use once the system is reachable again:

  • journalctl -b -1 -p err shows the errors from the previous boot;
  • systemctl --failed lists the services that did not start;
  • systemd-analyze shows how long each stage took;
  • systemd-analyze blame sorts services by start-up time;
  • dmesg shows kernel messages, including device errors.

A very common cause of a stuck boot is a line in /etc/fstab referring to a disk that is no longer present. The nofail option on lines for external or secondary disks prevents their absence from halting the boot.

Working out where it stopped

Symptom Likely stage
no manufacturer logo, black screen firmware or hardware
«no bootable device» firmware cannot find the ESP or the boot entry
grub> or grub rescue> prompt bootloader without configuration or missing files
kernel panic kernel or initramfs
emergency shell with a mount error initramfs or /etc/fstab
slow boot or stuck on a service systemd

In short

  • Booting goes through UEFI firmware, bootloader, kernel, initramfs and systemd.
  • Bootloaders live in the EFI partition; efibootmgr shows the boot order.
  • GRUB's configuration is changed in /etc/default/grub and regenerated, not edited by hand.
  • The initramfs contains what is needed to mount the root disk, including encryption.
  • journalctl -b -1, systemctl --failed and systemd-analyze blame are the first diagnostic tools.
MM
Marco Marzaduri

Marco Marzaduri works in cybersecurity, digital forensics and web development. With degrees in computer science and psychology, he combines technical analysis with an understanding of the human factor.

Read also