1.2. How Linux Boots: From Power-On to Shell

💡 First Principle: The Linux boot process is a strict handoff chain — each component initializes the next. Understanding where each stage starts and stops tells you exactly where to look when a system won't boot.

Most boot failures happen at one of three predictable points: the bootloader can't find the kernel, the kernel can't initialize hardware, or the init system can't start services. Knowing the sequence means you diagnose at the right layer instead of guessing.

Understanding the boot sequence matters when things go wrong: a failed initramfs, a corrupted GRUB config, or a systemd unit in a dependency loop can all prevent boot. Knowing the handoff chain tells you exactly where to intervene.

⚠️ Common Misconception: GRUB and the kernel are the same thing. GRUB is the bootloader — its only job is to find and load the kernel. The kernel is the OS itself. Editing /boot/grub/grub.cfg changes what gets loaded; it doesn't change the kernel.

Without understanding the boot sequence, a server that won't boot is a black box. Knowing that GRUB → kernel → initramfs → systemd is a strict handoff chain tells you exactly which layer to investigate: no GRUB menu means firmware/disk issue; kernel panic means hardware or initramfs; systemd hang means a unit dependency problem.

Stage 1: Firmware (BIOS or UEFI)

When you press the power button, firmware runs first. The older BIOS standard reads the first 512 bytes of the boot disk (the Master Boot Record, or MBR) to find stage-1 bootloader code. Modern systems use UEFI, which reads from a dedicated EFI System Partition (ESP) formatted as FAT32 and can directly execute EFI binaries — GRUB is delivered as an EFI binary in this case.

UEFI also enables Secure Boot, which cryptographically verifies each component in the chain before executing it. Secure Boot is increasingly relevant for the XK0-006 Security domain and appears in OS hardening scenarios.

Stage 2: GRUB2 (Grand Unified Bootloader)

GRUB2 is the most common bootloader on modern Linux systems. Its job is to load the kernel binary and the initial RAM disk, then pass control. Key GRUB concepts for the exam:

• Configuration file: /boot/grub2/grub.cfg (RHEL) or /boot/grub/grub.cfg (Debian) — auto-generated; edit /etc/default/grub and run grub2-mkconfig or update-grub to regenerate
• Kernel parameters: appended at the boot line — quiet, splash, ro, root=/dev/sda1, init=/bin/bash (for recovery)
• GRUB rescue prompt: appears when GRUB can't find its config or the kernel; ls, set, and insmod are available to manually boot

# Typical GRUB kernel line in grub.cfg
linux   /boot/vmlinuz-6.1.0 root=/dev/sda1 ro quiet splash
initrd  /boot/initramfs-6.1.0.img

Stage 3: Kernel Initialization

Once GRUB hands off, the kernel decompresses itself, detects and initializes hardware, and sets up virtual memory. The kernel then mounts the initrd (initial RAM disk) — a compressed filesystem image loaded into RAM that contains the minimum drivers and tools needed to mount the real root filesystem.

This two-stage mounting approach exists because the real root filesystem might be on a RAID array, an encrypted LUKS volume, or an iSCSI disk — and those require drivers that the kernel alone may not have loaded. The initrd bridges that gap.

• initramfs vs. initrd: Modern systems use initramfs (a cpio archive), while older systems used an initrd (an ext2 image). The terms are often used interchangeably.
• Rebuilding initramfs: dracut (RHEL/Fedora) or mkinitrd — needed after installing new drivers or changing storage configuration

Stage 4: systemd (PID 1)

After switching to the real root filesystem, the kernel executes /sbin/init — on modern systems, this is a symlink to systemd. systemd becomes Process ID 1 (PID 1), the ancestor of every other process on the system. Its key responsibilities:

• Activating systemd units in dependency order (services, mounts, sockets)
• Mounting filesystems from /etc/fstab
• Reaching the correct target (equivalent to runlevel): multi-user.target for text-mode servers, graphical.target for desktop systems

systemd-analyze          # Total boot time
systemd-analyze blame    # Per-unit boot time, sorted slowest-first
systemd-analyze critical-chain  # Identifies the slowest path through dependencies

Preboot Execution Environment (PXE)

PXE allows a machine to boot over the network rather than from a local disk. The firmware contacts a DHCP server, receives a TFTP server address, downloads a bootloader binary (like PXELINUX or GRUB), and proceeds through the normal boot sequence from there. PXE is how large-scale automated deployments (Kickstart, cloud-init) provision thousands of machines without manually inserting media.

⚠️ Exam Trap: GRUB configuration files (grub.cfg) should never be edited directly — they are auto-generated and will be overwritten. Always edit /etc/default/grub and run the appropriate regeneration command. On the exam, any answer suggesting direct edits to grub.cfg is wrong.

Reflection Question: A server is stuck at the GRUB rescue prompt after a disk was replaced. You can see the disk with ls (hd0,gpt2)/. What is the most likely cause and what steps would recover the system?