Documentation/initrd.txt: convert to ReST markup
- use a quote blocks where needed; - fix the chapter/section/subsection markups; - use ``foo`` for monotonic; - use .. note:: for /sbin/init file permissions; - adjust whitespaces and blank lines; - add it to the user's book. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This commit is contained in:
Mauro Carvalho Chehab
parent
7d4e3517bd
commit
5d0ad55378
|
|
@ -2,7 +2,7 @@ Using the initial RAM disk (initrd)
|
|||
===================================
|
||||
|
||||
Written 1996,2000 by Werner Almesberger <werner.almesberger@epfl.ch> and
|
||||
Hans Lermen <lermen@fgan.de>
|
||||
Hans Lermen <lermen@fgan.de>
|
||||
|
||||
|
||||
initrd provides the capability to load a RAM disk by the boot loader.
|
||||
|
|
@ -16,7 +16,7 @@ where the kernel comes up with a minimum set of compiled-in drivers, and
|
|||
where additional modules are loaded from initrd.
|
||||
|
||||
This document gives a brief overview of the use of initrd. A more detailed
|
||||
discussion of the boot process can be found in [1].
|
||||
discussion of the boot process can be found in [#f1]_.
|
||||
|
||||
|
||||
Operation
|
||||
|
|
@ -27,10 +27,10 @@ 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) if the root device is not /dev/ram0, the old (deprecated)
|
||||
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
|
||||
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
|
||||
|
|
@ -38,7 +38,7 @@ When using initrd, the system typically boots as follows:
|
|||
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
|
||||
8) init execs the /sbin/init on the new root filesystem, performing
|
||||
8) init execs the ``/sbin/init`` on the new root filesystem, performing
|
||||
the usual boot sequence
|
||||
9) the initrd file system is removed
|
||||
|
||||
|
|
@ -51,7 +51,7 @@ be accessible.
|
|||
Boot command-line options
|
||||
-------------------------
|
||||
|
||||
initrd adds the following new options:
|
||||
initrd adds the following new options::
|
||||
|
||||
initrd=<path> (e.g. LOADLIN)
|
||||
|
||||
|
|
@ -83,36 +83,36 @@ 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):
|
||||
example)::
|
||||
|
||||
find . | cpio --quiet -H newc -o | gzip -9 -n > /boot/imagefile.img
|
||||
find . | cpio --quiet -H newc -o | gzip -9 -n > /boot/imagefile.img
|
||||
|
||||
Examining the contents of an existing image file is just as simple:
|
||||
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
|
||||
mkdir /tmp/imagefile
|
||||
cd /tmp/imagefile
|
||||
gzip -cd /boot/imagefile.img | cpio -imd --quiet
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
First, a directory for the initrd file system has to be created on the
|
||||
"normal" root file system, e.g.
|
||||
"normal" root file system, e.g.::
|
||||
|
||||
# mkdir /initrd
|
||||
# mkdir /initrd
|
||||
|
||||
The name is not relevant. More details can be found on the pivot_root(2)
|
||||
man page.
|
||||
The name is not relevant. More details can be found on the
|
||||
:manpage:`pivot_root(2)` man page.
|
||||
|
||||
If the root file system is created during the boot procedure (i.e. if
|
||||
you're building an install floppy), the root file system creation
|
||||
procedure should create the /initrd directory.
|
||||
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:
|
||||
accessible if the following device has been created::
|
||||
|
||||
# mknod /dev/initrd b 1 250
|
||||
# chmod 400 /dev/initrd
|
||||
# mknod /dev/initrd b 1 250
|
||||
# chmod 400 /dev/initrd
|
||||
|
||||
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
|
||||
|
|
@ -131,60 +131,76 @@ kernels, at least three types of devices are suitable for that:
|
|||
We'll describe the loopback device method:
|
||||
|
||||
1) make sure loopback block devices are configured into the kernel
|
||||
2) create an empty file system of the appropriate size, e.g.
|
||||
# dd if=/dev/zero of=initrd bs=300k count=1
|
||||
# mke2fs -F -m0 initrd
|
||||
2) create an empty file system of the appropriate size, e.g.::
|
||||
|
||||
# dd if=/dev/zero of=initrd bs=300k count=1
|
||||
# mke2fs -F -m0 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:
|
||||
3) mount the file system, e.g.::
|
||||
|
||||
# mount -t ext2 -o loop initrd /mnt
|
||||
|
||||
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, /sbin/init
|
||||
Note that /sbin/init's permissions must include "x" (execute).
|
||||
environment. Don't forget the most important file, ``/sbin/init``
|
||||
|
||||
.. note:: ``/sbin/init`` permissions must include "x" (execute).
|
||||
|
||||
6) correct operation the initrd environment can frequently be tested
|
||||
even without rebooting with the command
|
||||
# chroot /mnt /sbin/init
|
||||
even without rebooting with the command::
|
||||
|
||||
# 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,
|
||||
etc. Note however that it is usually possible to use pivot_root in
|
||||
such a chroot'ed initrd environment.)
|
||||
7) unmount the file system
|
||||
# umount /mnt
|
||||
7) unmount the file system::
|
||||
|
||||
# umount /mnt
|
||||
|
||||
8) the initrd is now in the file "initrd". Optionally, it can now be
|
||||
compressed
|
||||
# gzip -9 initrd
|
||||
compressed::
|
||||
|
||||
# gzip -9 initrd
|
||||
|
||||
For experimenting with initrd, you may want to take a rescue floppy and
|
||||
only add a symbolic link from /sbin/init to /bin/sh. Alternatively, you
|
||||
can try the experimental newlib environment [2] to create a small
|
||||
only add a symbolic link from ``/sbin/init`` to ``/bin/sh``. Alternatively, you
|
||||
can try the experimental newlib environment [#f2]_ to create a small
|
||||
initrd.
|
||||
|
||||
Finally, you have to boot the kernel and load initrd. Almost all Linux
|
||||
boot loaders support initrd. Since the boot process is still compatible
|
||||
with an older mechanism, the following boot command line parameters
|
||||
have to be given:
|
||||
have to be given::
|
||||
|
||||
root=/dev/ram0 rw
|
||||
|
||||
(rw is only necessary if writing to the initrd file system.)
|
||||
|
||||
With LOADLIN, you simply execute
|
||||
With LOADLIN, you simply execute::
|
||||
|
||||
LOADLIN <kernel> initrd=<disk_image>
|
||||
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
|
||||
the options using APPEND, e.g.
|
||||
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
|
||||
the options using APPEND, e.g.::
|
||||
|
||||
image = /bzImage
|
||||
initrd = /boot/initrd.gz
|
||||
append = "root=/dev/ram0 rw"
|
||||
|
||||
and run /sbin/lilo
|
||||
and run ``/sbin/lilo``
|
||||
|
||||
For other boot loaders, please refer to the respective documentation.
|
||||
|
||||
|
|
@ -204,33 +220,33 @@ The procedure involves the following steps:
|
|||
- unmounting the initrd file system and de-allocating the RAM disk
|
||||
|
||||
Mounting the new root file system is easy: it just needs to be mounted on
|
||||
a directory under the current root. Example:
|
||||
a directory under the current root. Example::
|
||||
|
||||
# mkdir /new-root
|
||||
# mount -o ro /dev/hda1 /new-root
|
||||
# mkdir /new-root
|
||||
# mount -o ro /dev/hda1 /new-root
|
||||
|
||||
The root change is accomplished with the pivot_root system call, which
|
||||
is also available via the pivot_root utility (see pivot_root(8) man
|
||||
page; pivot_root is distributed with util-linux version 2.10h or higher
|
||||
[3]). pivot_root moves the current root to a directory under the new
|
||||
is also available via the ``pivot_root`` utility (see :manpage:`pivot_root(8)`
|
||||
man page; ``pivot_root`` is distributed with util-linux version 2.10h or higher
|
||||
[#f3]_). ``pivot_root`` moves the current root to a directory under the new
|
||||
root, and puts the new root at its place. The directory for the old root
|
||||
must exist before calling pivot_root. Example:
|
||||
must exist before calling ``pivot_root``. Example::
|
||||
|
||||
# cd /new-root
|
||||
# mkdir initrd
|
||||
# pivot_root . initrd
|
||||
# cd /new-root
|
||||
# mkdir initrd
|
||||
# pivot_root . initrd
|
||||
|
||||
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:
|
||||
following command::
|
||||
|
||||
# exec chroot . what-follows <dev/console >dev/console 2>&1
|
||||
# exec chroot . what-follows <dev/console >dev/console 2>&1
|
||||
|
||||
Where what-follows is a program under the new root, e.g. /sbin/init
|
||||
Where what-follows is a program under the new root, e.g. ``/sbin/init``
|
||||
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.
|
||||
``/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:
|
||||
|
|
@ -244,13 +260,13 @@ to ensure compatibility, the following points should be observed:
|
|||
- use relative paths for dev/console in the exec command
|
||||
|
||||
Now, the initrd can be unmounted and the memory allocated by the RAM
|
||||
disk can be freed:
|
||||
disk can be freed::
|
||||
|
||||
# umount /initrd
|
||||
# blockdev --flushbufs /dev/ram0
|
||||
# umount /initrd
|
||||
# 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.
|
||||
:manpage:`pivot_root(8)` man page for details.
|
||||
|
||||
|
||||
Usage scenarios
|
||||
|
|
@ -263,21 +279,21 @@ 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) /sbin/init 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) /sbin/init loads the necessary kernel modules
|
||||
4) /sbin/init 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) /sbin/init 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
|
||||
modules that was used to bring up the system (e.g. /initrd can be
|
||||
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)
|
||||
``/dev/ram0`` or ``/dev/rd/0`` to a file)
|
||||
8) now the system is bootable and additional installation tasks can be
|
||||
performed
|
||||
|
||||
|
|
@ -290,7 +306,7 @@ 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 /sbin/init 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 is more convenient recovery disks, because information
|
||||
|
|
@ -301,9 +317,9 @@ 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
|
||||
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.
|
||||
floppies.
|
||||
|
||||
|
||||
Obsolete root change mechanism
|
||||
|
|
@ -316,51 +332,52 @@ continued availability.
|
|||
It works by mounting the "real" root device (i.e. the one set with rdev
|
||||
in the kernel image or with root=... at the boot command line) as the
|
||||
root file system when linuxrc exits. The initrd file system is then
|
||||
unmounted, or, if it is still busy, moved to a directory /initrd, if
|
||||
unmounted, or, if it is still busy, moved to a directory ``/initrd``, if
|
||||
such a directory exists on the new root file system.
|
||||
|
||||
In order to use this mechanism, you do not have to specify the boot
|
||||
command options root, init, or rw. (If specified, they will affect
|
||||
the real root file system, not the initrd environment.)
|
||||
|
||||
|
||||
If /proc is mounted, the "real" root device can be changed from within
|
||||
linuxrc by writing the number of the new root FS device to the special
|
||||
file /proc/sys/kernel/real-root-dev, e.g.
|
||||
file /proc/sys/kernel/real-root-dev, e.g.::
|
||||
|
||||
# echo 0x301 >/proc/sys/kernel/real-root-dev
|
||||
|
||||
Note that the mechanism is incompatible with NFS and similar file
|
||||
systems.
|
||||
|
||||
This old, deprecated mechanism is commonly called "change_root", while
|
||||
the new, supported mechanism is called "pivot_root".
|
||||
This old, deprecated mechanism is commonly called ``change_root``, while
|
||||
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.
|
||||
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:
|
||||
``/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
|
||||
#! /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.
|
||||
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
|
||||
---------
|
||||
|
||||
[1] Almesberger, Werner; "Booting Linux: The History and the Future"
|
||||
.. [#f1] Almesberger, Werner; "Booting Linux: The History and the Future"
|
||||
http://www.almesberger.net/cv/papers/ols2k-9.ps.gz
|
||||
[2] newlib package (experimental), with initrd example
|
||||
http://sources.redhat.com/newlib/
|
||||
[3] util-linux: Miscellaneous utilities for Linux
|
||||
http://www.kernel.org/pub/linux/utils/util-linux/
|
||||
.. [#f2] newlib package (experimental), with initrd example
|
||||
https://www.sourceware.org/newlib/
|
||||
.. [#f3] util-linux: Miscellaneous utilities for Linux
|
||||
https://www.kernel.org/pub/linux/utils/util-linux/
|
||||
|
|
|
|||
Loading…
Reference in New Issue