initramfs

When the kernel first starts, it faces a chicken-and-egg problem: it needs to mount your real root file system (the disk where everything lives), but the driver that talks to your particular disk controller — and maybe the code to unlock an encrypted disk or assemble a RAID — might itself live on that very disk. The initramfs (initial RAM file system) solves this: it is a small, complete, throwaway file system bundled with the kernel and loaded into memory at boot, carrying just enough tools and drivers to reach the real root. Think of it as a survival kit you parachute in with: a tiny tent and a map that let you build the proper house once you have landed.

Concretely, the bootloader loads the initramfs into RAM right beside the kernel. The kernel unpacks it into a temporary in-memory file system and runs a small init script inside it. That script loads the needed kernel modules (the storage driver, the file-system driver), does any special setup (decrypt the disk, assemble software RAID, find a logical volume), and then mounts the actual root file system from the physical disk. Finally it performs a switch_root: it makes the real disk the new root and hands off to the real init/systemd, after which the initramfs is discarded and its memory freed. The older initrd did roughly the same job using a ramdisk image; modern systems use the more flexible initramfs (a compressed cpio archive).

It matters because it lets one generic, distribution-shipped kernel boot on wildly different machines without compiling every possible driver permanently into the kernel — the right drivers are simply staged in the initramfs. A common misconception is that the initramfs is your real file system; it is temporary and tiny, exists only to bootstrap the real one, and is thrown away the moment its job is done.