The boot process
Between pressing the power button and seeing a login prompt, a chain of programs hands control from firmware to boot loader to kernel to the first user process.
Firmware: BIOS and UEFI
When a computer powers on, the CPU runs firmware stored on the motherboard. Older PCs used BIOS, which performed a power-on self-test and loaded the first 512-byte sector (the master boot record) of a disk. Modern machines use UEFI, which understands partition tables and file systems, reads boot loaders from an EFI system partition, and supports Secure Boot, which checks that boot software is signed.
Partitions
Disks are divided into partitions described by a partition table. The older MBR scheme supports up to four primary partitions and disks up to 2 TiB with 512-byte sectors; GPT, used with UEFI, supports very large disks and up to 128 partitions by default. A typical Linux install has an EFI system partition, a root partition, and perhaps separate home or swap partitions.
The boot loader
The boot loader, usually GRUB 2 on PCs (systemd-boot is an alternative), presents a menu of kernels or operating systems, loads the chosen kernel image (vmlinuz) and an initial RAM filesystem (initramfs) into memory, and passes the kernel command-line parameters, such as which partition is the root file system.
Kernel initialisation
The kernel decompresses itself, initialises memory management, detects CPUs, sets up interrupts and timers, and initialises built-in drivers. It mounts the initramfs, a small temporary root file system containing tools and modules needed to find and mount the real root, which may require storage drivers, RAID, encryption, or network access. Kernel messages from this stage can be read later with dmesg.
Switching to the real root
Programs in the initramfs load the necessary modules, unlock encrypted volumes if needed, and mount the real root file system. Control then passes to the real root, and the kernel starts the first user-space process, with process ID 1, normally /sbin/init.
PID 1 and systemd
PID 1 is the ancestor of all user processes and is responsible for starting services and adopting orphaned processes. On most modern distributions PID 1 is systemd, first released in 2010, which starts services in parallel based on declared dependencies and brings the system to a target, such as multi-user.target for servers or graphical.target for desktops. Older systems used SysV init scripts and runlevels.
Shutting down and recovery
Shutting down reverses the process: systemd stops services, unmounts file systems, and asks the kernel to power off or reboot. If boot fails, you can edit the kernel command line in GRUB, for example adding systemd.unit=rescue.target to boot into a minimal rescue environment, or boot from a live USB to repair the installed system.
Worked example
A server will not finish booting after a disk was replaced. The GRUB menu appears, so firmware and boot loader work. The kernel starts, but the console shows the initramfs waiting for a root device by UUID. The new disk's file system has a different UUID, so the kernel command line, or /etc/fstab, still refers to the old one. Booting a rescue system, checking UUIDs with blkid, and updating the configuration fixes it.
Key takeaways
Firmware starts the boot: BIOS loads the master boot record; UEFI loads boot loaders from the EFI system partition and supports Secure Boot. MBR partition tables have tight limits; GPT supports large disks and many partitions. GRUB 2 loads the kernel (vmlinuz), the initramfs, and command-line parameters. The kernel initialises hardware, uses the initramfs to find and mount the real root, then starts PID 1. systemd (2010) is PID 1 on most distributions, starting services in parallel to reach targets such as multi-user.target. Rescue targets and live USBs aid recovery.
Flashcard
Legacy PC firmware
Check your understanding
What is the main job of the initramfs during boot?