There is a chicken and egg problem at the start of every Linux boot. The kernel must mount the root filesystem to find its modules. The driver for the controller holding that filesystem is a module. Which is on the root filesystem.

The initramfs breaks the loop.

What it does

The bootloader loads two things: the kernel, and a compressed archive called the initramfs. The kernel unpacks that archive into a temporary filesystem in memory and runs the init script inside it.

That miniature system:

1. Loads storage controller modules, NVMe, SATA, RAID, whatever is needed
2. Assembles RAID arrays and activates LVM volumes
3. Prompts for a passphrase and unlocks encrypted volumes
4. Mounts the real root filesystem
5. Pivots to it and executes the real init, normally systemd

Then it disappears. Everything after that is your actual system.

Rebuilding it

# Debian and Ubuntu
sudo update-initramfs -u                 # current kernel
sudo update-initramfs -u -k all          # every installed kernel

# Fedora and RHEL
sudo dracut -f                           # current kernel
sudo dracut -f --regenerate-all

# Arch
sudo mkinitcpio -P

Kernel updates do this automatically. You do it manually after changing something early boot depends on.

When you need to

Encryption changes. Adding or changing a LUKS volume that must be unlocked at boot.

Storage layout changes. New RAID array, changed LVM configuration, different root filesystem.

Missing driver. Moving a disk to a machine with a different controller, or hardware the generic image did not cover.

Adding a module needed early. A network driver for network boot, or a specific storage driver.

Configuration

Debian and Ubuntu, /etc/initramfs-tools/:

# Force a module in
echo "nvme" | sudo tee -a /etc/initramfs-tools/modules
sudo update-initramfs -u

Arch, /etc/mkinitcpio.conf, where the HOOKS line is the important part and its order matters:

HOOKS=(base udev autodetect modconf block encrypt lvm2 filesystems keyboard fsck)

encrypt must come before lvm2 for LUKS on LVM, and after it for LVM on LUKS. Getting this backwards produces a system that cannot find its root, and it is the single most common mkinitcpio mistake.

Fedora, /etc/dracut.conf.d/:

# /etc/dracut.conf.d/mymodules.conf
add_drivers+=" nvme "

Looking inside

lsinitramfs /boot/initrd.img-$(uname -r) | less     # Debian and Ubuntu
lsinitrd /boot/initramfs-$(uname -r).img | less     # Fedora
lsinitcpio /boot/initramfs-linux.img                # Arch

# Is a specific module in there?
lsinitramfs /boot/initrd.img-$(uname -r) | grep nvme

This turns “I think the module is missing” into a fact, which matters when you are about to reboot a machine you cannot easily reach.

When boot fails

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

The kernel and initramfs loaded, and the root filesystem could not be mounted. Three usual causes:

Missing driver. The controller is not supported by what is in the image.

Wrong root device. The UUID in the bootloader no longer matches, common after restoring or cloning a disk. Check with blkid from a live USB.

Corrupt initramfs. A rebuild interrupted by a full /boot partition produces a truncated image, which is why a full /boot is a genuinely dangerous condition.

The fix is nearly always the same: boot an older kernel entry from the GRUB menu, or boot a live USB and chroot in, then rebuild.

sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot
for d in dev proc sys run; do sudo mount --bind /$d /mnt/$d; done
sudo chroot /mnt
update-initramfs -u -k all
exit

Our chroot rescue guide covers the whole procedure.

Keep /boot from filling up

Each kernel keeps its own initramfs, and they are not small. A separate /boot partition sized years ago fills quietly, and the first symptom is a failed rebuild that leaves you unbootable.

df -h /boot
sudo apt autoremove --purge            # remove old kernels, Debian and Ubuntu
sudo dnf remove --oldinstallonly        # Fedora

Check this before a kernel update rather than after.

Frequently Asked Questions

What is the initramfs for?

It solves a bootstrapping problem. The kernel needs a driver to read the disk holding the root filesystem, but that driver is usually a module stored on that same disk. The initramfs is a small filesystem loaded into memory containing exactly the modules needed to reach the real root.

When do I need to rebuild it?

After changing anything the early boot depends on: encryption setup, RAID or LVM configuration, the root filesystem type, or adding a driver module needed to see the boot disk. Kernel updates rebuild it automatically.

What causes a kernel panic saying unable to mount root?

Usually a missing driver in the initramfs, or a root UUID that no longer matches. The kernel booted, the initramfs loaded, and it could not find or read the device it was told to mount. Boot an older kernel entry and rebuild.

Is initramfs the same as initrd?

Effectively yes in modern usage. initrd was the older mechanism using a block device image; initramfs is a compressed cpio archive unpacked into a tmpfs. The names are used interchangeably and the files are often still called initrd.

Why is my initramfs so large?

Most distributions build a generic image containing drivers for nearly every controller so the image works on any hardware. A host-only image containing just what your machine needs is much smaller and will not boot on different hardware.

How do I see what is inside it?

lsinitramfs on Debian and Ubuntu, or lsinitrd on Fedora, lists the contents. This is how you confirm a module you expected is actually present rather than guessing about why early boot failed.