The Boot Process, the Kernel & systemd Targets

In one line

Firmware → bootloader → kernel → initramfs → systemd → your services. Knowing each stage tells you where to look when a machine doesn't come back after a reboot.

0/5 · 0%

Think of it like this

Opening a shop in the morning. The security guard unlocks the building (firmware), the manager finds today's plan (bootloader), the manager arrives and takes charge (kernel), a temporary helper fetches the keys to the stockroom (initramfs), and then the shift supervisor starts every department in the right order (systemd).

Key ideas

01
FIRMWARE (UEFI, or legacy BIOS) tests the hardware and loads the BOOTLOADER (usually GRUB) from the disk's EFI partition. GRUB shows the menu of kernels and passes the KERNEL COMMAND LINE (root=, quiet, console=). On cloud VMs you rarely see this, but a bad kernel or GRUB config is still why some instances never come back.
02
The KERNEL initialises CPU, memory, and drivers, then mounts a small temporary root filesystem, the INITRAMFS, which contains just enough tools and drivers to find and mount the real root filesystem (on LVM, RAID, or an encrypted disk). Then it starts PID 1.
03
PID 1 is SYSTEMD. It reads unit files and starts services in parallel according to dependencies, aiming for a TARGET (a named group of units): multi-user.target (a normal server, no GUI), graphical.target (desktop), rescue.target (single-user maintenance). systemctl get-default shows it; systemd-analyze blame shows what slowed the boot.
04
KERNEL vs USER SPACE: the kernel runs with full hardware access and exposes services through SYSTEM CALLS (open, read, fork, connect...). Every program you run lives in user space and asks the kernel for things. Containers share the host's kernel, which is why they start in milliseconds (Docker course, container internals).
05
Where to look when boot goes wrong: journalctl -b (this boot), journalctl -b -1 (previous boot), dmesg (kernel messages: disks, drivers, OOM kills), and on cloud VMs the provider's serial console or 'get system log'. Classic culprits: a typo in /etc/fstab (Topic 7.5), a full root disk, or a failed service that others depend on.

Code & diagrams

from power-on to logindiagram

Rendering diagram…

inspect the bootbash

systemctl get-default              # multi-user.target
systemd-analyze                    # Startup finished in 2.1s (kernel) + 9.8s (userspace)
systemd-analyze blame | head -5    # slowest units
journalctl -b -p err               # errors from this boot only
journalctl -b -1 -n 50             # last 50 lines of the PREVIOUS boot (why did it reboot?)
dmesg -T | tail -20                # kernel messages with human timestamps
uname -r                           # running kernel version

Explain it without notes

What is the job of the initramfs?

What's the difference between kernel space and user space?

Practice

A VM rebooted unexpectedly overnight. Which commands tell you why?

Trade-offs

↔
Fewer services at boot means faster, more secure servers; disabling units you don't understand can also break dependencies, so check systemctl list-dependencies first.

Done when you can

I can name each boot stage and what it does
I can find errors from the current and previous boot