The boot sequence
Linux boots in a strict chain: firmware → bootloader → kernel → initramfs → PID 1. Each stage hands control to the next with a specific handoff. Knowing where the chain breaks tells you exactly how to recover a box that will not boot.
It is 2 am. A production VM is not responding. You console in and see a blinking cursor — the box never finished booting. Do you know where in the chain it stopped? Without that mental model, you are guessing. With it, you can read the cursor position, the last log line, or the grub menu and know immediately: firmware, bootloader, kernel decompression, initramfs mount, or PID 1 crash.
The Linux boot sequence is not magic — it is a strict chain of handoffs, each stage doing exactly one job before passing control to the next. When it breaks, it breaks at a seam.
After this lesson you can name every stage in the Linux boot sequence, explain what each stage hands to the next, identify which stage is responsible for a given boot symptom, and use journalctl -b to read the boot log.
Stage 1 — Firmware (UEFI or BIOS). When power is applied, the CPU starts executing from a fixed address in ROM — the firmware. On modern machines this is UEFI; on legacy hardware it is BIOS. The firmware does a Power-On Self Test (POST): check that RAM is present and readable, find storage controllers, enumerate PCI devices. It has no concept of Linux yet — just hardware.
At the end of POST, firmware looks for a bootable device. UEFI reads the EFI System Partition (ESP, typically /dev/sda1, formatted FAT32) and finds an EFI executable (e.g. grubx64.efi). BIOS reads the first 512 bytes of the disk (the Master Boot Record) and jumps to the code there.
The firmware’s job is done the moment it hands control to the bootloader. If the machine stops here you see: no POST beep, blank screen, or a firmware error message (“No boot device found”, “BOOTMGR is missing on a Windows-legacy path”).
Stage 2 — Bootloader (GRUB 2). The bootloader’s entire purpose is to load the kernel and hand it an initramfs image plus a command line. On Debian/Ubuntu the bootloader is GRUB 2 (/boot/grub/grub.cfg). GRUB reads its configuration file, shows you a menu (for a few seconds, or immediately if configured), then:
- Loads the kernel image from
/boot/vmlinuz-<version>into memory. - Loads the initial RAM filesystem from
/boot/initrd.img-<version>into memory. - Passes the kernel command line (from
grub.cfg— e.g.root=/dev/sda2 ro quiet splash). - Jumps to the kernel entry point.
If GRUB fails, you see its error shell or “error: no such device” messages. A common cause: the UUID in grub.cfg does not match the actual disk (this happens after disk replacement or partition resize).
Stage 3 — Kernel decompression and initialization. The kernel image (vmlinuz) is a compressed self-extracting binary. When GRUB jumps to it, the first thing the kernel does is decompress itself in-place. Then it initializes the CPU (sets up the interrupt descriptor table, enables paging), detects hardware from the device tree or ACPI tables, and initializes the memory allocator.
At this point, no disk is mounted — not even the root filesystem. The kernel only has the initramfs image in memory. Kernel messages appear on the console (the lines you see scroll by: [ 0.000000] Booting Linux on physical CPU 0x0). If the kernel panics here, it is usually a bad kernel parameter, missing CPU features (e.g., NX bit flag), or memory corruption.
Stage 4 — initramfs (initial RAM filesystem). The kernel mounts the initramfs as a temporary root filesystem (in memory, not on disk). Inside it lives a minimal userland: busybox, the udev device manager, and crucially the scripts and tools needed to find and mount the real root filesystem. This is where LVM activation, LUKS decryption, RAID assembly, and fsck happen — before the permanent root is mounted.
# Inspect what is inside the initramfs
lsinitramfs /boot/initrd.img-$(uname -r) | head -30Once the initramfs scripts successfully mount the real root at /root (from the initramfs perspective), they call switch_root to pivot from the RAM root to the real disk root. The initramfs RAM is freed. If the system stops here — e.g., you see “Waiting for root device…” — the initramfs cannot find or decrypt the disk.
Stage 5 — PID 1 and the system coming up. With the real root mounted and the pivot done, the kernel executes /sbin/init (or /lib/systemd/systemd) as PID 1 — the very first userland process. On modern Debian/Ubuntu this is systemd. PID 1 is responsible for everything from here: mounting the rest of the filesystems, starting all services, and reaching the target state (e.g., multi-user.target). Boot is complete when PID 1 signals that the target is active.
# See the full boot log from the most recent boot
journalctl -b
# Check how long each boot stage took
systemd-analyze blameIf PID 1 crashes, the kernel panics with “Kernel panic — not syncing: Attempted to kill init!” — there is no recovery without a reboot.
Diagnose a box that stops with “Waiting for root device /dev/sda2…”
This message is printed by the initramfs scripts when they cannot find the device. The most common cause on a VM that had its disk replaced: the UUID in /etc/fstab and in grub.cfg still points to the old disk’s UUID.
Recovery steps using a live boot:
# Boot from live USB, then:
# 1. Find the actual UUID of the new disk
blkid /dev/sda2
# 2. Mount the real root temporarily
mount /dev/sda2 /mnt
# 3. Edit fstab to use the new UUID
nano /mnt/etc/fstab
# 4. Chroot and regenerate grub
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt update-grub
# 5. RebootThe key insight: the initramfs passes control only after switch_root succeeds. A UUID mismatch is 100% a Stage 4 failure, not a kernel or firmware problem.
▸Why this works
On macOS and Apple Silicon Macs, the boot chain is Apple-controlled: iBoot (Apple Boot ROM) → macOS kernel. There is no GRUB, no initramfs in the Linux sense, and no /sbin/init — macOS uses launchd as PID 1. The conceptual flow (firmware → bootloader → kernel → init) is the same, but every concrete tool is different. Everything in this lesson applies to Linux on bare metal, VMs, and containers starting from the kernel stage.
▸Common mistake
A frequent mistake when chroot-recovering a broken boot: forgetting to bind-mount /dev, /proc, and /sys before running update-grub or dpkg. Without those pseudo-filesystems, update-grub may fail silently or generate a broken config because it cannot read the current disk topology from /sys/block. Always bind-mount all three before any chroot operation that touches the bootloader or initramfs.
A VM shows "Waiting for root device..." and never proceeds. Which boot stage has failed?
Linux boots in five stages: firmware (POST, find boot device), bootloader (load kernel + initramfs + cmdline), kernel init (decompress, detect hardware), initramfs (find and mount real root — where LUKS/LVM live), and PID 1 (systemd brings up services). Each stage hands off to the next at a well-defined seam. Boot failures are always at a seam: “no boot device” is firmware/bootloader; “Waiting for root device” is initramfs; “Attempted to kill init” is PID 1. journalctl -b and systemd-analyze blame are your primary tools after a successful boot.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.