L32: initramfs: Solving the Linux Kernel Boot Problem

 

EmbeddedPathashala  ›  Free Linux Kernel Programming Course  ›  Chapter 3

initramfs: Solving the Linux Kernel Boot Problem

Why does Linux need a tiny filesystem in RAM before it can read your disk? The answer is one of the most elegant tricks in systems programming.

📘 Lecture 32
⏰ 12 min read
🐧 Kernel 6.x Updated

Topics Covered

initramfs
initrd
cpio archive
chicken-and-egg boot
kernel modules
mkinitramfs
dracut
switch_root
CONFIG_BLK_DEV_INITRD
embedded initramfs

What You Will Learn

  • The exact chicken-and-egg problem that makes Linux booting non-trivial
  • What initramfs is, why it exists, and what it physically contains
  • How the bootloader, kernel, and initramfs hand off to each other
  • Tools that build the initramfs image on Ubuntu, Fedora, and Arch
  • How embedded systems use initramfs differently from desktops

📷 Suggested Image for This Post

A side-by-side diagram showing a locked disk on the left (labelled “ext4.ko lives here”) and a RAM chip on the right (labelled “kernel running here”) with a red crossed arrow between them. Below it, the initramfs image in RAM acting as a bridge. Alt text: Linux initramfs boot problem diagram showing chicken and egg deadlock.

The Chicken-and-Egg Problem

When Linux starts up, the kernel needs to mount the root filesystem — the partition that holds /bin, /etc, /lib, and everything else. To mount a filesystem like ext4 or btrfs, the kernel needs the right filesystem driver loaded as a kernel module.

Here is the problem: those kernel module files are stored inside the root filesystem, under /lib/modules/<kernel-version>/kernel/fs/. So the kernel needs the module to mount the disk, but the module is on the disk it cannot yet read.

The Deadlock in plain words:
Mount root filesystem → needs ext4.ko loaded.
Load ext4.ko → needs root filesystem mounted.
Neither can happen first. Classic deadlock.

The Chicken-and-Egg Boot Deadlock

KERNEL (in RAM)

Running, but cannot read disk yet

❓ Needs to mount root FS

❓ Needs ext4.ko first

🚫

DEADLOCK

ROOT FILESYSTEM (on disk)

Cannot be read — no driver

/lib/modules/6.x/kernel/fs/

ext4.ko ← locked away

📌 Kernel version note: Old textbooks and courses use reiserfs.ko as the example here. ReiserFS was removed from the Linux kernel entirely in version 6.6 (October 2023). The module that matters on modern systems is ext4.ko, btrfs.ko, or xfs.ko — same problem, different name.

The Solution — initramfs

The Linux developers solved this elegantly. The idea: bring a tiny pre-built filesystem with you, packed into RAM, that already has the module you need.

This is initramfs — short for initial RAM filesystem. You may also see it called initrd (initial RAM disk), which was the older name for a similar mechanism. On modern kernels, initramfs is always used internally, even if the image file is still called initrd.img.

How initramfs Breaks the Deadlock

1
Bootloader loads both images into RAM
vmlinuz-6.x.y (compressed kernel) + initrd.img-6.x.y (cpio archive)

2
Kernel unpacks initramfs in RAM as a mini root filesystem
Contains: /bin (busybox), /lib/modules/6.x/fs/ext4.ko, /scripts/init

3
Init scripts load ext4.ko from this RAM filesystem
Now the kernel has the filesystem driver it needs — from RAM, no disk needed

4
✓ Kernel mounts the real root filesystem from disk
Deadlock broken. Real / is now available.

5
switch_root — discard RAM mini-FS, hand off to systemd
RAM freed, real disk / takes over, PID 1 (systemd) starts

What Does initramfs Actually Contain?

The initramfs image is a cpio archive — think of it like a tar file, just a different format. It is usually compressed with gzip or lz4. When the kernel unpacks it into RAM, it looks like a small but functional Linux root filesystem.

Typical Contents of an initramfs Image

/ (initramfs root in RAM)
├── bin/        ← busybox shell + basic tools (ls, mount, insmod…)
├── etc/        ← minimal config (fstab, crypttab if encrypted)
├── lib/
│   └── modules/6.x.y/kernel/fs/
│        └── ext4.ko   ← THE module that breaks the deadlock
│        └── dm-crypt.ko (if encrypted disk)
├── scripts/   ← shell scripts that orchestrate the whole process
└── init        ← entry point — first thing the kernel runs here

The important thing to remember: this is not a full Linux system. It contains only what is strictly necessary to reach the point where the real root filesystem can be mounted.

Where Does the initramfs Image Come From?

When you install or update a kernel package, the package manager automatically rebuilds the initramfs. The tool used depends on your Linux distribution.

initramfs Build Tools by Distribution

Distribution Tool Output file in /boot
Ubuntu / Debian update-initramfsmkinitramfs initrd.img-6.x.y
Fedora / RHEL / openSUSE dracut initramfs-6.x.y.img
Arch Linux mkinitcpio initramfs-linux.img

Want to see what is packed inside yours? On Ubuntu:

# List all files in your current initramfs
lsinitramfs /boot/initrd.img-$(uname -r)

# Filter to show only kernel modules packed inside
lsinitramfs /boot/initrd.img-$(uname -r) | grep "\.ko"

# Manually unpack it to explore (safe — read only)
mkdir /tmp/myinitramfs
cd /tmp/myinitramfs
zcat /boot/initrd.img-$(uname -r) | cpio -idmv 2>/dev/null
ls -la
💡 Try it: Run the lsinitramfs command on your own Ubuntu system. You will find ext4.ko, driver modules for your specific hardware, and the init scripts. It gives a real feel for how minimal this filesystem actually is.

Other Situations Where initramfs Is Essential

The root filesystem driver problem is the original reason initramfs exists, but modern Linux systems use it for several other critical tasks too.

🔒 Encrypted Disks (LUKS)

If your disk is encrypted using LUKS (Linux Unified Key Setup), the kernel must prompt you for a passphrase before it can read anything. To show that prompt and accept input, it needs a working terminal and the cryptsetup tool. Both live in the initramfs. Without initramfs, full-disk encryption on Linux would not be possible.

📁 LVM and Software RAID

If your root partition lives inside an LVM (Logical Volume Manager) group or a software RAID array, the device mapper modules and the lvm2 or mdadm tools must run first to assemble the logical volume. All of this happens inside initramfs before the real root can be accessed.

🌎 Network Root (NFS / iSCSI)

On servers and embedded systems, the root filesystem sometimes lives on a remote machine — mounted over NFS or accessed via iSCSI. The initramfs brings up the network interface, configures an IP address, and connects to the remote storage — all before handing off to the main system.

initramfs on Embedded Linux Systems

On embedded devices like Raspberry Pi, industrial controllers, and automotive ECUs, initramfs works slightly differently. Rather than being a separate file on disk, it is often compiled directly into the kernel binary during the build.

# Kernel config option that embeds initramfs into the kernel image itself
CONFIG_INITRAMFS_SOURCE="/path/to/rootfs_staging_directory"

# Check what your current kernel has configured:
grep INITRAMFS /boot/config-$(uname -r)

Desktop vs Embedded — initramfs Deployment

Desktop / Server

/boot/ on disk

vmlinuz-6.x.y

initrd.img-6.x.y ← separate file

GRUB loads both separately into RAM

Embedded (ARM/RISC-V)

Single image on flash/eMMC

uImage / Image

↳ initramfs built in ← no separate file

U-Boot loads one binary; kernel unpacks its own mini-FS

Summary — The Full initramfs Flow

initramfs — Complete Boot Flow Summary

Phase What Happens Who Runs It
Build time mkinitramfs / dracut packs modules + scripts into a cpio.gz distro package manager
Install time /boot/initrd.img-6.x.y placed alongside vmlinuz kernel install hook
Boot: GRUB Loads vmlinuz + initrd.img into RAM, jumps to kernel GRUB2
Boot: Kernel Detects initramfs (CONFIG_BLK_DEV_INITRD=y), unpacks cpio, mounts mini-FS Linux kernel
Boot: /init Loads ext4.ko, finds real root by UUID, mounts it at /root initramfs shell script
switch_root Real FS becomes new /, RAM mini-FS freed, systemd starts as PID 1 switch_root utility

🎯 Frequently Asked Questions — initramfs

Common questions asked in Linux kernel, embedded systems, and device driver interviews.

Q1. What is the chicken-and-egg problem in Linux booting, and how does initramfs solve it?

The kernel needs to load a filesystem driver module (such as ext4.ko) to mount the root filesystem. But that module file is stored inside the root filesystem on disk. You cannot mount the disk without the module, and you cannot get the module without mounting the disk. initramfs breaks this deadlock by providing a compressed mini-filesystem in RAM that already contains the required module. The kernel unpacks this and loads the driver from RAM, then mounts the real disk filesystem.

Q2. What is the difference between initrd and initramfs?

initrd was the original mechanism — it emulated a fixed-size block device in RAM. The kernel mounted it like a real disk, and it had a fixed memory footprint regardless of actual content size. initramfs replaced it — it is a compressed cpio archive that the kernel unpacks directly into a tmpfs (a flexible in-memory filesystem). initramfs does not need a fixed size and is faster. On all modern kernels (2.6.13+), the initramfs mechanism is used internally, even if the image file is still named initrd.img.

Q3. What file format is an initramfs image, and how do you inspect it?

It is a cpio archive compressed with gzip or lz4 (some systems use zstd on newer kernels). On Ubuntu you can inspect it with lsinitramfs /boot/initrd.img-$(uname -r). On Fedora use lsinitrd. Modern Ubuntu systems may also have an early uncompressed section containing CPU microcode, followed by the main compressed cpio section.

Q4. What kernel config option controls initramfs support?

CONFIG_BLK_DEV_INITRD=y enables the kernel to detect and use an initramfs image. This is enabled in virtually all distribution kernels. A separate option, CONFIG_INITRAMFS_SOURCE, allows you to embed an initramfs archive directly into the kernel binary at compile time — commonly used in embedded systems.

Q5. What does switch_root do and how is it different from pivot_root?

switch_root is the modern way to transition from the initramfs environment to the real root filesystem. It moves the new root into place, unmounts and frees the initramfs tmpfs memory, and execs the real init (systemd). The older pivot_root syscall required more manual steps and left the old root mounted somewhere. switch_root (used by busybox and systemd-based initramfs environments) does everything atomically and cleans up RAM automatically.

Q6. Name two scenarios besides the filesystem driver problem where initramfs is required.

(1) Full disk encryption (LUKS) — The cryptsetup tool and a working terminal must be available before the encrypted root can be unlocked and mounted. These live inside initramfs. (2) LVM or software RAID — Device mapper modules and tools like lvm2 or mdadm must assemble the logical volumes before the root partition can even be located. (3) Network root (NFS/iSCSI) — The network interface must be brought up and remote storage connected before handing off to the main system.

Q7. How does an embedded Linux device use initramfs differently from a desktop?

On desktops and servers, initramfs is a separate file (initrd.img-6.x.y) loaded by GRUB from the /boot partition. On embedded devices, initramfs is often compiled into the kernel binary itself using CONFIG_INITRAMFS_SOURCE. The bootloader (typically U-Boot) loads just one binary — the kernel — and that kernel unpacks its own built-in mini-filesystem at boot. This simplifies deployment on devices without complex bootloaders or separate /boot partitions.

Free Linux Kernel Programming Course

EmbeddedPathashala is a completely free learning platform covering Linux kernel programming, BLE, Bluetooth, and embedded systems from the ground up.

Visit EmbeddedPathashala

 

Leave a Reply

Your email address will not be published. Required fields are marked *