patch-1.3.73 linux/Documentation/initrd.txt

• Lines: 287
• Date: Sat Mar 9 13:31:44 1996
• Orig file: v1.3.72/linux/Documentation/initrd.txt
• Orig date: Thu Jan 1 02:00:00 1970

diff -u --recursive --new-file v1.3.72/linux/Documentation/initrd.txt linux/Documentation/initrd.txt
@@ -0,0 +1,286 @@
+Using the initial RAM disk (initrd)
+===================================
+
+Written 1996 by Werner Almesberger <almesber@lrc.epfl.ch> and
+		Hans Lermen <lermen@elserv.ffm.fgan.de>
+
+
+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=<path>    (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 <rescue.gz >/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 <kernel> initrd=<disk_image>
+e.g. LOADLIN C:\LINUX\VMLINUZ initrd=C:\LINUX\INITRD
+
+With LILO, you add the option INITRD=<path> 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 floppys.
+
+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 programm 'freeramdisk', can be found on
+ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/initrd-example.tgz