home *** CD-ROM | disk | FTP | other *** search
/ Boot Disc 15 / boot-disc-1997-11.iso / Debian / Tools / LODLIN16.ZIP / LODLIN16 / DOC / INITRD.TXT < prev    next >
Text File  |  1996-04-30  |  12KB  |  287 lines
  1. Using the initial RAM disk (initrd)
  2. ===================================
  3.  
  4. Written 1996 by Werner Almesberger <almesber@lrc.epfl.ch> and
  5.         Hans Lermen <lermen@elserv.ffm.fgan.de>
  6.  
  7.  
  8. initrd adds the capability to load a RAM disk by the boot loader. This
  9. RAM disk can then be mounted as the root file system and programs can be
  10. run from it. Afterwards, a new root file system can be mounted from a
  11. different device. The previous root (from initrd) is then either moved
  12. to the directory /initrd or it is unmounted.
  13.  
  14. initrd is mainly designed to allow system startup to occur in two phases,
  15. where the kernel comes up with a minimum set of compiled-in drivers, and
  16. where additional modules are loaded from initrd.
  17.  
  18.  
  19. Operation
  20. ---------
  21.  
  22. When using initrd, the system boots as follows:
  23.  
  24.   1) the boot loader loads the kernel and the initial RAM disk
  25.   2) the kernel converts initrd into a "normal" RAM disk and
  26.      frees the memory used by initrd
  27.   3) initrd is mounted read-write as root
  28.   4) /linuxrc is executed (this can be any valid executable, including
  29.      shell scripts; it is run with uid 0 and can do basically everything
  30.      init can do)
  31.   5) when linuxrc terminates, the "real" root file system is mounted
  32.   6) if a directory /initrd exists, the initrd is moved there
  33.      otherwise, initrd is unmounted
  34.   7) the usual boot sequence (e.g. invocation of /sbin/init) is performed
  35.      on the root file system
  36.  
  37. Note that moving initrd from / to /initrd does not involve unmounting it.
  38. It is therefore possible to leave processes running on initrd (or leave
  39. file systems mounted, but see below) during that procedure. However, if
  40. /initrd doesn't exist, initrd can only be unmounted if it is not used by
  41. anything. If it can't be unmounted, it will stay in memory.
  42.  
  43. Also note that file systems mounted under initrd continue to be accessible,
  44. but their /proc/mounts entries are not updated. Also, if /initrd doesn't
  45. exist, initrd can't be unmounted and will "disappear" and take those file
  46. systems with it, thereby preventing them from being re-mounted. It is
  47. therefore strongly suggested to generally unmount all file systems (except
  48. of course for the root file system, but including /proc) before switching
  49. from initrd to the "normal" root file system.
  50.  
  51. In order to deallocate the memory used for the initial RAM disk, you have
  52. to execute freeramdisk (see 'Resources' below) after unmounting /initrd.
  53.  
  54.  
  55. Boot command-line options
  56. -------------------------
  57.  
  58. initrd adds the following new options:
  59.  
  60.   initrd=<path>    (LOADLIN only)
  61.  
  62.     Loads the specified file as the initial RAM disk. When using LILO, you
  63.     have to specify the RAM disk image file in /etc/lilo.conf, using the
  64.     INITRD configuration variable.
  65.  
  66.   noinitrd
  67.  
  68.     initrd data is preserved but it is not converted to a RAM disk and
  69.     the "normal" root file system is mounted. initrd data can be read
  70.     from /dev/initrd. Note that the data in initrd can have any structure
  71.     in this case and doesn't necessarily have to be a file system image.
  72.     This option is used mainly for debugging.
  73.  
  74.     Note that /dev/initrd is read-only and that it can only be used once.
  75.     As soon as the last process has closed it, all data is freed and
  76.     /dev/initrd can't be opened any longer.
  77.  
  78.   root=/dev/ram
  79.  
  80.     initrd is mounted as root, and /linuxrc is started. If no /linuxrc
  81.     exists, the normal boot procedure is followed, with the RAM disk
  82.     still mounted as root. This option is mainly useful when booting from
  83.     a floppy disk. Compared to directly mounting an on-disk file system,
  84.     the intermediate step of going via initrd adds a little speed
  85.     advantage and it allows the use of a compressed file system.
  86.     Also, together with LOADLIN you may load the RAM disk directly from
  87.     CDrom or disk, hence having a floppyless boot from CD,
  88.     e.g.: E:\loadlin E:\bzImage root=/dev/ram initrd=E:\rdimage
  89.  
  90.  
  91. Installation
  92. ------------
  93.  
  94. First, the "normal" root file system has to be prepared as follows:
  95.  
  96. # mknod /dev/initrd b 0 250 
  97. # chmod 400 /dev/initrd
  98. # mkdir /initrd
  99.  
  100. If the root file system is created during the boot procedure (i.e. if
  101. you're creating an install floppy), the root file system creation
  102. procedure should perform these operations.
  103.  
  104. Note that neither /dev/initrd nor /initrd are strictly required for
  105. correct operation of initrd, but it is a lot easier to experiment with
  106. initrd if you have them, and you may also want to use /initrd to pass
  107. data to the "real" system.
  108.  
  109. Second, the kernel has to be compiled with RAM disk support and with
  110. support for the initial RAM disk enabled. Also, at least all components
  111. needed to execute programs from initrd (e.g. executable format and file
  112. system) must be compiled into the kernel.
  113.  
  114. Third, you have to create the RAM disk image. This is done by creating a
  115. file system on a block device and then by copying files to it as needed.
  116. With recent kernels, at least three types of devices are suitable for
  117. that:
  118.  
  119.  - a floppy disk (works everywhere but it's painfully slow)
  120.  - a RAM disk (fast, but allocates physical memory)
  121.  - a loopback device (the most elegant solution, but currently requires a
  122.    modified mount)
  123.  
  124. We'll describe the RAM disk method:
  125.  
  126.  1) make sure you have a RAM disk device /dev/ram (block, major 1, minor 0)
  127.  2) create an empty file system of the appropriate size, e.g.
  128.     # mke2fs -m0 /dev/ram 300   
  129.     (if space is critical, you may want to use the Minix FS instead of Ext2)
  130.  3) mount the file system on an appropriate directory, e.g.
  131.     # mount -t ext2 /dev/ram /mnt
  132.  4) create the console device:
  133.     # mkdir /mnt/dev
  134.     # mknod /mnt/dev/tty1 c 4 1
  135.  5) copy all the files that are needed to properly use the initrd
  136.     environment. Don't forget the most important file, /linuxrc
  137.     Note that /linuxrc's permissions must include "x" (execute).
  138.  6) unmount the RAM disk
  139.     # umount /dev/ram
  140.  7) copy the image to a file
  141.     # dd if=/dev/ram bs=1k count=300 of=/boot/initrd
  142.  8) deallocate the RAM disk
  143.     # freeramdisk /dev/ram
  144.  
  145. For experimenting with initrd, you may want to take a rescue floppy (e.g.
  146. rescue.gz from Slackware) and only add a symbolic link from /linuxrc to
  147. /bin/sh, e.g.
  148.  
  149.  # gunzip <rescue.gz >/dev/ram
  150.  # mount -t minix /dev/ram /mnt
  151.  # ln -s /bin/sh /mnt/linuxrc
  152.  # umount /dev/ram
  153.  # dd if=/dev/ram bs=1k count=1440 of=/boot/initrd
  154.  # freeramdisk /dev/ram
  155.  
  156. Finally, you have to boot the kernel and load initrd. Currently,
  157. preliminary versions of LOADLIN 1.6 and LILO 18 support initrd (see
  158. below for where to get them). With LOADLIN, you simply execute
  159.  
  160.      LOADLIN <kernel> initrd=<disk_image>
  161. e.g. LOADLIN C:\LINUX\VMLINUZ initrd=C:\LINUX\INITRD
  162.  
  163. With LILO, you add the option INITRD=<path> to either the global section
  164. or to the section of the respective kernel in /etc/lilo.conf, e.g.
  165.  
  166.   image = /vmlinuz
  167.     initrd = /boot/initrd
  168.  
  169. and run /sbin/lilo
  170.  
  171. Now you can boot and enjoy using initrd.
  172.  
  173.  
  174. Setting the root device
  175. -----------------------
  176.  
  177. By default, the standard settings in the kernel are used for the root
  178. device, i.e. the default compiled in or set with rdev, or what was passed
  179. with root=xxx on the command line, or, with LILO, what was specified in
  180. /etc/lilo.conf It is also possible to use initrd with an NFS-mounted
  181. root; you have to use the nfs_root_name and nfs_root_addrs boot options
  182. for this.
  183.  
  184. It is also possible to change the root device from within the initrd
  185. environment. In order to do so, /proc has to be mounted. Then, the
  186. following files are available:
  187.  
  188.   /proc/sys/kernel/real-root-dev
  189.   /proc/sys/kernel/nfs-root-name
  190.   /proc/sys/kernel/nfs-root-addrs
  191.  
  192. real-root-dev can be changed by writing the number of the new root FS
  193. device to it, e.g.
  194.  
  195.   # echo 0x301 >/proc/sys/kernel/real-root-dev
  196.  
  197. for /dev/hda1. When using an NFS-mounted root, nfs-root-name and
  198. nfs-root-addrs have to be set accordingly and then real-root-dev has to
  199. be set to 0xff, e.g.
  200.  
  201.   # echo /var/nfsroot >/proc/sys/kernel/nfs-root-name
  202.   # echo 193.8.232.2:193.8.232.7::255.255.255.0:idefix \
  203.     >/proc/sys/kernel/nfs-root-addrs
  204.   # echo 255 >/proc/sys/kernel/real-root-dev
  205.  
  206. If the root device is set to the RAM disk, the root file system is not
  207. moved to /initrd, but the boot procedure is simply continued by starting
  208. init on the initial RAM disk.
  209.  
  210.  
  211. Usage scenarios
  212. ---------------
  213.  
  214. The main motivation for implementing initrd was to allow for modular
  215. kernel configuration at system installation. The procedure would work
  216. as follows:
  217.  
  218.   1) systems boots from floppy or other media with a minimal kernel
  219.      (e.g. support for RAM disks, initrd, a.out, and the ext2 FS) and
  220.      loads initrd
  221.   2) /linuxrc determines what is needed to (1) mount the "real" root FS
  222.      (i.e. device type, device drivers, file system) and (2) the
  223.      distribution media (e.g. CD-ROM, network, tape, ...). This can be
  224.      done by asking the user, by auto-probing, or by using a hybrid
  225.      approach.
  226.   3) /linuxrc loads the necessary modules
  227.   4) /linuxrc creates and populates the root file system (this doesn't
  228.      have to be a very usable system yet)
  229.   5) /linuxrc unmounts the root file system and possibly any other file
  230.      systems it has mounted, sets /proc/sys/kernel/..., and terminates
  231.   6) the root file system is mounted
  232.   7) now that we're sure that the file system is accessible and intact,
  233.      the boot loader can be installed
  234.   8) the boot loader is configured to load an initrd with the set of
  235.      modules that was used to bring up the system (e.g. /initrd can be
  236.      modified, then unmounted, and finally, the image is written from
  237.      /dev/ram to a file)
  238.   9) now the system is bootable and additional installation tasks can be
  239.      performed
  240.  
  241. The key role of initrd here is to re-use the configuration data during
  242. normal system operation without requiring the use of a bloated "generic"
  243. kernel or re-compilation or re-linking of the kernel.
  244.  
  245. A second scenario is for installations where Linux runs on systems with
  246. different hardware configurations in a single administrative domain. In
  247. such cases, it is desirable to generate only a small set of kernels
  248. (ideally only one) and to keep the system-specific part of configuration
  249. information as small as possible. In this case, a common initrd could be
  250. generated with all the necessary modules. Then, only /linuxrc or a file
  251. read by it would have to be different.
  252.  
  253. A third scenario are more convenient recovery disks, because information
  254. like the location of the root FS partition doesn't have to be provided at
  255. boot time, but the system loaded from initrd can use a user-friendly
  256. dialog and it can also perform some sanity checks (or even some form of
  257. auto-detection).
  258.  
  259. Last not least, CDrom distributors may use it for better installation from CD,
  260. either using a LILO boot floppy and bootstrapping a bigger ramdisk via
  261. initrd from CD, or using LOADLIN to directly load the ramdisk from CD
  262. without need of floppies.
  263.  
  264. Since initrd is a fairly generic mechanism, it is likely that additional
  265. uses will be found.
  266.  
  267.  
  268. Resources
  269. ---------
  270.  
  271. The bzImage+initrd patch (bzImage is an extension to load kernels directly
  272. above 1 MB, which allows kernels sizes of up to approximately 2 MB) can be
  273. found at
  274. ftp://lrcftp.epfl.ch/pub/people/almesber/lilo/bzImage+initrd-1.3.71.patch.gz
  275. and
  276. ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/bzImage+initrd-1.3.71.patch.gz
  277.  
  278. A preliminary version of LOADLIN 1.6 is available on
  279. ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/loadlin-1.6-pre8-bin.tgz
  280.  
  281. A preliminary version of LILO 18 is available on
  282. ftp://lrcftp.epfl.ch/pub/people/almesber/lilo/lilo.18dev3.tar.gz
  283.  
  284. A very simple example for building an image for initrd, also including
  285. the program 'freeramdisk', can be found on
  286. ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/initrd-example.tgz
  287.