Booting Linux and systemd

This chapter follows The Linux kernel.

When you power on a Debian machine, dozens of steps run before your shell prompt appears. Most server and desktop installs today use UEFI firmware, GRUB, an initramfs, and systemd as process 1. Knowing that chain helps you fix “won’t boot,” missing disks, and services that never start.

Firmware and the bootloader

UEFI (or legacy BIOS on older hardware) initializes hardware, reads NVRAM variables, and loads a bootloader. On Debian amd64, GRUB usually lives in the EFI System Partition and presents a menu of kernels.

GRUB reads configuration from /boot/grub/grub.cfg (generated from /etc/default/grub and scripts in /etc/grub.d/). Each menu entry points at a Linux kernel image and often an initramfs path under /boot.

After you change kernel cmdline options or add disks, regenerate GRUB:

1
sudo update-grub

On macOS, boot.efi and the Apple boot chain replace GRUB; on FreeBSD, bootloader stages differ but the idea—firmware loads a kernel—is the same.

Initramfs and root filesystem handoff

The kernel needs drivers to mount root: storage controllers, LUKS, LVM, or network root (less common on laptops). An initial RAM filesystem (initramfs) is a cpio archive the kernel unpacks into a temporary root. Early userspace (on Debian, initramfs-tools) loads modules, unlocks encrypted volumes, assembles RAID, then pivot_root into the real /.

If initramfs is missing modules, boot stops with errors about unknown UUID or unable to mount root. Fix by rebuilding initramfs after driver or crypttab changes:

1
sudo update-initramfs -u -k all

flowchart LR
  uefi[UEFI firmware]
  grub[GRUB]
  kernel[Linux kernel]
  initramfs[initramfs userspace]
  root[Real root on disk]
  uefi --> grub --> kernel --> initramfs --> root

systemd as PID 1

Once root is mounted, the kernel executes PID 1. On Debian 12+, that is systemd. PID 1 reaps zombies, starts the rest of the system, and defines dependency ordering for services.

Units are systemd’s configuration objects:

Targets such as multi-user.target (console/server) and graphical.target (desktop) pull in default dependencies. systemctl get-default shows which target boots by default.

Common commands:

1
systemctl status ssh.service
2
systemctl enable --now nginx.service
3
systemctl list-units --type=service --state=running

Legacy SysV init scripts still exist on some systems; Debian maps many through systemd. macOS uses launchd instead—plist-based, not unit files—but both solve “start the right daemons in order.”

journald and logs

systemd’s journald collects stdout, stderr, and syslog from services into a structured journal. On Debian, persistent journals often live under /var/log/journal/ when configured.

1
journalctl -u ssh.service -b
2
journalctl -xe
3
journalctl --disk-usage

-b limits to the current boot; -u filters by unit. For Apache on Debian, service logs still matter alongside access logs once a site is installed.

Plain text files under /var/log/ (auth.log, syslog) may still exist depending on rsyslog configuration; journald is the first place to inspect failed units.

Recovery and runlevels mindset

When the system will not reach multi-user mode, boot a rescue environment: Debian installer rescue mode, a live ISO, or single-user target (systemd.unit=rescue.target on the kernel cmdline). Mount root read-write, fix /etc/fstab, regenerate initramfs, or rollback kernel packages.

Understanding targets replaces old “runlevel 3 vs 5” thinking: rescue.target and emergency.target isolate minimal services for repair.

The next chapter, Scheduling tasks with cron and systemd timers, covers periodic work once the system is up.

The next chapter is Scheduling tasks with cron and systemd timers.