Linux Boot Process

What Happens When a Linux Machine Boots?

Step by Step

1. Firmware (BIOS/UEFI) — runs a Power-On Self Test (POST), initializes basic hardware, then hands off to a bootable device based on boot order.
2. Bootloader (GRUB2) — reads its config (/boot/grub/grub.cfg), presents the OS/kernel menu, then loads the selected kernel (vmlinuz) and initramfs into memory.
3. Kernel initialization — the kernel decompresses itself, initializes core drivers, and mounts the temporary initramfs as a root filesystem.
4. initramfs → real root — initramfs contains just enough drivers/tools to find and mount the actual root filesystem (e.g., on an encrypted or LVM volume), then hands off (switch_root) to it.
5. systemd starts as PID 1 — the very first real userspace process; everything else is its descendant.
6. Targets — systemd brings up services in dependency order until it reaches the configured target (multi-user.target for servers, graphical.target for desktops).
7. Login — a getty process presents a login prompt on the console, or a display manager starts for a GUI.

Inspecting and Debugging Boot

systemctl get-default             # which target boots by default
systemd-analyze                   # total boot time
systemd-analyze blame             # which services took the longest to start
systemd-analyze critical-chain    # the critical path of slow-starting units

journalctl -b                     # full boot log for the current boot
journalctl -b -1                  # log from the PREVIOUS boot (useful after a crash)
dmesg -T                          # kernel ring buffer messages

GRUB Essentials

cat /boot/grub2/grub.cfg | grep menuentry   # available boot entries
sudo grub2-mkconfig -o /boot/grub2/grub.cfg # regenerate config after a kernel update

# At the GRUB menu: press 'e' to edit boot params, add:
#   systemd.unit=rescue.target     -> boot to a minimal rescue shell
#   single                          -> single-user mode

SysV init vs systemd (Why It Changed)

Most modern distros (RHEL 7+, Ubuntu 16.04+, Debian 8+) use systemd; a few minimal/embedded distros still use SysV or OpenRC.

Recovering From a Broken Boot

# From the GRUB menu, add to the kernel line:
systemd.unit=emergency.target    # minimal shell, only root mounted read-only
systemd.unit=rescue.target        # single-user, most local filesystems mounted

# Once in a rescue shell:
mount -o remount,rw /             # remount root as writable
journalctl -xb                    # see what failed on the last boot attempt
systemctl list-units --failed     # which units failed to start

Production Considerations

• A bad /etc/fstab entry is one of the most common causes of a server dropping into emergency mode — always test mount changes carefully, and know systemd.unit=emergency.target as your escape hatch.
• systemd-analyze blame should be part of any “why is this server slow to boot/scale up” investigation — especially for autoscaling groups where boot time directly affects scale-out latency.
• Cloud instances (EC2, GCE) rely on the same boot chain but add cloud-init as an additional systemd-managed step for first-boot configuration.

Quick Interview Answer

“Boot goes: firmware POST, bootloader (GRUB) loads the kernel and initramfs, the kernel initializes and switches from initramfs to the real root filesystem, then systemd starts as PID 1 and brings the system up to a target like multi-user or graphical in dependency order rather than the old sequential SysV init scripts. journalctl -b and systemd-analyze blame are the go-to tools for debugging boot issues.”

Common Mistakes

• Confusing “kernel panic” (kernel itself crashes) with “systemd unit failed” (a service failed after the kernel booted fine) — very different debugging paths.
• Not knowing journalctl -b -1 exists to inspect the previous boot after an unexpected reboot.
• Editing /etc/fstab without testing (mount -a) before rebooting — an error there can strand a remote server in emergency mode.