The Linux boot process, from power button to login
What actually happens between pressing power and seeing a login prompt.
Explain like I'm 5
Imagine waking up a very sleepy giant who must follow the exact same getting-ready routine every single morning, in strict order, no skipping.
- The alarm clock (firmware) buzzes the moment you press the power button. It checks the giant still has all his bits — arms, legs, brain. Yep, all here.
- The to-do list on the fridge (the bootloader) tells the giant which brain to put on today, because he owns a few.
- Putting the brain on (the kernel) — now the giant can think and talk to his hands and feet.
- A little emergency backpack (initramfs) holds just enough tools to unlock the front door to the big cupboard where all his real clothes live.
- The butler (systemd) wakes up and starts everything else in the right order: the lights, the kettle, the radio.
- Finally a sign appears on the door: "Who are you? Please sign in." That's the login prompt.
Each helper does exactly one job, then hands control to the next. If any helper trips up, the giant just stands there confused — which is precisely why knowing the order helps you fix it.
Beginner
Booting is a handoff chain. Each stage knows just enough to find, load, and start the next one. Here are the players in order:
| Stage | What it does | Lives where |
|---|---|---|
| Firmware (BIOS/UEFI) | Powers up hardware, runs POST (self-test), finds a boot device | Chip on the motherboard |
| Bootloader (GRUB2) | Shows the boot menu, loads the kernel and initramfs into RAM | Boot partition or EFI System Partition |
| Kernel | The core of Linux — hardware, memory, processes | /boot/vmlinuz-* |
| initramfs | Tiny temporary root with drivers needed to mount the real root | /boot/initramfs-* or initrd.img-* |
| init / systemd | First real process (PID 1); starts every service | /usr/lib/systemd/systemd |
| Login | getty + login or a display manager | Virtual terminals / GUI |
Classic chicken-and-egg: the kernel needs a driver — say, for LVM, RAID, LUKS, or NVMe — to read the root filesystem, but that driver lives on the root filesystem it can't yet mount. The initramfs is a small filesystem baked into RAM at boot time that carries those drivers, mounts the real root, and then steps aside.
Once the real root is mounted and systemd takes over as PID 1, it brings the system up to a target — usually multi-user.target (networked text logins) or graphical.target (desktop environment) — and you get a prompt.
Intermediate
Let's trace the real sequence from power-on to prompt. Each step is a genuine transfer of control.
- 1Power onfirmware runs POST
- 2FirmwareBIOS/UEFI finds boot device
- 3GRUB2reads grub.cfg, shows menu
- 4Kernelvmlinuz decompresses, inits hardware
- 5initramfsloads drivers, mounts real root
- 6switch_rootpivot to real /
- 7systemd (PID 1)activates default target
- 8Logingetty / display manager
Firmware and POST. On power-up the firmware runs the Power-On Self-Test, initialises the CPU, RAM and buses, then searches for something bootable. On modern UEFI systems it reads its NVRAM boot entries and loads an EFI application (the bootloader) from the EFI System Partition (ESP). On legacy BIOS machines it loads the first 512 bytes of the chosen disk — the MBR — and chains from there.
GRUB2. The bootloader presents the menu defined in grub.cfg (usually under /boot/grub2/ or /boot/grub/), then loads the selected kernel (vmlinuz) and initramfs into RAM and hands the kernel its command line (e.g. root=UUID=... ro quiet). GRUB then jumps into the kernel.
Kernel + initramfs. The kernel decompresses itself, sets up memory management and the scheduler, detects hardware, and mounts the initramfs as a temporary root. Inside the initramfs, early-userspace scripts or systemd units load the modules needed to find the real root — assembling LVM, RAID, or LUKS as needed — then mount it.
Once the real root is mounted, the initramfs calls switch_root (a cousin of pivot_root): it moves the new root to /, frees the initramfs RAM, and execs the real /sbin/init — which is a symlink to systemd — as PID 1. Same PID, entirely new universe.
systemd to login. As PID 1, systemd reads its unit files and activates everything needed by the default target. multi-user.target starts networking and spawns getty on the virtual terminals; graphical.target additionally launches a display manager. Either way, you finally meet a login prompt.
Advanced
systemd targets replace SysV runlevels. Targets are synchronisation points — named groups of units that should be active together. They map roughly to the old numeric runlevels:
| SysV runlevel | systemd target | Meaning |
|---|---|---|
| 0 | poweroff.target | Halt |
| 1 / S | rescue.target | Single-user, minimal, root shell |
| 3 | multi-user.target | Full multi-user, no GUI |
| 5 | graphical.target | Multi-user + display manager |
| 6 | reboot.target | Reboot |
The boot default is set by a symlink: default.target points at the desired target under /etc/systemd/system/. Change it permanently with systemctl set-default multi-user.target, or override it for a single boot by appending systemd.unit=rescue.target to the kernel command line in GRUB.
Wants=/Requires= declare a dependency (pull that unit in). After=/Before= declare ordering (start me after/before that unit). You need both if order matters — Requires= alone does not imply After=, so units can start in parallel and race each other. This trips up nearly everyone writing custom units.
systemd builds a dependency graph from these directives and activates as much as possible in parallel, using targets as barriers. That parallelism is the main reason systemd boots substantially faster than serial SysV init scripts.
The kernel command line is where a surprising amount of boot behaviour is controlled. Common entries: root= (device or UUID of the real root, e.g. root=UUID=...), ro (mount root read-only initially so fsck can run safely), quiet (suppress kernel log output), splash (show a boot animation), and init= (override PID 1 entirely). GRUB assembles this from /etc/default/grub (GRUB_CMDLINE_LINUX and GRUB_CMDLINE_LINUX_DEFAULT) into the final grub.cfg. You can also edit it live at the GRUB menu by pressing e.
# What command line did we actually boot with?
cat /proc/cmdline
# What target are we in, and what is the persistent default?
systemctl get-default
systemctl list-units --type=target --state=activeDeep dive
At expert level the interesting parts are the firmware contract, the initramfs internals, and the troubleshooting tools you reach for when boot goes wrong.
UEFI boot entries and the ESP. UEFI keeps a list of boot entries in motherboard NVRAM, each pointing at an EFI binary on the EFI System Partition — a FAT32 partition mounted at /boot/efi (or /efi on some distros). Inspect and edit them with efibootmgr:
# List boot order and all entries
efibootmgr -v
# Files actually on the ESP
ls /boot/efi/EFI/
# Add a new entry (distro-specific paths vary)
sudo efibootmgr --create --disk /dev/sda --part 1 \
--label "Fedora" --loader "\\EFI\\fedora\\shimx64.efi"With Secure Boot enabled, firmware will only run EFI binaries signed by a key it trusts. Distros ship a small first-stage loader called shim, signed by Microsoft's UEFI CA (trusted by most motherboards), which in turn verifies the distro-signed GRUB and kernel. If you build your own kernel or load out-of-tree modules, they must be signed — either with your own key enrolled via MOK (mokutil --import), or Secure Boot must be disabled. An unsigned binary gets a firm refusal at firmware level.
initramfs internals. It's not magic — it's a compressed cpio archive unpacked into a tmpfs. Inside you'll find /bin (often busybox, or systemd itself in the modern systemd-in-initramfs layout), a curated set of kernel modules, udev rules, and the scripts or units that probe hardware, assemble LVM/RAID/LUKS, interpret root=, and mount the real root. dracut (Fedora/RHEL/SUSE), mkinitcpio (Arch), and initramfs-tools (Debian/Ubuntu) all build it from module specs. You can inspect and rebuild:
# List contents of the current initramfs (dracut)
lsinitrd /boot/initramfs-$(uname -r).img
# Same on Debian/Ubuntu
unmkinitramfs /boot/initrd.img-$(uname -r) /tmp/initrd-inspect
ls /tmp/initrd-inspect
# Rebuild after adding a driver or config change (dracut)
sudo dracut --force /boot/initramfs-$(uname -r).img $(uname -r)
# Rebuild on Debian/Ubuntu
sudo update-initramfs -u -k $(uname -r)Troubleshooting by symptom. The prompt (or lack of one) you land on identifies the broken stage:
| Symptom | Likely stage | First move |
|---|---|---|
grub rescue> prompt | GRUB found its first stage but lost its config/modules | Use ls to find the partition with /boot/grub, set prefix/root, insmod normal, boot, then reinstall GRUB |
| Drops to emergency shell | initramfs could not mount the real root | Check root=/UUID in /proc/cmdline, check fstab, check for a missing driver in the initramfs |
| Boots to rescue target | Mounted root but failed before multi-user.target | journalctl -xb to find the failed unit; systemctl --failed |
| Very slow boot, hangs late | A systemd unit is stalling or timing out | systemd-analyze blame, systemd-analyze critical-chain |
emergency.target is the barest possible shell: root filesystem mounted read-only, almost nothing else started. Use it when even basic initialisation has failed. rescue.target mounts local filesystems and starts a few more things before dropping to a root shell. Reach either by appending systemd.unit=emergency.target (or rescue.target) to the kernel line at the GRUB menu.
# Logs from this boot (-b) with explanations (-x)
journalctl -xb
# Raw kernel ring buffer — hardware and driver errors
dmesg --level=err,warn
# Boot time breakdown, then per-unit ranking
systemd-analyze
systemd-analyze blame
# Units that gave up entirely
systemctl --failedPress power and the firmware runs POST and locates a boot device; on UEFI it reads NVRAM boot entries and loads an EFI bootloader from the ESP (verified by shim under Secure Boot), on legacy BIOS it chains via the MBR. GRUB2 parses grub.cfg, displays the boot menu, loads the kernel (vmlinuz) and initramfs into RAM, and hands over the kernel command line (root=, ro, quiet, etc.). The kernel initialises hardware and mounts the initramfs as a temporary root; the initramfs carries the drivers needed for the real storage stack — LVM, RAID, LUKS, NVMe — mounts the real root, then calls switch_root to pivot to it and execs /sbin/init (systemd) as PID 1. systemd reads its unit files, builds a dependency graph using Wants=/Requires= and After=/Before=, and activates units in parallel until the default target (multi-user.target or graphical.target) is reached, at which point getty or a display manager offers a login. When something breaks, the prompt you land on names the stage: grub rescue> means the bootloader is lost, an emergency shell means root couldn't be mounted, and a failed unit means read journalctl -xb.
Frequently asked questions
What is the difference between BIOS and UEFI?
Both are firmware that brings up hardware and hands off to a bootloader, but legacy BIOS loads from a 512-byte MBR and is largely feature-frozen. UEFI loads EFI applications from a FAT-formatted EFI System Partition, stores named boot entries in NVRAM (manageable with efibootmgr), supports disks larger than 2 TB via GPT, and adds Secure Boot. Most hardware shipped since around 2012 uses UEFI.
Why does Linux need an initramfs?
Because the kernel often needs a driver — for LVM, software RAID, LUKS encryption, or a particular storage controller — to read the root filesystem, and that driver lives on the root filesystem it cannot yet mount. The initramfs is a small filesystem loaded into RAM by the bootloader; it carries those drivers, assembles the storage stack, mounts the real root, and then hands over.
What is the default systemd target and how do I change it?
It is whatever default.target symlinks to — usually graphical.target (GUI) or multi-user.target (text). Check it with `systemctl get-default` and change it with `sudo systemctl set-default multi-user.target`. For a single boot, press e at the GRUB menu and append `systemd.unit=multi-user.target` to the kernel line.
How do I boot into single-user or rescue mode?
At the GRUB menu press e, find the line beginning linux, and append `systemd.unit=rescue.target` (single-user, local filesystems mounted) or `systemd.unit=emergency.target` (bare root shell, root read-only). Press Ctrl-X or F10 to boot with that override. The traditional `single` or `1` kernel argument also still works on most distros as an alias for rescue.
How do I find out why my boot is slow?
Run `systemd-analyze` for an overall firmware/loader/kernel/userspace time breakdown, `systemd-analyze blame` to rank individual units by startup time, and `systemd-analyze critical-chain` to see the longest dependency path. `systemctl --failed` shows any units that failed to start at all.
What does the GRUB rescue prompt mean and how do I fix it?
grub rescue> means GRUB loaded its first stage but could not find its configuration or modules — most commonly because /boot moved, was reformatted, or GRUB was not reinstalled after a disk change. At the prompt, use ls to find the partition holding /boot/grub, then set root and prefix, then insmod normal and normal to continue booting. Once up, reinstall GRUB with grub-install and regenerate the config with update-grub or grub2-mkconfig.
ShellQuest turns concepts like this into bite-sized lessons, puzzles and labs you actually practise.
Join the waitlist