**** boot core diy document good initramfs initrd kernel learning_from_vmware_interview linux linux-reference minipc net on sysadmin

My tags:

From Wikipedia, the free encyclopedia

The initial ramdisk, or initrd is a temporary file system commonly used in the boot process of the Linux kernel. It is typically used for making preparations before the real root file system can be mounted.

Contents 1 Rationale 2 Implementation 3 Other uses 4 References 5 External links

[edit] 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, a network file system (NFS is common on diskless computers), 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 system 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 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]

[edit] Implementation

An image of this initial root file system (along with the kernel image) must 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 (a boot partition)
• A filesystem on CD in case of Live CDs
• A TFTP server (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 (optionally gzip-compressed) file system image, then it will be made available as a special block device (/dev/ram), which is then mounted as the initial root file system.^[3] The driver for that file system must be compiled statically into the kernel. Many distributions originally used compressed ext2 file systems as initrd images. Others (including Debian 3.1) used cramfs in order to boot on memory-limited systems, since the cramfs image can be mounted in-place without requiring extra space for decompression.

Once the initial root file system is up, the kernel executes /linuxrc (linux run command) as its first process. When it exits, the kernel assumes that /linuxrc has mounted the real root file system and executes "/sbin/init" to begin the normal user-space boot process.^[3]

• If the image is a gzip-compressed cpio archive, it will be unpacked by the kernel in an intermediate step into an initramfs (a special instance of a tmpfs available in Linux 2.6.13 onwards), which then becomes the initial root file system. It has the advantage of not requiring an intermediate file system to be compiled into the kernel.^[4]

On an initramfs, the kernel executes /init as its first process. /init is not expected to exit.

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

Other 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:

• 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.
• 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.
  • 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 logical volume, the LVM utilities must be invoked to scan for and activate the volume group containing it.
• If the root file system is on an encrypted block device:
  • 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).
  • Create a decryption target with the device mapper.
• Perform any maintenance tasks which cannot otherwise be safely done on a mounted root file system.
• Mount the root file system read-only.

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, it 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.^[5] 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.^[6]

[edit] Other uses

Fedora, SUSE Linux and Ubuntu use the initrd to paint a bootsplash animation onto the display early on in the boot process.

[edit] References

[edit] External links

• Detailed comparison of initrd-generating toolkits
• Kernel documentation on early userspace support