4.2.4 initramfs

Introduction

The initramfs is a small, temporary root filesystem that the Linux kernel uses very early in the boot process, before your real root filesystem is available. It lives in memory, gets unpacked by the kernel, runs a short sequence of programs to prepare the system, then hands control off to the real root filesystem and your normal pid 1 (usually systemd).

In this chapter we focus on what initramfs is, what it contains, how it is created, and why it is essential for flexible and reliable booting. Details of BIOS vs UEFI, GRUB2, and kernel loading are handled in their own chapters, so here we only refer to them where needed.

What initramfs Is

The name initramfs comes from “initial RAM filesystem.” It is an archive, usually compressed, that the bootloader loads into memory along with the kernel. The kernel then unpacks it into a special filesystem stored in RAM. This serves as the first root filesystem mounted at boot.

Older systems used initrd (initial RAM disk) as a block device image, but most modern distributions use initramfs, which is a cpio archive directly unpacked into a tmpfs in memory. Conceptually they solve the same problem. With initramfs, the kernel does not deal with a separate block device for the initial root but instead works entirely with an in‑memory filesystem from the start.

You will typically see one or more files like initramfs-linux.img, initrd.img-<version>, or initramfs-<version>.img in /boot. The bootloader passes both the kernel image and this initramfs image to the kernel.

Role of initramfs in the Boot Sequence

Once the bootloader has loaded and started the kernel, the kernel needs a root filesystem to continue initialization. For modern systems this almost always means:

1. The kernel unpacks the initramfs archive from RAM into a temporary root filesystem.
2. The kernel executes the init program inside the initramfs. This init is not your usual systemd or sysvinit, but a small script or program with the specific goal of preparing the real root filesystem.
3. The init inside initramfs performs tasks such as loading kernel modules, detecting storage devices, assembling RAID, activating LVM volumes, or decrypting disks.
4. Once the real root filesystem is ready, initramfs switches the root from the RAM filesystem to the real one and then starts the “real” pid 1 on that filesystem.

Without initramfs, the kernel would need to have built‑in support for all the storage technology you use, which would make the kernel inflexible and very large. initramfs allows kernels to remain modular and still boot on various hardware and storage setups.

What initramfs Contains

An initramfs image is typically a compressed cpio archive. When unpacked, it looks like a very small Linux filesystem, with its own /bin, /sbin, /lib, /dev, /etc, and a few scripts.

The exact contents depend on the distribution and your configuration, but commonly you will find:

A minimal user space with a small shell or an init program. Many distributions use a small BusyBox based environment so that the initramfs can run shell scripts and basic utilities.

Essential kernel modules that are not compiled directly into the kernel but are required to reach the real root filesystem. This often includes storage drivers, filesystem drivers, and drivers for disk controllers.

Device discovery tools or helpers that scan for disks or network devices, which is especially important for complex setups like SANs or iSCSI used as root.

Code to handle advanced storage layouts, such as LVM volume activation, assembling software RAID arrays, or dealing with Btrfs subvolumes.

Support for disk encryption so that the system can prompt for a passphrase or use a key file to unlock an encrypted root partition before mounting it.

Configuration snippets that describe what and where the real root filesystem is, and what steps are required to make it available.

There is often also a small init script at the root of the initramfs filesystem, for example /init. This script is the first user space process executed by the kernel. Its main job is to prepare and then switch to the real root.

Typical initramfs Implementations on Major Distributions

Different distributions provide different tools to build and manage the initramfs image, but their goals are the same. Understanding these tools is useful for troubleshooting and customization.

On Debian and Ubuntu, initramfs-tools is commonly used. The main configuration lives under /etc/initramfs-tools/. Scripts in directories like /etc/initramfs-tools/scripts/ and /usr/share/initramfs-tools/scripts/ determine how the image is created and what happens at boot. The command update-initramfs -u regenerates the image for the current kernel, and update-initramfs -c -k <version> can create a new one for a specific kernel version.

On Fedora, RHEL, CentOS, and similar derivatives, the standard is dracut. Dracut uses a modular design with configuration in /etc/dracut.conf and module directories under /usr/lib/dracut/modules.d/. You update or rebuild images with dracut commands such as dracut -f which regenerates the default image. Dracut tries to be generic and only include what is actually needed for your system.

On Arch Linux and some derivatives, the tool is mkinitcpio. Configuration lives in /etc/mkinitcpio.conf. There you list hooks that determine what features are included, such as base, udev, autodetect, modconf, block, filesystems, and keyboard. Hooks are executed in order when the initramfs runs. The command mkinitcpio -P regenerates all configured images for installed kernels.

On openSUSE and some older systems, mkinitrd is used, although modern releases may use dracut or similar tools. The idea is similar: a script generates the initramfs image based on your current system configuration.

How initramfs Prepares the Real Root Filesystem

Once the kernel hands control to the init inside the initramfs, this small environment performs several critical tasks, often in the following logical sequence.

First, it sets up basic devices and filesystems. This includes mounting special filesystems like proc and sysfs with commands such as mount -t proc proc /proc or mount -t sysfs sysfs /sys. It may also setup devtmpfs or use udev or similar to populate /dev with device nodes.

Then, it loads required kernel modules that are not built in, for example modules for storage controllers, filesystems, USB, or NVM Express devices. The initramfs environment typically runs modprobe with a list of modules determined at creation time or through automatic detection.

Next, it discovers storage devices and assembles any complex storage configuration. This is where LVM, RAID, or advanced filesystem features come into play. For an LVM based root, the initramfs tools will scan for physical volumes, volume groups, and logical volumes, then activate them. For software RAID, it might run mdadm to assemble arrays. For Btrfs with subvolumes, it will detect the correct subvolume to mount as root.

If encryption is used, the initramfs environment is responsible for unlocking encrypted volumes. It might prompt on the console for a passphrase, or it might use a key file from another device, or a network based unlocking mechanism. Only after decryption can the real root partition be accessed.

After all of that, the init inside initramfs mounts the real root filesystem, usually on a temporary mount point like /new_root or /sysroot. It checks that the mount succeeded and that required files exist, such as /sbin/init or /lib/systemd/systemd on that filesystem.

At the final stage, the root of the running system is switched from the initramfs filesystem to the newly mounted real root. This change of root is often called “switch root” or “pivot root,” using helper programs like switch_root or pivot_root. After the switch, the temporary initramfs environment is usually discarded and its memory is freed. Finally, the real init system on the new root filesystem is executed, and normal boot continues.

Handling Complex Root Setups with initramfs

The presence of initramfs is what makes many advanced root filesystem configurations possible. Several common scenarios rely heavily on it.

Encrypted root filesystems use Linux Unified Key Setup (LUKS). Here the root partition is not readable until it is decrypted. The initramfs is responsible for asking for a passphrase very early in boot, running the appropriate crypto tools, and opening the encrypted volume so the kernel can see a normal block device to mount.

LVM based roots depend on initramfs to scan for physical volumes, find volume groups, and activate the logical volumes that contain the root filesystem. Without that step, the root volume is invisible.

Software RAID arrays for root require assembly at boot. The initramfs environment runs RAID tools to build the arrays from their component disks. Only then can the root filesystem on the RAID device be mounted.

Network based root filesystems, such as root over NFS or iSCSI, are another important case. The initramfs may bring up basic networking, configure an IP address, set up routing, and mount a root filesystem over the network. Without the flexibility of initramfs, these complex and specialized setups would be very hard to support.

Custom hooks or modules in tools like dracut or mkinitcpio let you extend initramfs behavior further, for example adding scripts that check hardware conditions or choose alternate roots in specific scenarios.

Inspecting and Modifying an initramfs Image

Although initramfs is normally managed by your distribution tools, it is useful to know that the image is just a compressed cpio archive. With root privileges you can inspect or even modify it manually for debugging and experimentation.

On a typical system you might see an image in /boot called initramfs-<version>.img. You can copy it to a temporary location, decompress it with a tool like gzip or xz if needed, and extract its contents with cpio. For example, you might run a sequence such as:

mkdir /tmp/initramfs-unpacked
cd /tmp/initramfs-unpacked
zcat /boot/initramfs-<version>.img | cpio -idmv

After extraction, you can examine the directories and scripts that live inside this image, especially the main /init script or program and the hooks that run during early boot.

To customize behavior you would normally change configuration files or scripts used by the initramfs building tool, such as /etc/initramfs-tools/ for Debian or /etc/mkinitcpio.conf for Arch, and then regenerate the image. Direct manual modification of the extracted contents and reassembly with cpio is possible but error prone, and not how distributions intend you to work in normal circumstances.

Troubleshooting initramfs Problems

When something goes wrong before the real root filesystem is mounted, you often encounter an initramfs emergency shell. This is a very minimal environment, usually with a small shell from BusyBox. The kernel console might show messages like “Cannot find root device” or “Waiting for root device” followed by a timeout.

In this shell you can run commands like ls /dev, cat /proc/cmdline, dmesg, or specialized tools such as lvm or mdadm to inspect which devices are visible and what might be missing. For instance, if your encrypted root was not opened, you may not see its decrypted mapping under /dev/mapper. If a driver module is missing, relevant hardware may not appear in /dev or in dmesg output.

The kernel command line, provided by the bootloader, matters a lot here. Parameters such as root=/dev/... or root=UUID=... tell the initramfs scripts where to look for the real root filesystem. If this parameter is wrong or outdated, for example because device names changed or you replaced a disk, the initramfs environment will keep looking for a non‑existent device. Checking /proc/cmdline inside the emergency shell can reveal such misconfigurations.

Misconfigured initramfs images may also miss required modules or hooks. In that case, rebuilding the image after fixing your configuration is usually the solution.

initramfs and Memory Usage

The initramfs filesystem resides in RAM, which raises natural questions about memory usage. At boot, the kernel unpacks the cpio archive into a tmpfs instance. The size of the archive and the unpacked filesystem affects how much RAM is temporarily used during this phase.

For most desktop and server systems this overhead is small compared to total memory, but on very memory constrained systems such as embedded devices or small virtual machines, the initramfs footprint may matter. Tools like dracut and mkinitcpio try to minimize the contents of the image by including only what they detect as necessary. In some cases you may explicitly control which modules and hooks are included or excluded to reduce size.

Once the boot process finishes and the root has been switched, some or all of the initramfs memory can be freed. However, the details of exactly how and when memory is reclaimed depend on the kernel and how initramfs was implemented. The important point is that the initramfs environment is transient and not meant to be kept for normal system operation.

Summary

The initramfs is the kernel’s early user space. It provides a small, flexible environment in RAM that prepares all the conditions needed to mount the real root filesystem. By including the right modules, tools, and scripts, initramfs supports complex storage, encryption, and network boot scenarios without requiring a monolithic kernel.

Understanding initramfs helps explain why some boot problems occur and how to fix them. Knowing how your distribution builds and uses initramfs also gives you the ability to customize early boot behavior when necessary, for example to support unusual hardware or advanced storage layouts.