Walk me through what happens when a Linux system boots

Crisp answer: BIOS/UEFI runs POST, finds the bootloader on disk, GRUB loads the kernel into memory, the kernel mounts a temporary root filesystem (initramfs), runs systemd as PID 1, and systemd brings up the rest of the system in parallel to reach the target runlevel.

The full sequence:

1. BIOS / UEFI (firmware)

Power on triggers the firmware. It runs POST (Power-On Self Test) to check hardware, then searches for a bootable device according to the boot order (disk, USB, network PXE). On modern systems UEFI replaces BIOS — it can read the EFI System Partition (ESP) directly and supports Secure Boot, which verifies bootloader signatures before execution.

2. Bootloader — GRUB2

GRUB (GRand Unified Bootloader) lives in the MBR/GPT or the EFI partition. Its job is to load the Linux kernel (vmlinuz) and the initial RAM disk (initramfs / initrd) into memory. GRUB presents the boot menu (or skips it after a timeout). Key files:

/boot/grub/grub.cfg        # GRUB config — never edit directly
/etc/default/grub          # Human-editable GRUB settings
update-grub                # Regenerates grub.cfg from the above
/boot/vmlinuz-6.x.x        # The compressed kernel image
/boot/initramfs-6.x.x.img  # Temporary root filesystem

3. Kernel loads

GRUB hands control to the kernel. The kernel:

• Decompresses itself from the vmlinuz image
• Probes hardware and loads built-in drivers
• Mounts the initramfs as a temporary root filesystem (in RAM)
• Runs /init inside the initramfs — a minimal shell script or binary that loads the storage drivers needed to mount the real root filesystem
• Once the real root filesystem is mounted, the kernel pivot_root or chroot into it and discards the initramfs

Why initramfs? The kernel is compiled without every possible storage driver (e.g. NVMe, LVM, encrypted LUKS). The initramfs carries the specific drivers needed for this machine's root disk. Without it, the kernel couldn't find its own root partition.

4. systemd — PID 1

The kernel executes /sbin/init which on modern systems is a symlink to systemd. Systemd becomes PID 1 — every process on the system is a descendant of PID 1.

Systemd reads its target configuration (equivalent to SysV runlevels):

Target	Equivalent	Description
emergency.target	Single-user, minimal	Debug-only, almost nothing running
rescue.target	Single-user	Root filesystem mounted, no network
multi-user.target	Runlevel 3	Full multi-user, no GUI
graphical.target	Runlevel 5	Multi-user + display manager

The default target is usually multi-user.target on servers. Systemd activates units in dependency order, starting many in parallel.

5. User space comes up

Systemd starts services defined in unit files: networking, SSH daemon, logging (journald), cron, and any application services. The system is "booted" when the default target is reached.

Useful commands:

systemd-analyze              # Total boot time
systemd-analyze blame        # Time per service (find boot slowdowns)
systemd-analyze critical-chain  # Dependency chain on the critical path
journalctl -b                # All logs from this boot
journalctl -b -1             # Logs from the previous boot
dmesg                        # Kernel ring buffer messages
dmesg | grep -i error        # Kernel errors specifically

What to say in the interview:

"BIOS or UEFI runs POST, then hands off to GRUB which loads the kernel and initramfs. The kernel boots, mounts the initramfs to load storage drivers, then mounts the real root filesystem. It then executes systemd as PID 1, which reads the default target and activates services in parallel by dependency order. On a server that's usually multi-user.target — no graphical environment."

---