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
+ 3) if the root device is not /dev/ram0, the old (deprecated)
+ change_root procedure is followed. see the "Obsolete root change
+ mechanism" section below.
+ 4) root device is mounted. if it is /dev/ram0, the initrd image is
+ then mounted as root
+ 5) /sbin/init 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) linuxrc mounts the "real" root file system
- 6) linuxrc places the root file system at the root directory using the
+ init can do).
+ 6) init mounts the "real" root file system
+ 7) init places the root file system at the root directory using the
pivot_root system call
- 7) the usual boot sequence (e.g. invocation of /sbin/init) is performed
- on the root file system
- 8) the initrd file system is removed
+ 8) init execs the /sbin/init on the new root filesystem, performing
+ the usual boot sequence
+ 9) the initrd file system is removed
Note that changing the root directory does not involve unmounting it.
It is therefore possible to leave processes running on initrd during that
as the last process has closed it, all data is freed and /dev/initrd
can't be opened anymore.
- root=/dev/ram0 (without devfs)
- root=/dev/rd/0 (with devfs)
+ root=/dev/ram0
initrd is mounted as root, and the normal boot procedure is followed,
- with the RAM disk still mounted as root.
+ with the RAM disk mounted as root.
+Compressed cpio images
+----------------------
+
+Recent kernels have support for populating a ramdisk from a compressed cpio
+archive. On such systems, the creation of a ramdisk image doesn't need to
+involve special block devices or loopbacks; you merely create a directory on
+disk with the desired initrd content, cd to that directory, and run (as an
+example):
+
+find . | cpio --quiet -H newc -o | gzip -9 -n > /boot/imagefile.img
+
+Examining the contents of an existing image file is just as simple:
+
+mkdir /tmp/imagefile
+cd /tmp/imagefile
+gzip -cd /boot/imagefile.img | cpio -imd --quiet
Installation
------------
procedure should create the /initrd directory.
If initrd will not be mounted in some cases, its content is still
-accessible if the following device has been created (note that this
-does not work if using devfs):
+accessible if the following device has been created:
# mknod /dev/initrd b 1 250
# chmod 400 /dev/initrd
(if space is critical, you may want to use the Minix FS instead of Ext2)
3) mount the file system, e.g.
# mount -t ext2 -o loop initrd /mnt
- 4) create the console device (not necessary if using devfs, but it can't
- hurt to do it anyway):
+ 4) create the console device:
# mkdir /mnt/dev
# mknod /mnt/dev/console c 5 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).
+ environment. Don't forget the most important file, /sbin/init
+ Note that /sbin/init's permissions must include "x" (execute).
6) correct operation the initrd environment can frequently be tested
even without rebooting with the command
- # chroot /mnt /linuxrc
+ # chroot /mnt /sbin/init
This is of course limited to initrds that do not interfere with the
general system state (e.g. by reconfiguring network interfaces,
overwriting mounted devices, trying to start already running demons,
# gzip -9 initrd
For experimenting with initrd, you may want to take a rescue floppy and
-only add a symbolic link from /linuxrc to /bin/sh. Alternatively, you
+only add a symbolic link from /sbin/init to /bin/sh. Alternatively, you
can try the experimental newlib environment [2] to create a small
initrd.
with an older mechanism, the following boot command line parameters
have to be given:
- root=/dev/ram0 init=/linuxrc rw
+ root=/dev/ram0 rw
-if not using devfs, or
-
- root=/dev/rd/0 init=/linuxrc rw
-
-if using devfs. (rw is only necessary if writing to the initrd file
-system.)
+(rw is only necessary if writing to the initrd file system.)
With LOADLIN, you simply execute
LOADLIN <kernel> initrd=<disk_image>
-e.g. LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0
- init=/linuxrc rw
+e.g. LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0 rw
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, and pass
image = /bzImage
initrd = /boot/initrd.gz
- append = "root=/dev/ram0 init=/linuxrc rw"
+ append = "root=/dev/ram0 rw"
and run /sbin/lilo
Changing the root device
------------------------
-When finished with its duties, linuxrc typically changes the root device
+When finished with its duties, init typically changes the root device
and proceeds with starting the Linux system on the "real" root device.
The procedure involves the following steps:
# mkdir initrd
# pivot_root . initrd
-Now, the linuxrc process may still access the old root via its
+Now, the init process may still access the old root via its
executable, shared libraries, standard input/output/error, and its
current root directory. All these references are dropped by the
following command:
# exec chroot . what-follows <dev/console >dev/console 2>&1
Where what-follows is a program under the new root, e.g. /sbin/init
-If the new root file system will be used with devfs and has no valid
-/dev directory, devfs must be mounted before invoking chroot in order to
-provide /dev/console.
+If the new root file system will be used with udev and has no valid
+/dev directory, udev must be initialized before invoking chroot in order
+to provide /dev/console.
Note: implementation details of pivot_root may change with time. In order
to ensure compatibility, the following points should be observed:
disk can be freed:
# umount /initrd
-# blockdev --flushbufs /dev/ram0 # /dev/rd/0 if using devfs
+# blockdev --flushbufs /dev/ram0
It is also possible to use initrd with an NFS-mounted root, see the
pivot_root(8) man page for details.
-Note: if linuxrc or any program exec'ed from it terminates for some
-reason, the old change_root mechanism is invoked (see section "Obsolete
-root change mechanism").
-
Usage scenarios
---------------
1) system 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
+ 2) /sbin/init 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 kernel modules
- 4) /linuxrc creates and populates the root file system (this doesn't
+ 3) /sbin/init loads the necessary kernel modules
+ 4) /sbin/init creates and populates the root file system (this doesn't
have to be a very usable system yet)
- 5) /linuxrc invokes pivot_root to change the root file system and
+ 5) /sbin/init invokes pivot_root to change the root file system and
execs - via chroot - a program that continues the installation
6) the boot loader is installed
7) the boot loader is configured to load an initrd with the set of
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
+generated with all the necessary modules. Then, only /sbin/init or a file
read by it would have to be different.
-A third scenario are more convenient recovery disks, because information
+A third scenario is 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 invoke a user-friendly
dialog and it can also perform some sanity checks (or even some form of
the new, supported mechanism is called "pivot_root".
+Mixed change_root and pivot_root mechanism
+------------------------------------------
+
+In case you did not want to use root=/dev/ram0 to trigger the pivot_root
+mechanism, you may create both /linuxrc and /sbin/init in your initrd image.
+
+/linuxrc would contain only the following:
+
+#! /bin/sh
+mount -n -t proc proc /proc
+echo 0x0100 >/proc/sys/kernel/real-root-dev
+umount -n /proc
+
+Once linuxrc exited, the kernel would mount again your initrd as root,
+this time executing /sbin/init. Again, it would be the duty of this init
+to build the right environment (maybe using the root= device passed on
+the cmdline) before the final execution of the real /sbin/init.
+
+
Resources
---------
Code Review / linux-2.6.git / blobdiff