<aside> 🧭

Module 05 · Boot and init — from firmware to systemd

This is the last module in the Foundation tier, and it is here on purpose. Booting looks like a beginner topic, but explaining it honestly needs PID 1, mounts, and signal handling — all of which you now have.

🧠 concept → 🧩 real-world analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)

</aside>

<aside> ✅

Before you start, you should already know:

From Module 01 — kernel versus user space, device drivers, and how to read /proc and /sys.

From Module 02 — what PID 1 is and why it is special.

From Module 03 — mounts, mount points, and how one filesystem hides another.

From Module 04 — signals, TERM versus KILL, and graceful shutdown.

Everything in this module is read-only or reversible. Nothing here will stop your lab booting — but do it on the lab VM anyway, not on a machine you care about.

</aside>

🔌 Part A · Before the kernel runs

A1 · Firmware — the first code that runs

<aside> 📖

Official docs: bootup(7) — the whole boot sequence · Kernel admin guide · The kernel's command-line parameters

</aside>

When you press the power button, there is no operating system. There is no filesystem, no driver, and nothing in memory. The CPU has to start executing something, and that something has to be in a fixed place it can find without help.

That is the firmware: code stored on a chip on the motherboard. Its job is small and specific:

Check the hardware is present and working.
Find something bootable.
Load the first part of it into memory and jump to it.

Then it is finished. Firmware does not stay resident and does not manage anything.

There are two kinds, and which one you have changes almost everything about the next step.

	BIOS (legacy)	UEFI (modern)
How it finds the boot code	Reads the first 512 bytes of a disk — the master boot record — and runs it.	Reads a real filesystem (a FAT partition, the ESP) and runs a named `.efi` file.
How much room the boot code has	446 bytes. Genuinely.	As much as it likes. It is an ordinary file.
Boot entries	None. There is one MBR.	A list stored in NVRAM on the motherboard, editable with `efibootmgr`.
Signature checking	No.	Yes — Secure Boot.

That 446-byte figure is the reason GRUB exists in the shape it does. You cannot fit a bootloader in 446 bytes, so on BIOS systems it is split into stages: a tiny first stage whose only job is to find and load a bigger second stage.

<aside> 🧩

Real-world analogy — a relay race

Booting is a relay. Four runners, and each one's only real job is to hand the baton to the next.

Firmware runs the first leg. It knows almost nothing — no files, no network — but it knows where to find the next runner.
The bootloader runs the second leg. It can read a disk and knows how to start a kernel.
The kernel runs the third. Now there are drivers and memory management — and unlike the first two runners, the kernel never leaves the track; it stays underneath everything for as long as the machine is on. What it hands over is control of userspace, not the machine.
The initramfs init runs a short fourth leg: it loads the drivers it carries, mounts the real root, and hands over by execing the real init.
systemd runs the last leg, and it stays too.

The useful part of the picture is what happens at each handover: the first two runners stop. Firmware is not sitting underneath your running system supervising things. It handed over and finished. This is why "the BIOS is causing my performance problem" is almost always wrong — by the time Linux is up, the firmware has not executed an instruction in minutes.

Where the analogy stops working. Real runners all run the same kind of leg. Here, each stage is written in a different style, with different capabilities, and the handovers are where boot problems live. Nearly every boot failure you will debug happens at a handover — not in the middle of a leg.

</aside>

🧪 Exercise A1.1 — Find out which firmware booted this machine

# The one-command answer: if this directory exists, you booted with UEFI
[ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS (legacy)"

# On UEFI, the firmware keeps a boot menu in NVRAM
if command -v efibootmgr >/dev/null && [ -d /sys/firmware/efi ]; then
  sudo efibootmgr -v | head -8
else
  echo "(efibootmgr not installed, or BIOS boot)"
fi

# The EFI System Partition is an ordinary FAT filesystem - Module 03 applies
findmnt /boot/efi 2>/dev/null || echo "(no ESP mounted)"

# What is actually on it?
sudo find /boot/efi -name '*.efi' 2>/dev/null | head -5