Linux2.6内核的Initrd机制解析

Linux 2.6 内核的Initrd 机制解析1．什么是 Initrdinitrd 的英文含义是 boot loader initialized RAM disk，就是由 boot loader 初始化的内存盘。

在 linux内核启动前， boot loader 会把存储介质中的initrd 文件加载到内存，内核启动时会在访问真正的根文件系统前先访问该内存中的 initrd 文件系统。

在 boot loader 配置了 initrd 的情况下，内核启动被分成了两个阶段，第一阶段先执行 initrd 文件系统中的"某个文件"，完成加载驱动模块等任务，第二阶段才会执行真正的根文件系统中的 /sbin/init 进程。

这里提到的"某个文件"，Linux2.6 内核会同以前版本内核的不同，所以这里暂时使用了"某个文件"这个称呼，后面会详细讲到。

第一阶段启动的目的是为第二阶段的启动扫清一切障爱，最主要的是加载根文件系统存储介质的驱动模块。

我们知道根文件系统可以存储在包括IDE、SCSI、USB在内的多种介质上，如果把这些设备的驱动都编译进内核，可以想象内核会多么庞大、臃肿。

Initrd 的用途主要有以下四种：1. linux 发行版的必备部件linux 发行版必须适应各种不同的硬件架构，把所有的驱动编译进内核是不现实的，initrd 技术是解决该问题的关键技术。

Linux 发行版在内核中只编译了基本的硬件驱动，在安装过程中通过检测系统硬件，生成包含安装系统硬件驱动的initrd，无非是一种即可行又灵活的解决方案。

2. livecd 的必备部件同 linux 发行版相比，livecd 可能会面对更加复杂的硬件环境，所以也必须使用 initrd。

3. 制作 Linux usb 启动盘必须使用 initrdusb 设备是启动比较慢的设备，从驱动加载到设备真正可用大概需要几秒钟时间。

如果把 usb 驱动编译进内核，内核通常不能成功访问 usb 设备中的文件系统。

因为在内核访问 usb 设备时， usb 设备通常没有初始化完毕。

所以常规的做法是，在 initrd 中加载 usb 驱动，然后休眠几秒中，等待 usb设备初始化完毕后再挂载 usb 设备中的文件系统。

4. 在 linuxrc 脚本中可以很方便地启用个性化 bootsplash。

2．Linux2.4内核对 Initrd 的处理流程为了使读者清晰的了解Linux2.6内核initrd机制的变化，在重点介绍Linux2.6内核initrd之前，先对linux2.4内核的 initrd进行一个简单的介绍。

Linux2.4内核的initrd的格式是文件系统镜像文件，本文把其称为image-initrd，以区别后面介绍的linux2.6内核的cpio格式的initrd。

linux2.4内核对initrd 的处理流程如下：1. boot loader把内核以及/dev/initrd的内容加载到内存，/dev/initrd是由boot loader初始化的设备，存储着initrd。

2. 在内核初始化过程中，内核把 /dev/initrd 设备的内容解压缩并拷贝到/dev/ram0 设备上。

3. 内核以可读写的方式把 /dev/ram0 设备挂载为原始的根文件系统。

4. 如果 /dev/ram0 被指定为真正的根文件系统，那么内核跳至最后一步正常启动。

5. 执行 initrd 上的 /linuxrc 文件，linuxrc 通常是一个脚本文件，负责加载内核访问根文件系统必须的驱动，以及加载根文件系统。

6. /linuxrc 执行完毕，真正的根文件系统被挂载。

7. 如果真正的根文件系统存在 /initrd 目录，那么 /dev/ram0 把从 / 移动到/initrd。

否则如果 /initrd 目录不存在， /dev/ram0 把被卸载。

8. 在真正的根文件系统上进行正常启动过程，执行 /sbin/init。

linux2.4 内核的 initrd 的执行是作为内核启动的一个中间阶段，也就是说 initrd 的/linuxrc 执行以后，内核会继续执行初始化代码，我们后面会看到这是linux2.4 内核同 2.6 内核的 initrd 处理流程的一个显著区别。

3．Linux2.6 内核对 Initrd 的处理流程linux2.6 内核支持两种格式的 initrd，一种是前面第 3 部分介绍的 linux2.4 内核那种传统格式的文件系统镜像－image-initrd，它的制作方法同 Linux2.4 内核的 initrd 一样，其核心文件就是 /linuxrc。

另外一种格式的 initrd 是cpio 格式的，这种格式的 initrd 从 linux2.5 起开始引入，使用 cpio 工具生成，其核心文件不再是 /linuxrc，而是 /init，本文把这种 initrd 称为cpio-initrd。

尽管 linux2.6 内核对 cpio-initrd和 image-initrd 这两种格式的 initrd 均支持，但对其处理流程有着显著的区别，下面分别介绍 linux2.6 内核对这两种 initrd 的处理流程。

cpio-initrd 的处理流程1． boot loader 把内核以及 initrd 文件加载到内存的特定位置。

2．内核判断initrd的文件格式，如果是cpio格式。

3．把initrd的内容释放到rootfs中。

4．执行initrd中的/init文件，执行到这一点，内核的工作全部结束，完全交给/init文件处理。

image-initrd的处理流程1． boot loader把内核以及initrd文件加载到内存的特定位置。

2．内核判断initrd的文件格式，如果不是cpio格式，把其作为image-initrd 处理。

3．内核把initrd的内容保存在rootfs下的/initrd.image文件中。

4．内核把/initrd.image的内容读入/dev/ram0设备中，也就是读入了一个内存盘中。

5．接着内核以可读写的方式把/dev/ram0设备挂载为原始的根文件系统。

6． .如果/dev/ram0被指定为真正的根文件系统，那么内核跳至最后一步正常启动。

7．执行initrd上的/linuxrc文件，linuxrc通常是一个脚本文件，负责加载内核访问根文件系统必须的驱动，以及加载根文件系统。

8． /linuxrc执行完毕，常规根文件系统被挂载9．如果常规根文件系统存在/initrd目录，那么/dev/ram0把从/移动到/initrd。

否则如果/initrd目录不存在， /dev/ram0把被卸载。

10．在常规根文件系统上进行正常启动过程，执行/sbin/init。

通过上面的流程介绍可知，Linux2.6内核对image-initrd的处理流程同linux2.4内核相比并没有显著的变化， cpio-initrd的处理流程相比于image-initrd的处理流程却有很大的区别，流程非常简单，在后面的源代码分析中，读者更能体会到处理的简捷。

Using the initial RAM disk (initrd)===================================Written 1996,2000 by Werner Almesberger <werner.almesberger@epfl.ch> and Hans Lermen <lermen@fgan.de>initrd provides the capability to load a RAM disk by the boot loader. This RAM disk can then bemounted as the root file system and programs can be run from it. Afterwards, a new root file system can be mounted from a different device. The previous root (from initrd) is then moved to a directory and can be subsequently unmounted.initrd is mainly designed to allow system startup to occur in two phases, where the kernel comes up with a minimum set of compiled-in drivers, and where additional modules are loaded from initrd.This document gives a brief overview of the use of initrd. A more detailed discussion of the boot process can be found in [1].Operation---------When using initrd, the system typically boots as follows:1) the boot loader loads the kernel and the initial RAM disk 2) the kernel converts initrd intoa "normal" RAM disk and frees the memory used by initrd 3) if the root device is not /dev/ram0, the old (deprecated) change_root procedure is followed. see the "Obsolete root change mechanism" section below. 4) root device is mounted. if it is /dev/ram0, the initrd image is then mounted as root 5) /sbin/init is executed (this can be any valid executable, including shell scripts; it is run with uid 0 and can do basically everything init can do). 6) init mounts the "real" root file system 7) init places the root file system at the root directory using the pivot_root system call 8) init execs the /sbin/init on the new root filesystem, performing the usual boot sequence 9) the initrd file system is removedNote that changing the root directory does not involve unmounting it. It is therefore possible to leave processes running on initrd during that procedure. Also note that file systems mounted under initrd continue to be accessible.Boot command-line options-------------------------initrd adds the following new options:initrd=<path> (e.g. LOADLIN)Loads the specified file as the initial RAM disk. When using LILO, you have to specify the RAM disk image file in /etc/lilo.conf, using the INITRD configuration variable.noinitrdinitrd data is preserved but it is not converted to a RAM disk and the "normal" root file system is mounted. initrd data can be readfrom /dev/initrd. Note that the data in initrd can have any structure in this case and doesn't necessarily have to be a file system image. This option is used mainly for debugging.Note: /dev/initrd is read-only and it can only be used once. As soon as the last process has closed it, all data is freed and /dev/initrdcan't be opened anymore.root=/dev/ram0initrd is mounted as root, and the normal boot procedure is followed, with the RAM disk mounted as root.Compressed cpio images----------------------Recent kernels have support for populating a ramdisk from a compressed cpio archive. On such systems, the creation of a ramdisk image doesn't need to involve special block devicesor loopbacks; you merely create a directory on disk with the desired initrd content, cd to that directory, and run (as an example):find . | cpio --quiet -H newc -o | gzip -9 -n > /boot/imagefile.imgExamining the contents of an existing image file is just as simple:mkdir /tmp/imagefile cd /tmp/imagefile gzip -cd /boot/imagefile.img | cpio -imd --quiet Installation------------First, a directory for the initrd file system has to be created on the "normal" root file system, e.g.# mkdir /initrdThe name is not relevant. More details can be found on the pivot_root(2) man page.If the root file system is created during the boot procedure (i.e. if you're building an install floppy), the root file system creation procedure should create the /initrd directory.If initrd will not be mounted in some cases, its content is still accessible if the following device has been created:# mknod /dev/initrd b 1 250 # chmod 400 /dev/initrdSecond, the kernel has to be compiled with RAM disk support and with support for the initial RAM disk enabled. Also, at least all components needed to execute programs from initrd (e.g. executable format and file system) must be compiled into the kernel.Third, you have to create the RAM disk image. This is done by creating a file system on a block device, copying files to it as needed, and then copying the content of the block device to the initrd file. With recent kernels, at least three types of devices are suitable for that:- a floppy disk (works everywhere but it's painfully slow)- a RAM disk (fast, but allocates physical memory)- a loopback device (the most elegant solution)We'll describe the loopback device method:1) make sure loopback block devices are configured into the kernel 2) create an empty file system of the appropriate size, e.g. # dd if=/dev/zero of=initrd bs=300k count=1 # mke2fs -F -m0 initrd(if space is critical, you may want to use the Minix FS instead of Ext2) 3) mount the file system, e.g. # mount -t ext2 -o loop initrd /mnt 4) create the console device: # mkdir /mnt/dev# mknod /mnt/dev/console c 5 1 5) copy all the files that are needed to properly use the initrd environment. Don't forget the most important file, /sbin/initNote that /sbin/init's permissions must include "x" (execute). 6) correct operation the initrd environment can frequently be tested even without rebooting with the command # chroot /mnt /sbin/initThis is of course limited to initrds that do not interfere with the general system state (e.g. by reconfiguring network interfaces, overwriting mounted devices, trying to start already running demons,etc. Note however that it is usually possible to use pivot_root in such a chroot'ed initrd environment.) 7) unmount the file system # umount /mnt 8) the initrd is now in the file "initrd". Optionally, it can now be compressed# gzip -9 initrdFor experimenting with initrd, you may want to take a rescue floppy and only add a symbolic link from /sbin/init to /bin/sh. Alternatively, you can try the experimental newlib environment [2] to create a small initrd.Finally, you have to boot the kernel and load initrd. Almost all Linux boot loaders support initrd. Since the boot process is still compatible with an older mechanism, the following boot command line parameters have to be given:root=/dev/ram0 rw(rw is only necessary if writing to the initrd file system.)With LOADLIN, you simply executeLOADLIN <kernel> initrd=<disk_image> e.g. LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0 rwWith LILO, you add the option INITRD=<path> to either the global section or to the section of the respective kernel in /etc/lilo.conf, and pass the options using APPEND, e.g.image = /bzImage initrd = /boot/initrd.gzappend = "root=/dev/ram0 rw"and run /sbin/liloFor other boot loaders, please refer to the respective documentation.Now you can boot and enjoy using initrd.Changing the root device------------------------When finished with its duties, init typically changes the root device and proceeds with starting the Linux system on the "real" root device.The procedure involves the following steps:- mounting the new root file system- turning it into the root file system- removing all accesses to the old (initrd) root file system- unmounting the initrd file system and de-allocating the RAM diskMounting the new root file system is easy: it just needs to be mounted on a directory under the current root. Example:# mkdir /new-root # mount -o ro /dev/hda1 /new-rootThe root change is accomplished with the pivot_root system call, which is also available via the pivot_root utility (see pivot_root(8) man page; pivot_root is distributed with util-linux version 2.10h or higher [3]). pivot_root moves the current root to a directory under the new root, and puts the new root at its place. The directory for the old root must exist before calling pivot_root. Example:# cd /new-root # mkdir initrd # pivot_root . initrdNow, the init process may still access the old root via its executable, shared libraries, standard input/output/error, and its current root directory. All these references are dropped by the following command:# exec chroot . what-follows <dev/console >dev/console 2>&1Where what-follows is a program under the new root, e.g. /sbin/init If the new root file system will be used with udev and has no valid /dev directory, udev must be initialized before invoking chroot in order to provide /dev/console.Note: implementation details of pivot_root may change with time. In order to ensurecompatibility, the following points should be observed:- before calling pivot_root, the current directory of the invoking process should point to the new root directory- use . as the first argument, and the _relative_ path of the directory for the old root as the second argument- a chroot program must be available under the old and the new root- chroot to the new root afterwards- use relative paths for dev/console in the exec commandNow, the initrd can be unmounted and the memory allocated by the RAM disk can be freed: # umount /initrd # blockdev --flushbufs /dev/ram0It is also possible to use initrd with an NFS-mounted root, see the pivot_root(8) man page for details.Usage scenarios---------------The main motivation for implementing initrd was to allow for modular kernel configuration at system installation. The procedure would work as follows:1) system boots from floppy or other media with a minimal kernel (e.g. support for RAM disks, initrd, a.out, and the Ext2 FS) andloads initrd 2) /sbin/init determines what is needed to (1) mount the "real" root FS (i.e. device type, device drivers, file system) and (2) thedistribution media (e.g. CD-ROM, network, tape, ...). This can be done by asking the user, by auto-probing, or by using a hybridapproach. 3) /sbin/init loads the necessary kernel modules 4) /sbin/init creates and populates the root file system (this doesn't have to be a very usable system yet) 5) /sbin/init invokes pivot_root to change the root file system and execs - via chroot - a program that continues the installation 6) the boot loader is installed 7) the boot loader is configured to load an initrd with the set of modules that was used to bring up the system (e.g. /initrd can be modified, then unmounted, and finally, the image is written from/dev/ram0 or /dev/rd/0 to a file) 8) now the system is bootable and additional installation tasks can be performedThe key role of initrd here is to re-use the configuration data during normal system operation without requiring the use of a bloated "generic" kernel or re-compiling or re-linking the kernel.A second scenario is for installations where Linux runs on systems with different hardware configurations in a single administrative domain. In such cases, it is desirable to generate only a small set of kernels (ideally only one) and to keep the system-specific part of configuration information as small as possible. In this case, a common initrd could be generated with all the necessary modules. Then, only /sbin/init or a file read by it would have to be different.A third scenario is more convenient recovery disks, because information like the location of the root FS partition doesn't have to be provided at boot time, but the system loaded from initrd can invoke a user-friendly dialog and it can also perform some sanity checks (or even some form of auto-detection).Last not least, CD-ROM distributors may use it for better installation from CD, e.g. by using a boot floppy and bootstrapping a bigger RAM disk via initrd from CD; or by booting via aloader like LOADLIN or directly from the CD-ROM, and loading the RAM disk from CD without need of floppies.Obsolete root change mechanism------------------------------The following mechanism was used before the introduction of pivot_root. Current kernels still support it, but you should _not_ rely on its continued availability.It works by mounting the "real" root device (i.e. the one set with rdev in the kernel image or with root=... at the boot command line) as the root file system when linuxrc exits. The initrd file system is then unmounted, or, if it is still busy, moved to a directory /initrd, if such a directory exists on the new root file system.In order to use this mechanism, you do not have to specify the boot command options root, init, or rw. (If specified, they will affect the real root file system, not the initrd environment.) If /proc is mounted, the "real" root device can be changed from within linuxrc by writing the number of the new root FS device to the special file /proc/sys/kernel/real-root-dev, e.g.# echo 0x301 >/proc/sys/kernel/real-root-devNote that the mechanism is incompatible with NFS and similar file systems.This old, deprecated mechanism is commonly called "change_root", while the new, supported mechanism is called "pivot_root".Mixed change_root and pivot_root mechanism------------------------------------------In case you did not want to use root=/dev/ram0 to trigger the pivot_root mechanism, you may create both /linuxrc and /sbin/init in your initrd image./linuxrc would contain only the following:#! /bin/sh mount -n -t proc proc /proc echo 0x0100 >/proc/sys/kernel/real-root-dev umount -n /procOnce linuxrc exited, the kernel would mount again your initrd as root, this time executing /sbin/init. Again, it would be the duty of this init to build the right environment (maybe using the root= device passed on the cmdline) before the final execution of the real /sbin/init. Resources---------[1] Almesberger, Werner; "Booting Linux: The History and the Future" /cv/papers/ols2k-9.ps.gz[2] newlib package (experimental), with initrd example /newlib/[3] Brouwer, Andries; "util-linux: Miscellaneous utilities for Linux" ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/。