The boot process and the filesystem layout

Why this matters

Two questions account for a surprising share of the trouble a new Linux administrator gets into: what happens between pressing the power button and seeing a login prompt, and where does anything live.

They look like trivia. They are not. When a server will not boot, you cannot fix it unless you know which stage failed — firmware, bootloader, kernel, or init — because each stage fails differently and is repaired differently. And when you are told "the logs are filling the disk", you need to know that logs live in /var and that /var is very often its own filesystem, which is why the disk filled without touching anything else.

The exam tests both directly, and every later lesson assumes them.

The lesson

The boot process, stage by stage

Boot is a relay race. Each stage knows just enough to find and start the next one, then hands over.

1. Firmware. The board's own software runs first — BIOS on older hardware, UEFI on anything modern. It tests the hardware, then looks for something to boot. BIOS reads the first 512 bytes of a disk (the MBR); UEFI instead reads a FAT-formatted EFI System Partition and runs a .efi file from it. This is why UEFI systems have a small, oddly-formatted partition you must not delete.

2. The bootloader. On Linux this is almost always GRUB2. Its job is to find a kernel, load it into memory, hand it its parameters, and start it. It also presents the menu that lets you pick an older kernel or a recovery entry — which is the single most useful recovery tool on the system.

GRUB2's configuration files are worth separating carefully, because editing the wrong one is the classic mistake:

After changing the first two you must regenerate the third:

# Red Hat family
grub2-mkconfig -o /boot/grub2/grub.cfg
# Debian family
update-grub

3. The kernel. The kernel takes over the machine: it drives the hardware, manages memory and processes, and owns all access to devices. It is started with parameters — a plain string of options passed by the bootloader. You can see what the running kernel was given:

cat /proc/cmdline

Common ones you will actually use: ro (mount root read-only initially), quiet (suppress boot messages), single or systemd.unit=rescue.target (boot to a minimal shell for repair), and init=/bin/bash (a last-resort recovery shell, bypassing init entirely).

Editing a parameter for one boot only — press e at the GRUB menu, change the linux line, press Ctrl-X — is how you recover a system you cannot log into. It survives nothing, which is exactly what you want while experimenting.

4. The initrd. The initial RAM disk (initrd, or initramfs on current systems) is a small temporary root filesystem loaded into memory alongside the kernel.

It exists to solve a genuine chicken-and-egg problem. The kernel must mount the real root filesystem — but that root might be on an LVM volume, or on RAID, or encrypted, or on a SAN needing a driver. The kernel cannot read it without those drivers, and the drivers live on the filesystem it cannot read. So the initrd carries just enough drivers and tools to assemble the real root, mounts it, and then gets out of the way.

This is why a system stops booting after a kernel or storage change and drops you into an emergency shell. The initrd was not rebuilt, so it no longer contains the driver needed to find root. Rebuild it with dracut -f (Red Hat family) or update-initramfs -u (Debian family).

5. Init. The kernel starts the first user-space process, PID 1 — systemd on every current distribution. It brings up everything else. That is its own lesson.

Booting without a disk: PXE

Preboot Execution Environment lets a machine boot over the network with no operating system installed at all. The firmware asks DHCP for an address and is told the location of a TFTP server; it downloads a bootloader, then a kernel and initrd, and boots those.

You will meet PXE wherever machines are built at scale — provisioning a rack, re-imaging a lab, or running diskless nodes. For the exam, know the chain: DHCP hands out the pointer, TFTP serves the files.

Where everything lives: the Filesystem Hierarchy Standard

Linux has one tree, rooted at /. There are no drive letters; other disks are mounted onto directories inside that single tree. The Filesystem Hierarchy Standard is the agreement about what goes where, and it is why skills transfer between distributions at all.

Two of these repay a closer look.

/proc is not a disk. It is a window into the kernel, rendered as files. cat /proc/cpuinfo reports the processor, /proc/meminfo the memory, /proc/<PID>/ everything about one running process. Nothing there occupies disk space; it is generated the instant you read it. The same idea appears again in /sys.

/var is where disks die. Logs in /var/log, package caches in /var/cache, mail spools, database files. When a server reports a full disk and nobody has copied anything onto it, this is nearly always the answer, and runaway logging is nearly always the cause.

The distinction that ties the table together: /etc is configuration you write, /var is data the system writes, /usr is software that only changes when you install something. That split is exactly why /usr can be mounted read-only on a hardened system while /var cannot.

On the exam

• Expect to be given a boot symptom and asked which stage failed. "GRUB menu appears but the kernel panics looking for root" is an initrd problem, not a bootloader one.
• Know that /boot/grub2/grub.cfg is generated. A question offering "edit grub.cfg directly" as an option is offering you the wrong answer.
• Directory purposes come up as straight recall. /proc (kernel and process data), /var (logs and variable data) and /etc (configuration) are the three that appear most.
• PXE: DHCP supplies the pointer, TFTP supplies the files.
• Remember /tmp is cleared on reboot. Scenario questions about vanished files often hinge on nothing more than that.