From beb116954b9b7f3bb56412b2494b562f02b864b1 Mon Sep 17 00:00:00 2001 From: Ralf Baechle Date: Tue, 7 Jan 1997 02:33:00 +0000 Subject: Import of Linux/MIPS 2.1.14 --- Documentation/initrd.txt | 286 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 286 insertions(+) create mode 100644 Documentation/initrd.txt (limited to 'Documentation/initrd.txt') diff --git a/Documentation/initrd.txt b/Documentation/initrd.txt new file mode 100644 index 000000000..220fcb150 --- /dev/null +++ b/Documentation/initrd.txt @@ -0,0 +1,286 @@ +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 -- cgit v1.2.3