The Linux boot chain for troubleshooting: firmware, bootloader, kernel, initramfs and systemd

What it is

bootup(7) describes the chain: system firmware does minimal hardware initialization and hands control to a boot loader (GRUB or systemd-boot) stored on persistent storage. The boot loader invokes an OS kernel from disk or network; on EFI systems the firmware can also load the kernel directly. The kernel then mounts an in-memory root — the initramfs, a compressed CPIO archive extracted into a tmpfs — which locates and mounts the real root filesystem. The initramfs then hands over to the host's system manager (systemd(1) on most current distributions), which probes remaining hardware, mounts the rest of the filesystems and starts configured services up to the default target.

Why it matters

A failure in any stage looks different and needs a different fix: a firmware/boot-loader failure gives no kernel output at all; a kernel failure produces early kernel messages but no init; an initramfs failure typically drops to an early shell ((initramfs) on Debian/Ubuntu, a dracut emergency shell on RHEL-family systems) or hangs waiting for a root device; a systemd failure boots the kernel fine but services fail or the system lands in a target other than the default one. Treating all four as "it doesn't boot" wastes time reinstalling the wrong component.

How to apply

• Watch the console during boot (locally, over serial, or via a hypervisor console) to see the last stage that produced output.
• After a boot that reaches systemd, review the boot's own log: journalctl -b for the current boot, journalctl -b -1 for the previous one if the system rebooted itself (add --no-pager in scripts; output is paged through less by default). Reading the system journal needs root or membership in systemd-journal, adm or wheel.
• Measure where systemd spent time or what blocked it with systemd-analyze blame and systemd-analyze critical-chain, which prints the time-critical chain of units for a target.
• On the kernel command line, pass systemd.unit= to select an alternative startup target (for example rescue.target) for one boot only, without editing any file, per kernel-command-line(7); the rd.-prefixed form (rd.systemd.unit=) applies only inside the initramfs.
• If nothing reaches a login prompt, check the firmware/boot-loader stage first (does the boot menu appear at all?) before assuming the kernel or systemd is at fault.

Pitfalls

• Reading journalctl -b after the failing boot has already been superseded by a successful one; use -b -1, -b -2, etc. (journalctl --list-boots shows what is available), and note that a non-persistent journal loses earlier boots entirely.
• systemd-analyze blame does not report Type=simple services, because systemd treats them as started immediately; a slow simple service will not show up there.
• Assuming a silent screen after the firmware splash means "kernel crashed" when it may simply be a graphical boot animation hiding kernel messages; remove quiet splash (Debian/Ubuntu) or rhgb quiet (RHEL family) for one boot in the GRUB editor to see the real output.