Linux Boot Process Explained: What Initramfs Does

Updated on Sep 27, 2026

10 min read

The Linux boot process with initramfs is the sequence that takes a machine from firmware startup to a usable operating system. It matters when a kernel update fails, an encrypted disk will not unlock, or Linux cannot find its root filesystem. This guide follows the handoff from firmware and bootloader through the kernel’s early userspace, explains what initramfs does, and shows how to inspect it without making a working system harder to recover.

What Is Initramfs?

An initramfs is an archive of files that the Linux kernel makes available as an initial, temporary userspace during startup. It commonly contains an early /init program, kernel modules, device-discovery tools, and scripts for locating and mounting the actual root filesystem. The kernel documentation describes how an initramfs archive populates the kernel’s initial root filesystem; the Linux kernel documentation on ramfs, rootfs, and initramfs explains the mechanism in detail.

The Linux kernel project is the operating-system kernel, not a complete distribution. A distribution combines that kernel with a bootloader, userspace tools, service manager, and other components. Initramfs connects the kernel to enough of those userspace tools to reach the installed system. It is not normally the user’s permanent root filesystem.

The name can be confusing. An initramfs is typically a cpio archive, often compressed, that the kernel unpacks into its initial root filesystem. Initrd originally referred to an initial RAM disk: a block-device image loaded into memory and mounted during boot. Modern distributions may call a file initrd.img even when its contents use the newer initramfs format, so a filename alone does not identify the implementation.

The Problem Initramfs Solves

The kernel needs to mount the real root filesystem before it can start the normal system manager and services. But the storage device or filesystem holding that root may depend on code that is not built directly into the kernel. For example, a machine may need a storage-controller driver, software RAID assembly, LVM volume activation, disk encryption, or a network connection before the root device is reachable.

That creates a startup dependency: Linux needs files from the root filesystem to load the component that makes the root filesystem accessible. Initramfs breaks the cycle by providing a small environment that is available before the real root is mounted. It can load required modules, discover hardware, unlock or assemble storage, and then hand control to the installed system.

Without this early environment, a kernel can still boot when all necessary drivers are built in and the root device is immediately accessible. Initramfs is common because distribution kernels support a wide range of hardware and installation layouts without compiling every possible driver into every kernel.

How the Linux Boot Process Works

The details vary by hardware, bootloader, and distribution, but the main handoffs are consistent:

Firmware selects a boot program. BIOS or UEFI firmware initializes enough hardware to select a boot entry or device. Firmware behavior is separate from Linux userspace.
The bootloader loads the kernel and boot data. A bootloader such as GRUB loads a Linux kernel image, usually an initramfs image, and a kernel command line into memory. The Linux x86 boot protocol documents the x86-specific interface between a bootloader and the kernel; other processor architectures have their own boot conventions.
The kernel initializes. The kernel decompresses if necessary, configures core facilities, initializes built-in drivers, and processes the command line. The root= parameter may identify the intended root device by a path, UUID, or another supported identifier.
The kernel prepares early userspace. It unpacks the initramfs archive into its initial root filesystem. If an executable /init is present, the kernel runs it as process ID 1 for this early stage. The initramfs may load additional modules and use tools such as udev to discover devices.
Early userspace finds the real root. Its scripts interpret the boot configuration, wait for devices when needed, assemble storage, unlock encrypted volumes, and mount the selected root filesystem. The mount location and exact commands depend on the distribution’s initramfs implementation.
Control moves to the installed system. Early userspace changes the process root to the mounted system, commonly with switch_root or a related mechanism, and executes the system’s init program. On many distributions that program is systemd, but Linux systems can use other init systems.

The key distinction is between the kernel’s initial root filesystem and the real root filesystem on disk or over a network. Linux always has an initial rootfs available; initramfs files populate it so that early userspace can do the work required to mount the real root. The Filesystem Hierarchy Standard describes conventional directory locations such as /boot, but the bootloader configuration determines which specific kernel and initramfs files a machine loads.

Term	What it is	Role in startup	Is it usually the installed root?
Initramfs	A `cpio` archive unpacked into the kernel’s initial rootfs	Supplies early userspace and tools to locate the root	No
Legacy initrd	A block-device image loaded into memory and mounted temporarily	Older approach to providing an initial environment	No
Initial rootfs	The kernel’s always-present root filesystem in memory	Holds built-in or unpacked early files	No
Real root filesystem	The installed system’s filesystem, on local or network storage	Becomes the environment used for normal operation	Yes

Components and Key Concepts

The initramfs image and its generator

The image combines files needed before the real root is available. Its contents are generated for a particular kernel and machine configuration. Common tools include initramfs-tools on Debian-derived systems, dracut on Fedora and many other distributions, and mkinitcpio on Arch Linux. The dracut manual documents its image-generation options. These tools differ in configuration, hooks, and default contents; use the documentation for the installed distribution rather than assuming one command applies everywhere.

Early userspace and `/init`

The /init program in the archive is not the same file as the init program on the real root. It runs first and coordinates the handoff. It may load modules, create or wait for device nodes, read a root-device identifier, prompt for a disk passphrase, and mount the root filesystem. A minimal recovery shell may also be provided when automatic discovery fails.

Kernel modules and root-device discovery

Drivers needed only for the root device must be available early. The initramfs can include modules for a storage controller, filesystem, encryption layer, or virtualized hardware. The kernel command line and distribution-specific configuration tell early userspace what to mount. A stale UUID, missing driver, or omitted encryption hook can therefore prevent the transition even though the kernel itself started correctly.

The handoff to PID 1

During early startup, /init runs as PID 1. Once it has mounted the installed root, it replaces itself with the system’s normal init process. This is the point where the boot process enters the service-management stage. The subsequent unit and target relationships on systemd-based machines are covered in our systemd architecture explainer.

Real-World Uses

Encrypted disks: Early userspace asks for a passphrase or obtains a key, opens the encrypted device, and exposes the filesystem underneath.
LVM and software RAID: The image discovers and assembles logical volumes or arrays before mounting a root volume stored inside them.
Hardware variation: A general-purpose distribution image can include modules for storage and filesystems that are not built into the kernel.
Network or specialized roots: A diskless machine or appliance can configure networking and locate a root filesystem that is not on a local disk.
Recovery: A boot-time shell can provide limited tools to diagnose missing devices, incorrect root parameters, or a broken filesystem before the normal system starts.

These cases explain why initramfs is part of the system’s boot-critical configuration, not merely a duplicate copy of the kernel. The permanent directory tree that becomes / after the handoff is described in our guide to the Linux filesystem hierarchy.

Getting Started: Inspect and Rebuild Safely

Start with read-only checks on a running Linux system. These show the running kernel, the command line passed at boot, the mounted root, and available storage identifiers:

uname -r
cat /proc/cmdline
findmnt /
lsblk -f

On systems using systemd, inspect kernel messages from the current boot:

journalctl -b -k --no-pager

The initramfs inspection command and image path vary by distribution. For example, Debian- and Ubuntu-based systems commonly use:

lsinitramfs "/boot/initrd.img-$(uname -r)" | head -n 40

Fedora- and dracut-based systems commonly use:

lsinitrd "/boot/initramfs-$(uname -r).img" | head -n 40

If the image is missing a required module or hook, first review the distribution’s configuration and confirm which kernel the bootloader actually selects. A rebuild changes a boot-critical file; keep a known-good kernel entry and recovery media available. On Debian-derived systems, the usual update command for the running kernel is:

sudo update-initramfs -u -k "$(uname -r)"

On a dracut-based system, the equivalent operation is commonly:

sudo dracut --force --kver "$(uname -r)"

Do not run both commands or copy them to another distribution. Check the tool’s local manual and vendor instructions, especially on systems that use unified kernel images or custom boot layouts. After a rebuild, verify that the expected image exists and that the bootloader entry points to it before rebooting.

If startup fails, record the complete error before changing configuration. For a message such as “waiting for root device,” check that the root identifier in the boot entry matches lsblk -f, and determine whether the relevant storage, filesystem, encryption, or RAID support is present in the initramfs. An emergency shell may offer only a small set of commands, so its available tools can differ from those on a normal boot. Avoid deleting old kernel images or changing several boot parameters at once; keeping one known-good entry makes recovery and comparison safer.

Common Misconceptions

“Initramfs is the Linux kernel.” It is an archive of userspace files the kernel loads for early startup. The kernel and the initramfs are separate components even when a distribution packages them together.
“Every Linux machine needs an initramfs.” A kernel can mount an immediately accessible root using built-in drivers without one. Distributions commonly use initramfs to support diverse hardware and more complex storage configurations.
“The file must be named initramfs to use that format.” Names such as initrd.img persist for compatibility and convention. Inspect the image with the distribution’s tools rather than inferring its format from the filename.
“A successful initramfs boot means the root filesystem is healthy.” It only means early userspace managed to hand off control. Later mount, filesystem, service, or kernel failures can still occur; see our guide to system crashes and kernel panics for diagnosing failures after startup.

Changelog

Initial publication; boot behavior and tooling checked against the linked kernel documentation.