Stage 4 — initrd / initramfs: Preparing the System to Mount the Root Filesystem

By the end of the previous stage, the Linux kernel is fully operational.

It has:

initialized the processor,

taken control of memory management,

started its internal subsystems,

detected hardware,

initialized built-in device drivers.

Despite all of this progress, the system still cannot boot completely.

One critical problem remains.

The kernel still does not know how to access the real root filesystem.

This may sound surprising.

After all, the kernel was loaded from the disk.

Shouldn't it already know where the operating system is?

The answer is:

Not necessarily.

Modern Linux systems often place the root filesystem behind one or more abstraction layers.

For example:

Disk
 │
 ▼
RAID
 │
 ▼
LVM
 │
 ▼
Filesystem
 │
 ▼
Root (/)

Disk
 │
 ▼
Multipath
 │
 ▼
LVM
 │
 ▼
Filesystem
 │
 ▼
Root (/)

or even

SAN Storage
 │
 ▼
Fibre Channel
 │
 ▼
Multipath
 │
 ▼
LVM
 │
 ▼
XFS
 │
 ▼
Root (/)

At this moment, the kernel has not yet assembled these storage layers.

It cannot simply mount /.

Something else must prepare the environment first.

That "something" is the Initial RAM Disk, commonly known as initrd or initramfs.

Why Does initrd Exist?

To understand why initrd exists, let's look at the history of Linux.

In the early days, Linux systems were much simpler.

A typical machine looked like this:

IDE Disk
    │
    ▼
ext2 Filesystem
    │
    ▼
Root Filesystem

The kernel already contained all required drivers.

Booting was straightforward.

Kernel

↓

Mount Root

↓

Start init

No temporary filesystem was necessary.

As Linux evolved, systems became significantly more complex.

Modern enterprise servers may use:

Software RAID

Hardware RAID

Multipath

Fibre Channel SAN

iSCSI

NVMe

Encrypted disks (LUKS)

Network boot

Bundling every possible driver into the kernel would make it unnecessarily large and difficult to maintain.

Instead, Linux adopted a modular design.

Only essential components remain built into the kernel.

Additional modules are loaded during early boot from a temporary filesystem.

That temporary filesystem is initrd (or, on modern systems, initramfs).

initrd vs initramfs

Although the terms are often used interchangeably, they are not identical.

initrd	initramfs
Older implementation	Modern implementation
Block device backed	RAM filesystem
Used heavily by RHEL 5 and older distributions	Used by modern Linux distributions
Typically created with `mkinitrd`	Typically created with `dracut`
Less flexible	More flexible and efficient

Because this series includes both legacy and modern Linux systems, we will use the term initrd when discussing older environments such as RHEL 5, and initramfs when referring to newer systems.

What Is Inside initrd?

Many administrators think of initrd as a mysterious binary blob.

In reality, it is simply a compressed filesystem image containing everything needed to prepare the system for mounting the real root filesystem.

Typical contents include:

/init
/bin
/sbin
/lib
/lib/modules
/dev
/proc
/sys

More importantly, it contains:

Storage drivers

Filesystem drivers

LVM tools

RAID utilities

Multipath utilities

Device mapper support

udev components

Think of initrd as a miniature Linux system whose only purpose is to prepare the real Linux system.

Boot Flow with initrd

Once the kernel has completed its initialization, it unpacks the initrd into memory.

The process now looks like this:

GRUB
 │
 ▼
Kernel
 │
 ▼
Unpack initrd
 │
 ▼
Temporary Root Filesystem
 │
 ▼
Execute /init

Notice something important.

The kernel has not mounted the real root filesystem yet.

Instead, it mounts the temporary root filesystem provided by initrd.

From this point onward, the /init program inside initrd becomes responsible for preparing the real storage environment.

What Happens Inside initrd?

This is where most enterprise boot logic takes place.

The /init program performs tasks such as:

Loading additional kernel modules.

Starting udev.

Detecting storage devices.

Loading storage controller drivers.

Detecting RAID arrays.

Activating LVM volume groups.

Starting multipath services.

Locating the root filesystem.

Mounting the real root filesystem.

Switching execution to the real system.

A simplified workflow looks like this:

Kernel
    │
    ▼
Execute /init
    │
    ▼
Load Modules
    │
    ▼
Detect Storage
    │
    ▼
Activate LVM
    │
    ▼
Locate Root Filesystem
    │
    ▼
Mount Root
    │
    ▼
switch_root

LVM Activation

Let's focus on one of the most important steps.

Many enterprise Linux installations store the root filesystem inside LVM.

For example:

Disk
 │
 ▼
Physical Volume (PV)
 │
 ▼
Volume Group (VG)
 │
 ▼
Logical Volume (LV)
 │
 ▼
XFS / ext4
 │
 ▼
Root Filesystem

The kernel cannot mount:

/dev/mapper/vg_root-lv_root

unless the Volume Group has already been activated.

That activation happens inside initrd.

Internally, tools equivalent to:

vgscan
vgchange -ay

(or their initramfs equivalents) make the logical volumes available before the root filesystem is mounted.

Without this step, the kernel has no device to mount as /.

Engineering Insight

This explains why LVM-related boot failures almost always appear before the system reaches systemd or the login prompt. If the Volume Group cannot be activated during the initrd stage—because a Physical Volume is missing, metadata is corrupted, or the necessary LVM tools are absent—the root filesystem never becomes available. The kernel is left waiting for a device that does not exist, and the boot process cannot continue.

This is exactly the class of problem we encountered during the RHEL 5.2 recovery after the Acronis restore. The issue was not with the kernel itself, but with the early userspace environment failing to expose the expected storage layout.

Device Discovery

While LVM is being activated, initrd also waits for storage devices to appear.

This includes:

SATA disks

SAS disks

NVMe drives

Fibre Channel LUNs

iSCSI targets

Multipath devices

Enterprise storage may require several seconds before all devices become available.

The initrd environment is responsible for waiting, probing, and assembling these devices before attempting to mount the root filesystem.

switch_root

Once the real root filesystem has been successfully mounted, the temporary initrd environment is no longer needed.

Instead of rebooting or restarting, Linux performs a handoff.

This operation is called switch_root (historically, some systems used pivot_root).

The transition looks like this:

Temporary Root (initrd)
        │
        ▼
Real Root Filesystem
        │
        ▼
switch_root
        │
        ▼
Execute /sbin/init

After this point, the initrd environment is discarded, and the real operating system takes over.

This is the first moment during the boot process where the system begins executing programs from the permanent root filesystem.

Common initrd / initramfs Failures

Because initrd is responsible for preparing the storage stack, failures here are often related to storage, drivers, or root filesystem discovery.

Symptom	Likely Cause
`dracut-initqueue timeout`	Storage device never appeared
`Volume Group not found`	LVM activation failed
`No root device found`	Incorrect `root=` parameter or missing driver
`Kernel panic - unable to mount root fs`	Root filesystem could not be mounted
`Waiting for root device`	Storage initialization incomplete

One important observation is that these errors occur after the kernel has started, but before the real operating system begins. Understanding that distinction helps avoid troubleshooting the wrong component.

Summary

The initrd/initramfs stage bridges the gap between a running kernel and a usable operating system. It provides a temporary userspace where additional drivers can be loaded, storage technologies such as LVM and RAID can be activated, and the real root filesystem can be located and mounted.

Without this stage, many modern Linux systems would be unable to boot because the kernel alone lacks the information required to discover complex storage configurations.