Using the initial RAM disk (initrd)

initrd adds the capability to load a RAM disk by the boot loader. This RAM disk can then be mounted as the root filesystem and programs can be run from it. Afterwards, a new root filesystem can be mounted from a different device. The previous root (from initrd) is then either moved to the directory /initrd or it is 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.

Operation

When using initrd, the system boots as follows:

1. the boot loader loads the kernel and the initial RAM disk

2. the kernel converts initrd into a “normal” RAM disk and frees the memory used by initrd.

3. initrd is mounted read-write as root

4. linuxrc 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)

5. when linuxrc terminates, the “real” root filesystem is mounted

6. if a directory /initrd exists, the initrd is moved there, otherwise, initrd is unmounted

7. the usual boot sequence (e.g. invocation of /sbin/init ) is performed on the root filesystem

Note that moving initrd from / to /initrd does not involve unmounting it. It is therefore possible to leave processes running on initrd (or leave filesystems mounted, but see below) during that procedure. However, if /initrd doesn't exist, initrd can only be unmounted if it is not used by anything. If it can't be unmounted, it will stay in memory.

Also note that filesystems mounted under initrd continue to be accessible, but their /proc/mounts entries are not updated. Also, if /initrd doesn't exist, initrd can't be unmounted and will “disappear” and take those filesystems with it, thereby preventing them from being re-mounted. It is therefore strongly suggested to generally unmount all filesystems (except of course for the root filesystem, but including /proc) before switching from initrd to the “normal” root filesystem.

In order to de-allocate the memory used for the initial RAM disk, you have to execute freeramdisk after unmounting /initrd.

initrd adds the following new options to the boot command line options:

initrd= (LOADLIN only)

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.

noinitrd

initrd data is preserved but it is not converted to a RAM disk and the “normal” root filesystem is mounted. initrd data can be read from /dev/initrd. Note that the data in initrd can have any structure in this case and doesn't necessarily have to be a filesystem image. This option is used mainly for debugging.

Note that /dev/initrd is read-only and that it can only be used once. As soon as the last process has closed it, all data is freed and /dev/initrd can't be opened any longer.

root=/dev/ram

initrd is mounted as root, and /linuxrc is started. If no /linuxrc exists, the normal boot procedure is followed, with the RAM disk still mounted as root. This option is mainly useful when booting from a floppy disk. Compared to directly mounting an on-disk filesystem, the intermediate step of going via initrd adds a little speed advantage and it allows the use of a compressed file system. Also, together with LOADLIN you may load the RAM disk directly from CDrom or disk, hence having a floppy-less boot from CD, e.g.: E:\loadlin E:\bzImage root=/dev/ram initrd=E:\rdimage

Installation

First, the “normal” root filesystem has to be prepared as follows:

# mknod /dev/initrd b 0 250 
# chmod 400 /dev/initrd
# mkdir /initrd
        

If the root filesystem is created during the boot procedure (i.e. if you're creating an install floppy), the root filesystem creation procedure should perform these operations.

Note that neither /dev/initrd nor /initrd are strictly required for correct operation of initrd, but it is a lot easier to experiment with initrd if you have them, and you may also want to use /initrd to pass data to the “real” system.

Second, the kernel has to be compiled with RAM disk support and with support for the initial RAM disk enabled. Also, all components needed to execute programs from initrd (e.g. executable format and filesystem) must be compiled into the kernel).

Third, you have to create the RAM disk image. This is done by creating a filesystem on a block device and then by copying files to it as needed. 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 RAM disk method:

1. make sure you have a RAM disk device /dev/ram (block, major 1, minor 0)

2. create an empty filesystem of the appropriate size, e.g.

   # mke2fs -m0 /dev/ram 300   
   (if space is critical, you may want to use the Minix FS instead of Ext2)
                 

3. mount the filesystem on an appropriate directory, e.g.

   # mount -t ext2 /dev/ram /mnt
                 

4. create the console device:

   # mkdir /mnt/dev
   # mknod /mnt/dev/tty1 c 4 1
                 

5. copy all the files that are needed to properly use the initrd environment. Don't forget the most important file, /linuxrc Note that /linuxrc must be given execute permission.

6. unmount the RAM disk

   # umount /dev/ram
                 

7. copy the image to a file

   # dd if=/dev/ram bs=1k count=300 of=/boot/initrd
                 

8. deallocate the RAM disk

   # freeramdisk /dev/ram
                 

For experimenting with initrd, you may want to take a rescue floppy (e.g. rescue.gz from Slackware) and only add a symbolic link from /linuxrc to /bin/sh, e.g.

# gunzip /dev/ram
# mount -t minix /dev/ram /mnt
# ln -s /bin/sh /mnt/linuxrc
# umount /dev/ram
# dd if=/dev/ram bs=1k count=1440 of=/boot/initrd
# freeramdisk /dev/ram
          

Finally, you have to boot the kernel and load initrd . With LOADLIN, you simply execute

LOADLIN initrd=
e.g. LOADLIN C:\LINUX\VMLINUZ initrd=C:\LINUX\INITRD
          

With LILO, you add the option INITRD= to either the global section or to the section of the respective kernel in /etc/lilo.conf, e.g.

image = /vmlinuz
initrd = /boot/initrd
          

and run /sbin/lilo

Now you can boot and enjoy using initrd.

Setting the root device

By default, the standard settings in the kernel are used for the root device, i.e. the default compiled in or set with rdev , or what was passed with root=xxx on the command line, or, with LILO, what was specified in /etc/lilo.conf It is also possible to use initrd with an NFS-mounted root; you have to use the nfs_root_name and nfs_root_addrs boot options for this.

It is also possible to change the root device from within the initrd environment. In order to do so, /proc has to be mounted. Then, the following files are available:

/proc/sys/kernel/real-root-dev
/proc/sys/kernel/nfs-root-name
/proc/sys/kernel/nfs-root-addrs
          

real-root-dev can be changed by writing the number of the new root FS device to it, e.g.

# echo 0x301 >/proc/sys/kernel/real-root-dev
          

for /dev/hda1. When using an NFS-mounted root, nfs-root-name and nfs-root-addrs have to be set accordingly and then real-root-dev has to be set to 0xff, e.g.

# echo /var/nfsroot >/proc/sys/kernel/nfs-root-name
# echo 193.8.232.2:193.8.232.7::255.255.255.0:idefix \
   >/proc/sys/kernel/nfs-root-addrs
# echo 255 >/proc/sys/kernel/real-root-dev
          

If the root device is set to the RAM disk, the root filesystem is not moved to /initrd, but the boot procedure is simply continued by starting init on the initial RAM disk.

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. systems boots from floppy or other media with a minimal kernel (e.g. support for RAM disks, initrd, a.out, and the ext2 FS) and loads initrd

2. /linuxrc determines what is needed to (1) mount the “real” root FS (i.e. device type, device drivers, filesystem) and (2) the distribution media (e.g. CD-ROM, network, tape, ...). This can be done by asking the user, by auto-probing, or by using a hybrid approach.

3. /linuxrc loads the necessary modules

4. /linuxrc creates and populates the root file system (this doesn't have to be a very usable system yet)

5. /linuxrc unmounts the root filesystem and possibly any other filesystems it has mounted, sets /proc/sys/kernel/..., and terminates

6. the root filesystem is mounted

7. now that we're sure that the filesystem is accessible and intact, the boot loader can be installed

8. 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/ram to a file)

9. now the system is bootable and additional installation tasks can be performed

The 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-compilation or re-linking of 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 /linuxrc or a file read by it would have to be different.

A third scenario might result in more convenient recovery disks, because information like the location of the root FS partition doesn't have to be provided at boot time, and the system loaded from initrd can use a user-friendly dialog and can also perform some sanity checks (or even some form of auto-detection).

Last but not least, CDrom distributors may use it for better installation from CD, either using a LILO boot floppy and bootstrapping a bigger ramdisk via initrd from CD, or using LOADLIN to directly load the ramdisk from CD without need of floppies.

Since initrd is a fairly generic mechanism, it is likely that additional uses will be found.