// linux fundamentals — module 06

Module 6 — The Boot Sequence: From Power Button to Login

Thesis: Boot is a relay race with five well-defined runners: firmware → bootloader → kernel → initramfs → init. Each runner's only job is to find the next one and hand off. Name the runners and you can diagnose which one dropped the baton, instead of staring at a black screen.

Prerequisite: Module 5 — Processes, Signals, and IO — the finish line of boot is PID 1 forking and exec'ing all of userland, and you know exactly what those words mean.

You now have every concept boot requires: the kernel as a file (M0/M2), drivers as modules (M2), filesystems and mounting (M3), PID 1 and fork/exec (M2/M5). Boot is just those pieces in chronological order.

6.1 The bootstrap problem

The chicken-and-egg at the heart of it: programs live on disk → reading a disk requires a driver → drivers are software → software lives on disk. And at power-on, RAM is empty and the CPU knows nothing.

The solution is a chain of stages, each just barely capable enough to load the next, each stage bigger and smarter than the last. "Booting" is short for bootstrapping — pulling yourself up by your bootstraps. Five stages:

firmware → bootloader → kernel → initramfs → init (PID 1) → login

6.2 Stage 1 — Firmware (UEFI, formerly BIOS)

Soldered onto the motherboard is a flash chip containing firmware — code the CPU is hardwired to start executing at power-on. It initializes RAM and core hardware, optionally shows a splash screen/setup menu (the F2/DEL screen), and then does its one essential job: find something bootable and jump to it.

Two generations:

• BIOS (1981–): read the first 512-byte sector of a disk — the MBR — and execute whatever's there. 512 bytes is too small for a real loader, so BIOS boot was a Rube-Goldberg chain of stub-loaders. Legacy now, but the vocabulary ("MBR") survives.
• UEFI (modern standard): the firmware understands partitions and filesystems. It looks for a special partition — the EFI System Partition (ESP), FAT-formatted (§3.6's vfat, and the reason that format still matters), usually mounted at /boot or /boot/efi on a running system — and runs a bootloader program (.efi file) from it. UEFI keeps a boot-entry list in NVRAM, editable from Linux with efibootmgr. Secure Boot is a UEFI feature: the firmware verifies signatures on what it loads — worth knowing exists, since it's the usual culprit when a fresh Linux install refuses to boot.

Which one did your machine use? A running system tells you: the directory /sys/firmware/efi (§2.7 — the kernel publishing state) exists if and only if you booted via UEFI.

6.3 Stage 2 — The bootloader

The firmware is generic; it knows nothing about Linux. The bootloader is the Linux-aware runner: its job is to locate a kernel image, load it into RAM (with its initramfs, §6.5), pass it a command line, and jump to it — usually after offering you a menu.

The two you'll meet:

• GRUB — the traditional heavyweight: scriptable, themable, handles BIOS and UEFI and exotic setups. Config generated into grub.cfg (you don't hand-edit it).
• systemd-boot — the modern minimalist for UEFI-only machines: a tiny menu that reads simple text entries from the ESP, each naming a kernel, an initramfs, and options. One entry looks like:

  title   NixOS
  linux   /EFI/nixos/kernel.efi
  initrd  /EFI/nixos/initrd.efi
  options root=UUID=3f8a…  loglevel=4

  Readable with Module 3 eyes: a path to the kernel file, a path to the initramfs, and root=UUID=… telling the kernel which filesystem will be the real root — a UUID, for exactly the reason fstab uses them.

That options line is the kernel command line — boot-time parameters for the kernel. Two facts make it a diagnostic power tool: a running system shows what it booted with (cat /proc/cmdline), and the bootloader menu lets you edit it for one boot — this is how you rescue an unbootable system (e.g., appending systemd.unit=rescue.target, once Module 7 gives you targets, or the classic init=/bin/sh — "make my shell PID 1 instead of systemd," a phrase you can fully parse since Module 5).

Handoff: you pick a menu entry (or the timeout does); the bootloader loads two files into RAM — kernel + initramfs — and jumps into the kernel. Its job is done; it's gone from memory.

6.4 Stage 3 — The kernel wakes up

The kernel (the one program from Module 0, until now literally a compressed file — /boot/vmlinuz-* — which you can now appreciate) decompresses itself and initializes its whole universe: CPU cores, the memory manager and page tables (§2.4), the scheduler (§2.3), built-in drivers probing hardware. Everything it does here is narrated into the ring buffer you read as dmesg — the boot story, from the kernel's own mouth (Lab 2's tool, origin revealed).

Then it hits the wall from §6.1: to continue, it must mount the real root filesystem (root= from the command line) — but the driver for your disk controller, or your filesystem type, or your disk encryption, may be a module (§2.6)… which lives on that very disk. The chicken-and-egg, one last time.

6.5 Stage 4 — initramfs: the temporary root

The escape hatch: the bootloader already loaded a second file into RAM alongside the kernel — the initramfs (initial RAM filesystem; the older near-synonym is initrd). It's a compressed archive containing a miniature userland: just enough kernel modules and just enough tools to find and mount the real root.

The kernel unpacks it into a RAM-backed filesystem (tmpfs, §3.7 — every module keeps paying off), uses it as a temporary root, and runs its init script. That script: loads the storage/filesystem modules it carries → finds the device named by root=UUID=… → (if needed) prompts for the disk-encryption passphrase — this is the stage asking, which is why the prompt appears so early and unstyled → mounts the real root → then pivots: switches the meaning of / from the RAM filesystem to the real one (switch_root), frees the initramfs, and execs the real init.

Why is the initramfs per-machine (generated at install/update time by tools like mkinitcpio/dracut) rather than shipped generic? Because it carries your hardware's modules — which is also why a broken initramfs (bad update, missing driver) yields boot's most famous error: the kernel panic / emergency shell complaining it cannot mount root. When you see it, you'll know the exact runner that fell: stage 4, and the usual fix is regenerating it.

6.6 Stage 5 — PID 1 and the rise of userland

The initramfs execs /sbin/init on the real root — creating PID 1 (§2.5), which on your machine is a symlink to (or directly is) systemd. The kernel's active role in boot is over; from here on it does its normal job — scheduling, syscalls — while userland assembles itself:

PID 1 reads its configuration and brings up everything else — remaining mounts from fstab (§3.6's promised loop), device management, networking, logging, services — as a dependency graph, not a fixed script, which is precisely Module 7's subject. The visible finish line is a login prompt: either getty processes on text consoles (spot them in pstree) or a graphical display manager. You authenticate (§4.2's machinery verifies against /etc/shadow), and a shell or desktop session starts as your UID (§4.1's story, now with its full backstory).

Every login prompt you have ever seen sits at the end of this exact chain. Total elapsed time: a few seconds.

6.7 Debugging boot: naming the fallen runner

The payoff table — symptom → stage:

Your tools: the bootloader menu itself (edit the kernel command line for one boot — §6.3), dmesg for stages 3–4, and journalctl -b for stage 5 (formally introduced next module). Plus the time-honored heavy tool: boot from a live USB — which is just this same five-stage chain running from a stick — and mount/repair the internal disk with Module 3 skills.

6.8 → NixOS: generations live here

NixOS's headline safety feature is a bootloader feature. Each time you rebuild your NixOS system, the result is a new immutable generation — and NixOS adds a menu entry for it in systemd-boot (older entries remain, listing their date and NixOS version). A broken configuration is therefore never fatal: reboot, choose the previous generation from the very menu you studied in §6.3, and you're back on the last working system — same mechanism as choosing any other entry, pointing at a different kernel/initramfs/init= (NixOS passes init=/nix/store/…-nixos-system-…/init on the kernel command line — parseable to you word by word now).

Rollback isn't magic; it's stage 2 of the relay, with more entries in the table. You'll also declare the loader itself in configuration: boot.loader.systemd-boot.enable = true; — a sentence about a program whose exact job you now know.

Lab 6

Best done on a VM or a machine you can freely reboot. (VM bonus: you can watch boot as slowly as you like, and snapshots make §6.7-style breakage reversible.)

1. Identify your firmware path. Run ls /sys/firmware/efi — UEFI if it exists. If UEFI: lsblk -f and find the ESP (vfat partition, mounted at /boot or /boot/efi), then list it — find the actual .efi bootloader files and your kernels/initramfs images. Run sudo efibootmgr and read the firmware's boot-entry list, including the boot order.

2. Read your kernel command line. cat /proc/cmdline. Identify root= (match its UUID against lsblk -f — it should be your root partition) and translate every other parameter you see (search man 7 kernel-parameters or the web — each is a boot instruction you can now contextualize).

3. Actually look at the menu. Reboot and stop at the bootloader menu (hold/press the key if it's hidden — often Shift or Esc for GRUB, any key for systemd-boot). Read every entry. Find the edit key (e in both) and look at an entry's kernel/initrd/options lines without changing anything. Boot normally. This five-minute exercise is where rescue skills live.

4. Read the kernel's boot diary. After rebooting: sudo dmesg | less. Hunt for landmarks in order: the kernel version banner (line 1), CPU/memory setup, disk detection (search /sda or /nvme), the root mount, and the hand-off (search systemd — "systemd v… running in system mode" is stage 5 starting). You just read the relay race's own transcript.

5. Look inside your initramfs. Run lsinitrd (Fedora-family) or lsinitramfs /boot/initrd* (Debian-family) — or lsinitcpio (Arch). Skim: a mini /bin with a shell, a /lib/modules tree of storage drivers, an init script. It's a tiny Module-3 world in a zip file, and you can name why each part is there.

6. Time the race. systemd-analyze — total boot time split into firmware / loader / kernel / userspace: your four+1 stages, with stopwatch numbers. Then systemd-analyze blame | head — the slowest parts of stage 5, a preview of Module 7's units.

7. (VM with snapshot only) Break stage 5 and rescue via stage 2. At the bootloader, edit the kernel line and append init=/bin/sh. Boot: you land in a bare root shell as PID 1 — run echo $$ for proof, and feel how little exists (no job control, read-only root). Reboot normally, and appreciate what PID 1 usually does for you. This is the classic "forgot root password" rescue path, and you just walked it calmly.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

1. Recite the five stages, and each runner's one-sentence job.
2. What is the bootstrap problem, and how does the chain-of-stages design solve it? Where does it recur a second time, and what solves that?
3. BIOS vs. UEFI: how does each find the next stage? What is the ESP, what filesystem is it, and how do you check which path your machine took?
4. What three things does a bootloader entry specify? What is the kernel command line, how do you read the current one, and why is being able to edit it for one boot a rescue superpower?
5. What's inside an initramfs, why must it be generated per-machine, and what famous failure appears when it's wrong?
6. What does "pivot to the real root" mean, and what happens to the initramfs afterward?
7. From exec of PID 1 to the login prompt: what happens, in Module-5 vocabulary?
8. For each symptom, name the stage: no vendor logo · "no bootable device" · kernel panic "cannot mount root" · hangs after boot messages, before login · rejects your password.

And perform cold:

• Determine firmware type, find the ESP, and read the boot entries of any machine.
• Halt at a bootloader menu and inspect/edit an entry.
• Walk dmesg output and point at each stage's landmarks.

When all of that is effortless: Module 7 — systemd