Subversion Repositories or1k

Using the initial RAM disk (initrd)

===================================

Written 1996 by Werner Almesberger  and

                Hans Lermen 

initrd adds the capability to load a RAM disk by the boot loader. This

RAM disk can then be mounted 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 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 file system 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 file system

Note that moving initrd from / to /initrd does not involve unmounting it.

It is therefore possible to leave processes running on initrd (or leave

file systems 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 file systems 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 file

systems with it, thereby preventing them from being re-mounted. It is

therefore strongly suggested to generally unmount all file systems (except

of course for the root file system, but including /proc) before switching

from initrd to the "normal" root file system.

In order to deallocate the memory used for the initial RAM disk, you have

to execute freeramdisk (see 'Resources' below) after unmounting /initrd.

Boot command-line options

-------------------------

initrd adds the following new 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 file system 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 file system 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 file system,

    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 floppyless boot from CD,

    e.g.: E:\loadlin E:\bzImage root=/dev/ram initrd=E:\rdimage

Installation

------------

First, the "normal" root file system has to be prepared as follows:

# mknod /dev/initrd b 0 250

# chmod 400 /dev/initrd

# mkdir /initrd

If the root file system is created during the boot procedure (i.e. if

you're creating an install floppy), the root file system 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, 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 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, but currently requires a

   modified mount)

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 file system 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 file system 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's permissions must include "x" (execute).

 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. Currently,

preliminary versions of LOADLIN 1.6 and LILO 18 support initrd (see

below for where to get them). 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 file system 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, file system) 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 file system and possibly any other file

     systems it has mounted, sets /proc/sys/kernel/..., and terminates

  6) the root file system is mounted

  7) now that we're sure that the file system 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 are 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 use a user-friendly

dialog and it can also perform some sanity checks (or even some form of

auto-detection).

Last 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.

Resources

---------

The bzImage+initrd patch (bzImage is an extension to load kernels directly

above 1 MB, which allows kernels sizes of up to approximately 2 MB) can be

found at

ftp://lrcftp.epfl.ch/pub/people/almesber/lilo/bzImage+initrd-1.3.71.patch.gz

and

ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/bzImage+initrd-1.3.71.patch.gz

A preliminary version of LOADLIN 1.6 is available on

ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/loadlin-1.6-pre8-bin.tgz

A preliminary version of LILO 18 is available on

ftp://lrcftp.epfl.ch/pub/people/almesber/lilo/lilo.18dev3.tar.gz

A very simple example for building an image for initrd, also including

the program 'freeramdisk', can be found on

ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/initrd-example.tgz