initrd

In computing, initrd (initial ramdisk) is a scheme for loading a temporary file system into memory in the boot process of the Linux kernel. initrd and initramfs refer to slightly different methods of achieving this. Both are commonly used to make preparations before the real root file system can be mounted.

Contents

Rationale

Many Linux distributions ship a single, generic kernel image that is intended to boot as wide a variety of hardware as possible. The device drivers for this generic kernel image are included as loadable modules, as it is not possible to statically compile them all into the one kernel without making it too large to boot from computers with limited memory or from lower-capacity media like floppy disks.[1]

This then raises the problem of detecting and loading the modules necessary to mount the root file system at boot time (or, for that matter, deducing where or what the root file system is).[1]

To further complicate matters, the root file system may be on a software RAID volume, LVM, NFS (on diskless workstations), or on an encrypted partition. All of these require special preparations to mount.[2]

Another complication is kernel support for hibernation, which suspends the computer to disk by dumping an image of the entire contents of memory to a swap partition or a regular file, then powering off. On next boot, this image has to be made accessible before it can be loaded back into memory.

To avoid having to hardcode handling for so many special cases into the kernel, an initial boot stage with a temporary root file system—now dubbed early user space—is used. This root file system would contain user-space helpers that would do the hardware detection, module loading and device discovery necessary to get the real root file system mounted.[2]

Implementation

An image of this initial root file system (along with the kernel image) must be stored somewhere accessible by the Linux bootloader or the boot firmware of the computer. This can be:

The bootloader will load the kernel and initial root file system image into memory and then start the kernel, passing in the memory address of the image. At the end of its boot sequence, the kernel tries to determine the format of the image from its first few blocks of data:

Once the initial root file system is up, the kernel executes /linuxrc as its first process. When it exits, the kernel assumes that the real root file system has been mounted and executes "/sbin/init" to begin the normal user-space boot process.[3]
On an initramfs, the kernel executes /init as its first process. /init is not expected to exit.

Depending on which algorithms were compiled statically into it, the kernel can currently unpack initrd/initramfs images compressed with gzip, bzip2, LZMA and XZ.

Mount preparations

Some Linux distributions will generate a customized initrd image which contains only whatever is necessary to boot some particular computer, such as ATA, SCSI and filesystem kernel modules. These typically embed the location and type of the root file system.

Other Linux distributions (such as Fedora and Ubuntu) generate a more generic initrd image. These start only with the device name of the root file system (or its UUID) and must discover everything else at boot time. In this case, a complex cascade of tasks must be performed to get the root file system mounted:

Some distributions use an event-driven hotplug agent such as udev, which invokes helper programs as hardware devices, disk partitions and storage volumes matching certain rules come online. This allows discovery to run in parallel, and to progressively cascade into arbitrary nestings of LVM, RAID or encryption to get at the root file system.

When the root file system finally becomes visible:

The final root file system cannot simply be mounted over /, since that would make the scripts and tools on the initial root file system inaccessible for any final cleanup tasks:

Most initial root file systems implement /linuxrc or /init as a shell script and thus include a minimal shell (usually /bin/ash) along with some essential user-space utilities (usually the BusyBox toolkit). To further save space, the shell, utilities and their supporting libraries are typically compiled with space optimizations enabled (such as with gcc's "-Os" flag) and linked against klibc, a minimal version of the C library written specifically for this purpose.[6]

Other uses

Installers for Linux distributions are typically run entirely from an initramfs, as they must be able to host the installer interface and supporting tools before any persistent storage has been set up.

Tiny Core Linux also runs from initrd.[7]

Puppy Linux also runs from initrd.[8]

See also

References

  1. ^ a b Almesberger, Werner (2000), "Booting linux: the history and the future", Proceedings of the Ottawa Linux Symposium, http://www.linuxsymposium.org/2000/booting.php 
  2. ^ a b Landley, Rob (15 March 2005), Introducing initramfs, a new model for initial RAM disks, linuxdevices.com, http://linuxdevices.com/articles/AT4017834659.html 
  3. ^ a b Almesberger, Werner; and Lermen, Hans (2000), http://www.kernel.org/doc/Documentation/initrd.txt 
  4. ^ Landley, Rob (2005-10-17), ramfs, rootfs, and initramfs docs, take 2, Linux kernel source tree, http://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt 
  5. ^ Fish, Richard (2005-07-06), pivot_root from initramfs causes circular reference in mount tree, Linux Kernel Bug Tracker, http://bugzilla.kernel.org/show_bug.cgi?id=4857, retrieved 2009-02-28 
  6. ^ Garzik, Jeff (2002-11-02), initramfs merge, part 1 of N, Linux kernel mailing list, http://lkml.org/lkml/2002/11/2/17 
  7. ^ http://distro.ibiblio.org/tinycorelinux/concepts.html
  8. ^ http://distro.ibiblio.org/puppylinux/puppy-5.3/release-Slacko-5.3.htm

External links