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 errshows the errors from the previous boot;systemctl --failedlists the services that did not start;systemd-analyzeshows how long each stage took;systemd-analyze blamesorts services by start-up time;dmesgshows 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;
efibootmgrshows the boot order. - GRUB's configuration is changed in
/etc/default/gruband regenerated, not edited by hand. - The initramfs contains what is needed to mount the root disk, including encryption.
journalctl -b -1,systemctl --failedandsystemd-analyze blameare the first diagnostic tools.