Initial ramdisk

In

Many Linux distributions ship a single, generic Linux kernel image – one that the distribution's developers create specifically to boot on a wide variety of hardware. The device drivers for this generic kernel image are included as loadable kernel modules because statically compiling many drivers into one kernel causes the kernel image to be much larger, perhaps too large to boot on computers with limited memory, or in some cases to cause boot-time crashes or other problems due to probing for nonexistent or conflicting hardware. This static-compiled kernel approach also leaves modules in kernel memory which are no longer used or needed, and 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

An

• Any hardware drivers that the boot process depends on must be loaded. A common arrangement is to pack kernel modules for common storage devices onto the initrd and then invoke a
  hotplug
  agent to pull in modules matching the computer's detected hardware.
• On systems which display a boot splash screen, the video hardware must be initialized and a user-space helper started to paint animations onto the display in lockstep with the boot process.
• If the root file system is on NFS, it must then bring up the primary
  network interface, invoke a DHCP
  client, with which it can obtain a DHCP lease, extract the name of the NFS share and the address of the NFS server from the lease, and mount the NFS share.
• If the root file system appears to be on a software RAID device, there is no way of knowing which devices the RAID volume spans; the standard MD utilities must be invoked to scan all available block devices and bring the required ones online.
• If the root file system appears to be on a
  volume group
  containing it.
• If the root file system is on an encrypted block device, the software needs to invoke a helper script to prompt the user to type in a passphrase and/or insert a hardware token (such as a smart card or a USB security dongle), and then create a decryption target with the device mapper.

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, any maintenance tasks that cannot run on a mounted root file system are done, the root file system is mounted read-only, and any processes that must continue running (such as the splash screen helper and its command FIFO) are hoisted into the newly mounted root file system.

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:

• On an initrd, the new root is mounted at a temporary mount point and rotated into place with pivot_root(8) (which was introduced specifically for this purpose). This leaves the initial root file system at a mount point (such as /initrd) where normal boot scripts can later unmount it to free up memory held by the initrd.
• On an initramfs, the initial root file system cannot be rotated away.^[10] Instead, it is simply emptied and the final root file system mounted over the top.

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.^[11]

Other uses

Installers for Linux distributions 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.^{[citation needed]}

Tiny Core Linux^[12] and Puppy Linux^{[13][failed verification]} can run entirely from initrd.

Similarities in other operating systems

This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources in this section. Unsourced material may be challenged and removed. (August 2015) (Learn how and when to remove this message)

Since Windows Vista,^[14] Windows can boot from a WIM disk image file, for which the file format is published;^[15] it is similar to the ZIP format except that it supports hard links, deduplicated chunks, and uses chunk-by-chunk compression. In this case, the whole WIM is initially loaded into RAM, followed by the kernel initialisation. Next, the loaded WIM is available as a SystemRoot with an assigned drive letter. The Windows installer uses this so it boots from BOOT.WIM, and then uses INSTALL.WIM as the collection of the Windows files to be installed.

Also, Windows Preinstallation Environment (Windows PE) uses the same, being a base for separate-boot versions of some antivirus and backup/disaster recovery software.

It is also possible to install Windows so that it will always boot from a WIM or VHD file placed on a physical drive. However, this is rarely used since the Windows boot loader is capable of loading the .sys files for boot-time kernel modules itself, which is the task that requires initrd in Linux.

See also

• dracut
• booster initramfs generator
• Linux startup process
• List of Linux distributions that run from RAM
• EFISTUB booting allows EFI firmware to load a Linux kernel (Arch Linux Wiki)

References