The boot process on a modern Debian server (Debian 12 “bookworm” or Debian 13 “trixie” in 2026) follows the standard Linux boot sequence but includes several Debian-specific choices and behaviors that affect reliability, debuggability, and minimalism. Understanding the sequence helps diagnose boot failures, optimize startup time, harden the early boot environment, and troubleshoot slow or hanging boots.
High-Level Overview of the Stages
- Firmware / UEFI → Bootloader
- Bootloader → Kernel + initramfs
- Kernel → init (systemd)
- systemd → Userspace targets & services
- Login prompt / getty
Detailed Step-by-Step Explanation
1. Firmware Phase (BIOS or UEFI)
- BIOS (legacy):
- POST (Power-On Self-Test)
- Reads Master Boot Record (MBR) sector 0 of the boot disk
- Loads first-stage bootloader (usually GRUB)
- UEFI (modern servers, default since ~2015):
- UEFI firmware scans EFI System Partition (ESP, usually FAT32, mounted at /boot/efi)
- Reads EFI variables (NVRAM) to find boot entries
- Loads EFI application: typically \EFI\debian\grubx64.efi (or shimx64.efi if Secure Boot is enabled)
- Secure Boot (if active): verifies signatures using Microsoft-signed shim → grub → kernel
Debian installer creates a clean UEFI boot entry named “Debian” by default.
2. GRUB (Grand Unified Bootloader) Phase
GRUB 2 is the default bootloader in Debian.
- Stage 1: grubx64.efi (or core.img in BIOS) loads
- Stage 2: Loads /boot/grub/grub.cfg (generated by update-grub)
- Displays menu (if timeout > 0) or boots default entry immediately
- Loads selected kernel (vmlinuz-) and initramfs (initrd.img-) into memory
- Passes kernel command line parameters (from GRUB or /etc/default/grub)
Common Debian kernel parameters seen in grub.cfg:
- quiet splash (reduced console output)
- root=UUID=… or root=/dev/sda1
- ro (read-only initial root mount)
- initrd=…
3. Kernel Decompression & Early Initialization
- Kernel decompresses itself
- Initializes CPU, memory, interrupt controllers, timers
- Mounts initramfs (initial RAM filesystem) as temporary root
- initramfs contains minimal userspace: busybox, udev, modules needed to access real root (LUKS, LVM, RAID, NFS, virtio drivers, etc.)
Debian’s initramfs is generated by initramfs-tools (default) or dracut (optional).
4. initramfs → Switch Root
The init script inside initramfs:
- Loads required kernel modules (from /etc/initramfs-tools/modules or auto-detected)
- Assembles RAID (mdadm), unlocks LUKS (cryptsetup), activates LVM (lvm), waits for network if root is NFS
- Mounts real root filesystem (usually ext4/xfs/btrfs) read-only
- Checks filesystem if needed (fsck)
- Switches root: switch_root /newroot /sbin/init
If anything fails here (wrong UUID, LUKS passphrase timeout, missing module), you drop to initramfs emergency shell.
5. systemd as PID 1
Once real root is mounted:
- Kernel executes /sbin/init → symlink to /lib/systemd/systemd
- systemd becomes PID 1 and starts acting as system and service manager
systemd follows dependency-based activation:
- Mounts remaining filesystems from /etc/fstab
- Sets up tmpfs mounts (/run, /dev/shm, /tmp if tmpfs)
- Starts udev (device manager)
- Reaches basic.target → sysinit.target → multi-user.target (server default)
- Starts gettys (login prompts on console/tty)
- If graphical install: reaches graphical.target (rare on servers)
6. Typical Boot Targets on a Debian Server
- emergency.target → single-user rescue mode
- rescue.target → single-user with networking
- multi-user.target → non-GUI server state (default)
- graphical.target → desktop with display manager
Most servers boot to multi-user.target.
Where Things Commonly Go Wrong (and How to Diagnose)
| Stage | Symptom | Diagnostic Clues / Tools |
|---|---|---|
| Firmware/GRUB | No boot menu, stuck at logo | Check UEFI boot order, Secure Boot keys |
| Kernel loading | “Kernel panic – not syncing” | Missing initramfs, wrong root= parameter |
| initramfs | “Gave up waiting for root”, busybox shell | UUID mismatch, LUKS timeout, missing module |
| Early systemd | Hung after “Reached target Local File Systems” | fsck failure, bad fstab entry |
| Late userspace | Slow boot, services failed | systemd-analyze blame, journalctl -b -p err |
Useful Boot-Time Debugging Tricks
- Remove quiet from kernel cmdline → verbose kernel messages
- Add systemd.log_level=debug or rd.systemd.unit=emergency.target to drop to emergency shell
- Press e at GRUB menu → edit kernel line temporarily
- Boot with init=/bin/sh → bypass systemd for raw root shell (rescue only)
- systemd-analyze critical-chain and blame after successful boot → identify slow units
Why Debian’s Boot Is Considered Reliable
- Predictable initramfs generation
- UUID-based root identification (not device names)
- Thorough fsck integration
- systemd’s dependency tracking prevents race conditions
- Extensive journald logging from PID 1 onward
In short: the boot process is a carefully orchestrated handoff from firmware → GRUB → kernel → initramfs → systemd → multi-user.target, with each stage designed to fail safely and provide debug information when something goes wrong.