Linux Boot & systemd
The boot sequence from power-on to login, BIOS vs UEFI, systemd units and targets, and debugging a failed service with journalctl.
5 questions
JuniorTheoryCommonWhat is a systemd unit, and what are the main unit types?
What is a systemd unit, and what are the main unit types?
systemd is the init system the kernel starts as PID 1; a unit is a declarative object it manages from a config file. Key types: .service (a process), .target (a group that replaces SysV runlevels), .socket (socket activation), .timer (cron-like). You drive them all with systemctl.
Common mistakes
- ✗Thinking a unit is a running process rather than a config-described object
- ✗Believing systemd handles only
.serviceunits, not targets/sockets/timers - ✗Assuming SysV runlevels remain instead of
.targetunits replacing them
Follow-up questions
- →How does a
.targetunit differ in practice from an old SysV runlevel? - →What does socket activation via a
.socketunit buy you at boot time?
MiddleTheoryCommonWalk the Linux boot sequence from power-on to the login prompt.
Walk the Linux boot sequence from power-on to the login prompt.
Firmware (BIOS or UEFI) runs POST, then hands off to the bootloader. GRUB loads the kernel and an initramfs and passes the kernel command line. The kernel uses the initramfs to mount the real root, then execs PID 1 — systemd — which starts the default target's units in dependency order until login.
Common mistakes
- ✗Skipping initramfs and assuming the kernel mounts the real root directly
- ✗Thinking the bootloader, not the kernel, starts PID 1 and the services
- ✗Believing services start in arbitrary order rather than by target dependencies
Follow-up questions
- →Why is an initramfs needed at all instead of building drivers into the kernel?
- →What does the kernel command line passed by GRUB typically configure?
JuniorTheoryOccasionalWhat is the difference between BIOS and UEFI firmware at boot?
What is the difference between BIOS and UEFI firmware at boot?
Both are firmware that runs first at power-on, then hands off to a bootloader. Legacy BIOS reads a 512-byte MBR in 16-bit mode, capping boot disks at 2 TB. UEFI reads a GPT table, loads an .efi bootloader from an EFI System Partition, handles far larger disks, and can enforce Secure Boot.
Common mistakes
- ✗Reversing them — thinking BIOS is the newer, GPT-aware firmware
- ✗Believing UEFI still boots from a 512-byte MBR like BIOS
- ✗Confusing Secure Boot with the BIOS/UEFI distinction itself
Follow-up questions
- →Why does a GPT disk keep a protective MBR in its very first sector?
- →What lives on the EFI System Partition, and what filesystem does it use?
MiddleDebuggingOccasionalA service runs after I start it but is gone after a reboot — diagnose and fix.
A service runs after I start it but is gone after a reboot — diagnose and fix.
The unit is disabled, so nothing pulled it in at boot — start had run it for that session only. start runs a unit now but does not survive reboot; enable creates the WantedBy symlink so it boots but not now. The empty journalctl -b shows it never started. Fix: systemctl enable --now myapp.
Common mistakes
- ✗Confusing
start(run now) withenable(start at boot) - ✗Re-running
startafter every reboot instead of enabling once - ✗Reading an empty
journalctl -bas a crash rather than never starting
Follow-up questions
- →What symlink does
systemctl enablecreate, and in which directory? - →How does a
maskedunit differ from a merelydisabledone?
MiddleCodeOccasionalComplete a systemd service unit that restarts the daemon on failure.
Complete a systemd service unit that restarts the daemon on failure.
In [Service] add Restart=on-failure so systemd relaunches the daemon on a non-zero exit, plus RestartSec=5. In [Install] add WantedBy=multi-user.target so enable links it into that boot target. Then run systemctl enable --now myapp: enable wires it for boot, --now starts it now.
Common mistakes
- ✗Putting
RestartorWantedByin the wrong unit section - ✗Thinking
systemctl startalone makes a unit survive a reboot - ✗Omitting
[Install] WantedBy, soenablehas no target to link into
Follow-up questions
- →What does
systemctl daemon-reloaddo after you edit a unit file? - →How does
Restart=on-failurediffer fromRestart=always?
