Why does a typical Linux distribution boot through an initramfs instead of letting the kernel mount the root filesystem directly, and what does that early user space do before it hands over?

## The problem it solves A distribution kernel has to boot laptops, NVMe servers, virtual machines with paravirtual disks, and hardware RAID controllers, all from one image. Compiling every driver in would make a huge kernel, so most drivers are modules — and modules live under `/lib/modules/` on the root filesystem, which the kernel cannot mount until it has the driver. That circularity is what the initramfs exists to break. There is a second reason, just as important on real servers: the root device may not exist as a device yet. If root sits on software RAID, on an encrypted volume that needs a passphrase, or on a network-attached disk, something in user space has to assemble or unlock it first. That "something" needs a filesystem to live on, and the only one available before root is mounted is one that lives in memory. ## What it physically is An **initramfs** is a cpio archive, compressed with gzip or zstd, sitting in `/boot` next to the kernel — `/boot/initramfs-<version>.img` on RHEL-family systems, `/boot/initrd.img-<version>` on Debian/Ubuntu. The bootloader loads it into memory as an opaque blob; the kernel unpacks it into a RAM-backed root filesystem and executes `/init` from it. (The older `initrd` mechanism was a *block device* image that the kernel mounted and later `pivot_root`ed away from; the modern initramfs is unpacked, not mounted, which is why it can simply be freed.) You can look inside one: ```bash lsinitrd /boot/initramfs-$(uname -r).img # dracut-based systems lsinitramfs /boot/initrd.img-$(uname -r) # Debian/Ubuntu ``` ## What its /init actually does Roughly, in order: start device management so hardware events are processed; load the modules for the storage controller and the root filesystem; wait for the device named by `root=` to appear, which is why `root=UUID=…` is used rather than a kernel device name that can change between boots; assemble or unlock the root device if needed; optionally check it; mount it **read-only** at `/sysroot`; and finally `switch_root` — move the `/proc`, `/sys` and `/dev` mounts into the new root, release the RAM filesystem, chroot, and `exec` the real init. Because that last step is an exec, the process keeps PID 1: there is exactly one PID 1 for the whole life of the machine. ## Host-only versus generic images This is where interviews get interesting. `dracut` defaults to a **host-only** image on Fedora and RHEL: it includes only the modules this machine currently needs, which keeps the image small and boot fast. The consequence is that the image is not portable — move that disk into a machine with a different disk controller, or change the storage backing of a VM, and the initramfs no longer contains the driver for the new root device. You get a kernel that boots fine and then panics with `VFS: Unable to mount root fs`. Rebuilding with a generic image (`dracut --no-hostonly`) is the fix, and it is the reason golden images for varied hardware are built non-host-only. ## Why it breaks The initramfs is **regenerated** whenever a kernel is installed or a relevant config changes, so it is a file that can be silently written wrong: - `/boot` is full, so the new image is truncated — the classic "it booted fine until the next reboot, three weeks after the update" failure. - The rebuild ran with a config that omits the module for this host's disk. - `root=` points to a UUID that no longer exists after a disk was replaced or cloned. All three present the same way: the kernel starts, prints messages, and then cannot find or mount root. The diagnostic move is to interrupt the initramfs before the pivot — dracut offers `rd.break` on the kernel command line, Debian's initramfs-tools offers `break=` — and look at what devices are actually present from that shell. ## The rule of thumb If the failure happens *before* any user-space service messages appear but *after* the kernel is clearly running, suspect the initramfs and the `root=` parameter. Regenerating it (`dracut -f` or `update-initramfs -u -k all`) from a rescue environment fixes a large share of "the server won't boot after the update" incidents.