4.2 The Linux Boot Process

Table of Contents

Overview of the Linux Boot Process

The Linux boot process is the sequence of steps that transforms a powered‑off machine into a running Linux system with user logins, services, and applications. Understanding this sequence helps you troubleshoot boot problems, tune performance, and customize behavior.

At a high level, the process is:

Firmware initialization (BIOS or UEFI)
Bootloader starts (commonly GRUB2)
Kernel is loaded, along with initramfs
Kernel initializes hardware and mounts the root filesystem
The first userspace process (typically systemd) starts and brings up services and user sessions

Later chapters will go deeper into BIOS vs UEFI, GRUB2, kernel loading, initramfs, and troubleshooting. This chapter focuses on how these pieces fit together as an end‑to‑end flow.

High-Level Sequence

From power‑on to login prompt, a typical Linux system goes through:

Power‑on and firmware self-test

CPU resets to a fixed address.
Firmware (BIOS or UEFI) performs basic hardware checks.
Firmware discovers bootable devices and applies its configured boot order.

Boot device selection

Firmware selects a disk/network device to boot from.
Control is passed to the boot code on that device.

Bootloader phase

Bootloader (e.g., GRUB2) is loaded from disk.
Bootloader presents a menu and loads the selected kernel + initramfs into memory.
Bootloader passes parameters to the kernel and jumps to it.

Kernel initialization

Kernel sets up memory management, CPU scheduling, basic device drivers, kernel subsystems, and logging.
Kernel unpacks and runs initramfs to locate and mount the real root filesystem.

First userspace process

Kernel starts PID 1 (usually systemd; sometimes init, upstart, or another init system if configured).
PID 1 starts services, mounts remaining filesystems, configures networking, and finally spawns logins and graphical sessions.

User login and normal operation

Gettys (text logins) or display managers (graphical logins) start.
Users log in and launch applications on top of the now‑running system.

Each of these phases has its own logs, error messages, and configuration knobs.

Firmware Stage: BIOS/UEFI to Bootloader

Firmware is the very first code that runs. It:

Initializes minimal hardware required to continue booting:

CPU mode (16‑bit/32‑bit/64‑bit depending on platform)
Basic memory controller initialization
Keyboard and simple display output

Implements configuration menus for:

Boot order
Secure Boot (on UEFI systems)
Hardware options (SATA mode, virtualization extensions, etc.)

Searches for a bootable device using the configured order:

Internal disks
USB
Network (PXE)
Optical drives

Depending on whether the system uses BIOS or UEFI, the exact mechanisms differ (covered in detail in the BIOS vs UEFI chapter), but the result is similar: firmware loads the bootloader from a specific place on the chosen device and passes control to it.

Bootloader Stage: GRUB2 and Friends

The bootloader bridges firmware and the Linux kernel. Its main roles:

Understand the disk layout and filesystems well enough to:

Find its configuration file (e.g. /boot/grub/grub.cfg)
Locate kernel and initramfs images (usually under /boot)

Present a menu of boot entries:

Normal boot
Recovery/rescue modes
Alternative kernels

Load:

The selected kernel image (e.g. /boot/vmlinuz-…) into memory
The corresponding initramfs image (e.g. /boot/initramfs-… or /boot/initrd.img-…)

Pass kernel command-line parameters

Root filesystem location (root= parameter)
Console settings
Debugging and boot modes
Parameters controlling specific drivers or features

When you select an entry (or the default auto‑boots), the bootloader sets up the appropriate CPU mode and jumps into the kernel entry point.

Kernel Initialization

Once the bootloader transfers control to the kernel:

Early kernel setup

Switch to the correct CPU mode (if needed).
Initialize early memory management (page tables).
Set up very basic I/O and logging (e.g., early console for messages).
Parse the kernel command line:

root=, ro/rw (read‑only/read‑write root filesystem)
init= (custom PID 1)
Various debugging options (e.g. debug, systemd.log_level=debug)

Driver and subsystem initialization

Initialize core kernel subsystems:

Process scheduler
Virtual memory
Filesystems
Networking (core)

Load built‑in drivers for essential hardware:

Storage controllers (SATA, NVMe, SCSI)
Bus systems (PCI, USB)
Basic input devices

Start emitting kernel log messages, usually visible later via tools like dmesg or journalctl -k.

Handing off to initramfs

Kernel unpacks the initramfs image into a tmpfs (in‑memory filesystem).
Root changes to that temporary filesystem.
The init program inside initramfs (often a small shell script or an init binary) is executed.

This early phase is short but critical: if essential drivers or root filesystem discovery fail here, the system cannot continue to boot properly.

initramfs: Early Userspace

initramfs (also called an initrd in older setups, though technically different) is a minimal userspace used before your real root filesystem is mounted. It exists to handle tasks that are easier in userspace than in the kernel, such as:

Discovering complex storage configurations:

RAID (mdadm)
LVM
Encrypted partitions (LUKS)

Loading additional kernel modules required to reach the root filesystem
Detecting and activating root filesystems on:

USB or other removable media
Network filesystems (for diskless systems)
SAN devices

Handling root filesystem decryption prompts (passphrase input)
Applying early udev rules to name devices consistently

Typical steps in initramfs:

Start a minimal userspace init process in RAM.
Probe hardware and load extra modules using tools like udev.
Bring up enough storage/networking to locate the real root filesystem (as specified by root= or other configuration).
Check or repair the filesystem if configured (e.g. via fsck).
Mount the real root filesystem, usually at /new_root or similar.
Perform a pivot or switch root:

Move from the RAM‑based root to the real on‑disk root.
Replace the temporary init with the real init system (e.g., systemd).

If initramfs cannot find or mount the real root filesystem, it may:

Drop you into an emergency shell (often a busybox shell) for manual rescue.
Reboot, depending on configuration and failure type.

Root Filesystem and PID 1

Once the real root filesystem is mounted and switch_root (or an equivalent) has run, the system transitions into its normal foundation:

Root filesystem (e.g. / on ext4, XFS, Btrfs) is now active.
/sbin/init (or the binary specified by init= on the kernel command line) is executed as PID 1.

On most modern distributions, /sbin/init is symlinked to systemd, so PID 1 is actually the systemd process. Alternatives like sysvinit, OpenRC, or runit can also act as PID 1 on some systems, but the role is always the same: orchestrate the rest of userspace.

Responsibilities of PID 1

PID 1 is special:

It never exits under normal circumstances. If PID 1 dies, the kernel panics or reboots.
It reaps orphaned child processes.
It is responsible for:

Running startup tasks
Spawning login processes
Bringing up and managing critical services

The details of service management are covered elsewhere (e.g. in the systemd and service management chapter). Here, focus on how boot flows into PID 1’s startup logic.

Userspace Initialization (systemd Perspective)

On a systemd system, once PID 1 starts:

Read configuration

Parse unit files from standard directories, such as:

/usr/lib/systemd/system
/etc/systemd/system

Determine the default boot target (similar to old “runlevels”), e.g.:

multi-user.target (multiuser, non-graphical)
graphical.target (multiuser with graphical interface)
rescue.target (single-user mode)

Mount remaining filesystems

Mount entries from /etc/fstab that weren’t handled in early boot:

Separate /home, /var, /boot, etc.

Mount swap devices.
Bring up network filesystems, if configured (e.g. NFS).

Start essential system services

Logging (e.g. systemd-journald)
Device management (systemd-udevd)
Time synchronization (e.g. systemd-timesyncd or chronyd)
Network management (e.g. NetworkManager, systemd-networkd)
DBus message bus.

Reach the default target

Start all services that are dependencies of the default target.
Activate sockets, timers, and other units required at boot.

Start login interfaces

For text consoles:

Spawn agetty processes on TTYs, leading to login prompts like:

tty1, tty2, ...

For graphical interfaces:

Start a display manager (e.g. gdm, sddm, lightdm).
Display a graphical login screen.

Once the target is reached, you get a login prompt or display manager screen. From that point on, the system is in its steady state, handling logins, user processes, and services under normal operation.

Boot Modes and Targets

Different boot modes correspond to different sets of services and targets. Some commonly relevant modes:

Normal multi-user boot

Full networking and standard services.
Depending on configuration, either console or graphical login.

Rescue/single-user mode

Minimal set of services.
Often used for maintenance, repairs, and password resets.
Initiated by:

Choosing a “rescue” entry in the bootloader.
Adding parameters like systemd.unit=rescue.target or single to the kernel command line.

Emergency mode

Even more minimal than rescue.
Often only a root shell on the console with almost no services.
Used when essential resources (like the root filesystem) can’t be correctly mounted.
Typically triggered automatically on severe boot failures or manually via systemd.unit=emergency.target.

These modes are invaluable when troubleshooting boot issues, especially filesystem or configuration problems.

Boot Logs and Diagnostics

Understanding the boot sequence also means knowing where to look when it fails or slows down.

Kernel and early boot messages

Kernel emits messages from very early in boot:

Viewable with dmesg on a running system.
Logged via systemd-journald (e.g. journalctl -k).

initramfs scripts often log to the console:

If boot fails here, you might see messages like:

“Unable to find root device”
“Failed to mount /sysroot”

Some distributions offer an emergency shell in initramfs for manual investigation.

systemd boot analysis

On systemd systems, you can inspect boot performance and ordering using:

systemd-analyze:

Summaries of kernel vs userspace time.

systemd-analyze blame:

Lists services ordered by startup time.

journalctl -b:

Shows logs from the current boot only.

journalctl -b -1:

Shows logs from the previous boot.

If boot fails after PID 1 starts, you can often reboot into a rescue or emergency mode and inspect these logs.

Summary Flow

To recap in a concise chain:

Firmware (BIOS/UEFI) initializes hardware and selects a boot device.
Bootloader (e.g., GRUB2) loads the selected kernel and initramfs and passes them parameters.
Kernel initializes core subsystems and unpacks initramfs.
initramfs runs minimal userspace to:

Detect hardware.
Assemble storage (RAID/LVM).
Decrypt disks.
Mount the real root filesystem.

Switch to real root and execute PID 1 (/sbin/init, usually systemd).
PID 1:

Mounts additional filesystems.
Starts system services.
Brings the system to the configured boot target.
Spawns login prompts (text or graphical).

Understanding this sequence provides the foundation for the more detailed topics in the following chapters: BIOS vs UEFI, GRUB2, kernel loading and initramfs, and troubleshooting the boot process.

4.2.1 BIOS vs UEFI

4.2.2 Understanding GRUB2

4.2.3 Kernel loading

4.2.4 initramfs

4.2.5 Troubleshooting boot issues