< Back to index
The initial ramdisk, or initrd is a temporary file system used by the Linux kernel during boot. The initrd is typically used for making preparations before the real root file system can be mounted. When specified, the boot loader loads the ramdisk into memory and passes it on to the kernel, which temporarily mounts it as root and executes the /linuxrc executable.
Rationale
To simplify security updates and their installation process, many Linux distributions also ship a single, generic kernel image that is intended to boot as wide variety of hardware as possible. The drivers included with this generic kernel image must be modular, as it is not possible to statically compile everything into the one kernel without making it too large to boot from computers with limited memory or from lower-capacity media like floppy disks.
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).
In Linux 2.4 and earlier, the kernel itself handled these with ad-hoc code triggered by special [http://slackware.osuosl.org/slackware-3.3/docs/linux-2.0.30/nfsroot.txt|boot options]. These were often fragile, inflexible and duplicated the functionality already available in user-space utilities.
In Linux 2.6, these have been deprecated in favour of the initrd scheme, which solves this problem by introducing an extra stage in the kernel's boot process. In this stage, a temporary initial root file system, in which user-space tools and programs can be executed, becomes available. The contents of that initial file system are provided by an initrd image.
Implementation
The kernel image and initrd image must both be stored somewhere accessible by the boot firmware of the computer or the Linux bootloader. On PCs, this is usually:
* The root file system itself
* A small ext2 or FAT-formatted partition on a local disk
* TFTP (on systems that can boot from Ethernet)
The bootloader will load the kernel and initrd image into memory and then start the kernel, passing in the memory address of the initrd. At the end of its boot sequence, the kernel tries to determine the format of the image from its first few blocks of data:
* If the image is a gzip-compressed cpio archive, it will be unpacked by the kernel in an intermediate step into a tmpfs, which then becomes the initial root file system.
* If the image is a (optionally gzip-compressed) file system image, then it will be made available as special block devices (/dev/ram). This block device is then mounted as the initial root file system. The driver for that file system must be compiled statically into the kernel. Many distributions use compressed ext2 file systems as initrd images; Debian uses a cramfs file system (which can be used in-place without requiring extra space for decompression) in order to boot on memory-limited systems.
Once the initial root file system is up, the kernel executes "/linuxrc" as its first process. When it exits, the kernel assumes that the the real root file system is in place and executes "/sbin/init" to begin the normal user-space boot process.
The initrd usually contains LKMs required to mount the root filesystem, such as ATA, SCSI or USB LKMs.
Some Linux distributions will generate a customized initrd which contains only the drivers necessary to boot that particular computer: these typically embed the location and type of the root file system in the initrd.
Others (such as Fedora and Ubuntu) generate a more generic initrd. These starts only with the device name of the root file system or its UUID (in the 'root=' boot parameter) and must discover everything else at boot time. With such an initrd, "/linuxrc" must perform a complex cascade of tasks to get the root file system mounted:
* Any hardware drivers that the boot process depends on must be loaded. A common arrangement is to pack kernel modules common storage devices onto the initrd and then for "/linuxrc" to invoke a hotplug agent to pull in modules matching the computer's detected hardware.
* If the root file system is on NFS, "/linuxrc" must:
* * Bring up the primary network interface.
* * Invoke a DHCP client which it can invoke to obtain a DHCP lease.
* * Extract the address of the NFS server from the lease.
* * Mount the NFS share.
* If the root file system appears to be on a software RAID device, "/linuxrc" has no way of knowing which devices the RAID volume spans and must invoke the standard MD utilities to scan all available block devices and bring the required one online.
* If the root file system appears to be on a logical volume, "/linuxrc" must invoke the LVM utilities to scan for and activate the volume group containing it.
"/linuxrc" cannot simply mount the final root file system over "/", since that would make the scripts and tools on the initial root file system inaccessible for any final cleanup tasks. Instead, it is mounted at a temporary mount point and [http://man.linuxquestions.org/index.php?query=pivot_root&type=2§ion=8 pivot_root(8)] is used to rotate it into place. 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.
Most initial root file systems implement "/linuxrc" 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 a stripped-down version of the C library such as dietlibc or klibc.
Some distributions (notably, SUSE Linux and Ubuntu) further use the initrd to paint a bootsplash animation onto the display early on in the boot process.
This entry uses material from from Wikipedia, the leading user-contributed encyclopedia. It is licensed under the GNU Free Documentation License. Disclaimer.