Part 6 — Boot and the kernel

Everything so far assumed a system that's already running. This part goes backward, to before any of it exists: what actually happens between pressing the power button and seeing a login prompt, and where the kernel — the thing implementing every mechanism from Parts 1–5 — fits into that sequence.

In one sentence

Booting a computer is a chain of progressively-more-capable programs each loading and handing off to the next — firmware, then a bootloader, then the kernel, then user space — and every link in that chain is a place things can go wrong, or (just as importantly) be attacked.

Why this matters

"Why won't this server boot" (a genuinely common real incident) is a diagnostic process that only makes sense once you know WHICH stage failed — each stage fails differently and needs a completely different fix.

How it actually works

   THE CHAIN, roughly, on a modern PC/server:

     1. FIRMWARE (UEFI, the modern successor to the old BIOS) runs
        FIRST, the instant power is applied -- built into the
        motherboard, independent of any disk. It initialises basic
        hardware, runs a Power-On Self-Test (POST), and looks for a
        BOOTLOADER to hand off to.

     2. THE BOOTLOADER (commonly GRUB on Linux) is a small program,
        itself loaded from disk by the firmware, whose entire job is
        to find and load the actual KERNEL into memory and start it.
        This is why you see a boot MENU (choose a kernel version, boot
        into recovery mode) at this stage -- the bootloader is where
        that choice happens, before the kernel is even running.

     3. THE KERNEL takes over: initialises itself, sets up memory
        management (Chapter 10), detects and initialises hardware
        (loading DEVICE DRIVERS as it goes, Chapter 22), mounts an
        initial, minimal root filesystem, and finally starts the very
        FIRST USER-SPACE PROCESS -- historically always PID 1.

     4. PID 1 (the INIT SYSTEM -- systemd on most modern Linux
        distributions, Chapter 22) takes over from here: it starts every
        other system service (networking, logging, your SSH daemon, your
        application) in the right order, and becomes the ultimate PARENT
        of every process on the machine (Chapter 3) -- if a process's
        original parent dies, PID 1 adopts it.

     5. Eventually, a LOGIN PROMPT (or, for a server, the point where
        SSH becomes reachable) appears -- the machine is now "up."

   EVERY STAGE HANDS OFF TRUST to the next: the firmware trusts the
   bootloader it loads, the bootloader trusts the kernel, the kernel
   trusts PID 1. This CHAIN OF TRUST is exactly what security features
   like UEFI SECURE BOOT are designed to protect (below).

Real-world example

   UEFI SECURE BOOT exists specifically because of a well-documented,
   real attack category: BOOTKITS -- malware that infects the
   BOOTLOADER or early boot stages, running BEFORE the operating system
   (and therefore before any antivirus/endpoint-security software
   running IN the OS) has even started. A bootkit that compromises stage
   2 of this chain can control everything that loads afterward,
   including subverting the kernel itself, while remaining invisible to
   security tools that only start running once the OS is already up --
   a genuinely serious, well-documented real threat category (multiple
   real bootkit families have been publicly documented by security
   researchers over the years, targeting exactly this "trust chain,
   compromised at the earliest possible link" attack surface).
   Secure Boot's mechanism is a direct application of this chapter's
   "each stage hands off trust" model: the firmware CRYPTOGRAPHICALLY
   VERIFIES the bootloader's signature before running it, the bootloader
   verifies the kernel's signature before running IT, and so on --
   refusing to hand off execution to anything unsigned or tampered
   with, specifically closing the "compromise an early stage, own
   everything after it" attack this whole boot chain would otherwise be
   vulnerable to.

Try it yourself

# See how your current machine actually booted
dmesg | head -30              # kernel's own boot-time log (may need sudo,
                              # and may only show recent entries on
                              # systems with dmesg buffer limits)
journalctl -b | head -30      # systemd's fuller boot log, if available

# See what your bootloader currently offers
cat /boot/grub/grub.cfg 2>/dev/null | grep -i "menuentry" | head -5 || \
  echo "GRUB config not found at the default path on this system"

# Time your own boot (useful, real diagnostic technique)
systemd-analyze 2>/dev/null || echo "systemd-analyze not available"
systemd-analyze blame 2>/dev/null | head -10   # which services were
                                               # slowest to start

Common mistakes

Treating "won't boot" as one problem. A firmware failure, a bootloader failure, a kernel panic, and an init-system failure all look different and need completely different fixes — figure out WHICH stage failed before troubleshooting.
Assuming Secure Boot is "just an annoying setting." It's a genuine, meaningful defence against a real, documented attack class — disabling it casually (common when installing certain drivers or dual-booting) trades away real protection, which may or may not matter for your threat model.
Confusing the bootloader menu with the OS itself. Seeing the GRUB menu means the FIRMWARE and BOOTLOADER stages succeeded — a subsequent failure is happening in the kernel or init stage, a different problem entirely.

Check yourself

List the boot chain from power-on to login prompt, in order.
What is PID 1, and why does it matter that it becomes the "ultimate parent" of every process?
What specific attack does UEFI Secure Boot defend against, and how does it use this chapter's "chain of trust" idea to do it?

(Answers: Appendix E.)