mirror of https://github.com/tLDP/LDP
96 lines
4.0 KiB
XML
96 lines
4.0 KiB
XML
<sect1 id="initrd">
|
|
<title>/initrd</title>
|
|
|
|
<para>
|
|
<screen>
|
|
initrd provides 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 moved to a directory and
|
|
can be subsequently 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 typically 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) linuxrc mounts the "real" root file system
|
|
6) linuxrc 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
|
|
|
|
Note that changing the root directory does not involve unmounting
|
|
it. It is therefore possible to leave processes running on initrd
|
|
during that procedure. Also note that file systems mounted under
|
|
initrd continue to be accessible.
|
|
|
|
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) 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 (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 have to be a very usable system yet)
|
|
5) /linuxrc 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
|
|
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/ram0 or /dev/rd/0 to a file)
|
|
8) 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-compiling or re-linking 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
|
|
invoke a user-friendly dialog and it can also perform some sanity
|
|
checks (or even some form of auto-detection).
|
|
|
|
Last not least, CD-ROM distributors may use it for better installation
|
|
from CD, e.g. by using a boot floppy and bootstrapping a bigger RAM disk
|
|
via initrd from CD; or by booting via a loader like LOADLIN or directly
|
|
from the CD-ROM, and loading the RAM disk from CD without need of floppies.
|
|
</screen>
|
|
</para>
|
|
|
|
</sect1>
|