The boot process — from power button to a running OS
Every mechanism covered so far in this domain — processes, memory, the kernel — has to come from somewhere. Booting is the sequence that gets a completely powered-off machine to the point where any of it exists at all.
Beginner
3 min read
The chicken-and-egg problem booting has to solve
When a computer is first powered on, there's no operating system loaded into
memory yet — nothing is running that could load one. Booting is the
sequence of small, self-contained steps that gets from "nothing is running"
to "the full operating system, with its process scheduler and memory
manager, is up and managing the machine" — each step just capable enough to
load and hand off to the next.
The four stages
Firmware (UEFI, or the older BIOS) — the very first code that runs,
stored on a chip on the motherboard itself, independent of any disk. It
runs a hardware self-check (POST — Power-On Self-Test), then locates a
bootable disk and hands off to whatever bootloader is stored there.
Bootloader (GRUB, on most Linux systems) — a small, purpose-built
program whose only real job is finding the actual OS kernel on disk and
loading it into memory. On a machine with multiple operating systems
installed, this is also the "choose your OS" menu you might have seen.
Kernel initialization — once loaded, the kernel takes over: it
initializes memory management, discovers and sets up hardware devices,
and prepares the process scheduler and every other mechanism this domain
has covered so far. At this point the machine has an operating system
running, but nothing user-facing yet.
Init process (PID 1) — the kernel starts exactly one first process
(systemd on most modern Linux distributions), which becomes the parent
of every other process that will ever run. It starts every configured
background service (networking, logging, your database, whatever
systemctl status reports on) in order, and once enough of them are up,
the system is genuinely ready — a login prompt or desktop appears.
Why this order can't be skipped or reordered
Each stage depends entirely on the guarantees the one before it already
established. The bootloader can't run before firmware has initialized
enough hardware to read a disk at all; the kernel can't start managing
processes before it's loaded into memory by the bootloader; and no service
managed by init can start before the kernel it depends on for memory,
scheduling, and system calls is already running. It's the same "layers,
each depending on the one below" pattern that showed up in the networking
domain's protocol stack — just applied to bringing up an entire machine
instead of sending a single packet.
Why this matters day to day
"Why won't this server boot" is a genuinely different class of problem
depending on which stage it's stuck at — a firmware-level hardware failure,
a corrupted bootloader, a kernel that can't find its root filesystem, or a
specific service failing to start under init are all different failures
needing completely different fixes. Knowing the actual sequence (and that
systemctl status reports on the last stage specifically) is what turns
"the server won't come up" from a mystery into a specific stage to
investigate.