Check: Linux boot

Firmware (BIOS or UEFI) checks the hardware and hands control to the bootloader. The bootloader loads the kernel and the initramfs image into memory and hands control to the kernel. The kernel unpacks the initramfs, which mounts the real root, and only then does PID 1 start, usually systemd.

There's one exception, and it doesn't break the order. On UEFI, firmware can launch a kernel built with an EFI stub directly, without a separate bootloader: that link drops out, but nothing else changes. More in the boot overview lesson.

The MBR takes up the first sector of the disk, 512 bytes. The layout is fixed:

bytes 0-445     primary bootloader code (446 bytes)
bytes 446-509   partition table, 4 entries of 16 bytes each (64 bytes)
bytes 510-511   55 aa signature (2 bytes)

Option 3 confuses the code with the partition table: 64 bytes is exactly the table. One caveat: in a modern MBR, bytes 440-445 inside the code area also hold a disk signature, so there's really 440 bytes of code there. The classic answer is still 446: that's how much is reserved up to the partition table. A GPT disk also has a sector 0, the protective MBR, with a single entry of type ee covering the whole disk. It's there so old utilities don't mistake the disk for empty. The actual GPT header sits in the next sector and starts with the signature EFI PART. More in the firmware and disk lesson.

The root can sit on LVM, RAID, or behind encryption, and the kernel modules it needs live on that same root. initramfs solves this chicken-and-egg problem. It's a compressed cpio archive that the kernel unpacks into an in-memory rootfs (tmpfs, if that's enabled in the kernel) and runs /init from it. The script loads modules, for example dm-mod.ko for LVM, mounts the real root, and switches to it with switch_root.

Each kernel has its own image: initrd.img-<version>. The modules inside it live in a directory named after the kernel version, so you need to look at the image for the kernel you actually booted with. More in the initramfs lesson.

A unit file describes what should be running and what it depends on, not a sequence of commands. systemd builds a dependency graph and starts everything that's already able to start, all at once. The default target (default.target) is a link to one of the targets, for example multi-user.target or graphical.target. The command systemctl set-default is exactly what rewrites that link.

systemd has nothing to do with firmware mode. By the time it starts, firmware finished its job long ago. If a filesystem from /etc/fstab fails to mount at boot, local-fs.target fails, and systemd drops into emergency.target: the console shows You are in emergency mode. More in the systemd as init lesson.

When a device appears or disappears, the kernel sends a uevent. On modern systems, the kernel itself creates the base node, something like /dev/sdb1, in devtmpfs. udev (systemd-udevd) catches the event and, by its own rules, sets permissions and ownership, gives network cards predictable names, and adds stable links like /dev/disk/by-uuid/<UUID>.

These are exactly the links written into /etc/fstab. The name sdb depends on the order disks are discovered in, while the UUID is recorded in the filesystem itself and never changes. If a disk gets replaced and fstab isn't updated, udev won't create links with the old UUID anymore, and systemd will wait for a device that doesn't exist. More in the udev lesson.