1 |
3 |
xianfeng |
Using the initial RAM disk (initrd)
|
2 |
|
|
===================================
|
3 |
|
|
|
4 |
|
|
Written 1996,2000 by Werner Almesberger and
|
5 |
|
|
Hans Lermen
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
initrd provides the capability to load a RAM disk by the boot loader.
|
9 |
|
|
This RAM disk can then be mounted as the root file system and programs
|
10 |
|
|
can be run from it. Afterwards, a new root file system can be mounted
|
11 |
|
|
from a different device. The previous root (from initrd) is then moved
|
12 |
|
|
to a directory and can be subsequently 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 |
|
|
This document gives a brief overview of the use of initrd. A more detailed
|
19 |
|
|
discussion of the boot process can be found in [1].
|
20 |
|
|
|
21 |
|
|
|
22 |
|
|
Operation
|
23 |
|
|
---------
|
24 |
|
|
|
25 |
|
|
When using initrd, the system typically boots as follows:
|
26 |
|
|
|
27 |
|
|
1) the boot loader loads the kernel and the initial RAM disk
|
28 |
|
|
2) the kernel converts initrd into a "normal" RAM disk and
|
29 |
|
|
frees the memory used by initrd
|
30 |
|
|
3) if the root device is not /dev/ram0, the old (deprecated)
|
31 |
|
|
change_root procedure is followed. see the "Obsolete root change
|
32 |
|
|
mechanism" section below.
|
33 |
|
|
4) root device is mounted. if it is /dev/ram0, the initrd image is
|
34 |
|
|
then mounted as root
|
35 |
|
|
5) /sbin/init is executed (this can be any valid executable, including
|
36 |
|
|
shell scripts; it is run with uid 0 and can do basically everything
|
37 |
|
|
init can do).
|
38 |
|
|
6) init mounts the "real" root file system
|
39 |
|
|
7) init places the root file system at the root directory using the
|
40 |
|
|
pivot_root system call
|
41 |
|
|
8) init execs the /sbin/init on the new root filesystem, performing
|
42 |
|
|
the usual boot sequence
|
43 |
|
|
9) the initrd file system is removed
|
44 |
|
|
|
45 |
|
|
Note that changing the root directory does not involve unmounting it.
|
46 |
|
|
It is therefore possible to leave processes running on initrd during that
|
47 |
|
|
procedure. Also note that file systems mounted under initrd continue to
|
48 |
|
|
be accessible.
|
49 |
|
|
|
50 |
|
|
|
51 |
|
|
Boot command-line options
|
52 |
|
|
-------------------------
|
53 |
|
|
|
54 |
|
|
initrd adds the following new options:
|
55 |
|
|
|
56 |
|
|
initrd= (e.g. LOADLIN)
|
57 |
|
|
|
58 |
|
|
Loads the specified file as the initial RAM disk. When using LILO, you
|
59 |
|
|
have to specify the RAM disk image file in /etc/lilo.conf, using the
|
60 |
|
|
INITRD configuration variable.
|
61 |
|
|
|
62 |
|
|
noinitrd
|
63 |
|
|
|
64 |
|
|
initrd data is preserved but it is not converted to a RAM disk and
|
65 |
|
|
the "normal" root file system is mounted. initrd data can be read
|
66 |
|
|
from /dev/initrd. Note that the data in initrd can have any structure
|
67 |
|
|
in this case and doesn't necessarily have to be a file system image.
|
68 |
|
|
This option is used mainly for debugging.
|
69 |
|
|
|
70 |
|
|
Note: /dev/initrd is read-only and it can only be used once. As soon
|
71 |
|
|
as the last process has closed it, all data is freed and /dev/initrd
|
72 |
|
|
can't be opened anymore.
|
73 |
|
|
|
74 |
|
|
root=/dev/ram0
|
75 |
|
|
|
76 |
|
|
initrd is mounted as root, and the normal boot procedure is followed,
|
77 |
|
|
with the RAM disk mounted as root.
|
78 |
|
|
|
79 |
|
|
Compressed cpio images
|
80 |
|
|
----------------------
|
81 |
|
|
|
82 |
|
|
Recent kernels have support for populating a ramdisk from a compressed cpio
|
83 |
|
|
archive. On such systems, the creation of a ramdisk image doesn't need to
|
84 |
|
|
involve special block devices or loopbacks; you merely create a directory on
|
85 |
|
|
disk with the desired initrd content, cd to that directory, and run (as an
|
86 |
|
|
example):
|
87 |
|
|
|
88 |
|
|
find . | cpio --quiet -c -o | gzip -9 -n > /boot/imagefile.img
|
89 |
|
|
|
90 |
|
|
Examining the contents of an existing image file is just as simple:
|
91 |
|
|
|
92 |
|
|
mkdir /tmp/imagefile
|
93 |
|
|
cd /tmp/imagefile
|
94 |
|
|
gzip -cd /boot/imagefile.img | cpio -imd --quiet
|
95 |
|
|
|
96 |
|
|
Installation
|
97 |
|
|
------------
|
98 |
|
|
|
99 |
|
|
First, a directory for the initrd file system has to be created on the
|
100 |
|
|
"normal" root file system, e.g.
|
101 |
|
|
|
102 |
|
|
# mkdir /initrd
|
103 |
|
|
|
104 |
|
|
The name is not relevant. More details can be found on the pivot_root(2)
|
105 |
|
|
man page.
|
106 |
|
|
|
107 |
|
|
If the root file system is created during the boot procedure (i.e. if
|
108 |
|
|
you're building an install floppy), the root file system creation
|
109 |
|
|
procedure should create the /initrd directory.
|
110 |
|
|
|
111 |
|
|
If initrd will not be mounted in some cases, its content is still
|
112 |
|
|
accessible if the following device has been created:
|
113 |
|
|
|
114 |
|
|
# mknod /dev/initrd b 1 250
|
115 |
|
|
# chmod 400 /dev/initrd
|
116 |
|
|
|
117 |
|
|
Second, the kernel has to be compiled with RAM disk support and with
|
118 |
|
|
support for the initial RAM disk enabled. Also, at least all components
|
119 |
|
|
needed to execute programs from initrd (e.g. executable format and file
|
120 |
|
|
system) must be compiled into the kernel.
|
121 |
|
|
|
122 |
|
|
Third, you have to create the RAM disk image. This is done by creating a
|
123 |
|
|
file system on a block device, copying files to it as needed, and then
|
124 |
|
|
copying the content of the block device to the initrd file. With recent
|
125 |
|
|
kernels, at least three types of devices are suitable for that:
|
126 |
|
|
|
127 |
|
|
- a floppy disk (works everywhere but it's painfully slow)
|
128 |
|
|
- a RAM disk (fast, but allocates physical memory)
|
129 |
|
|
- a loopback device (the most elegant solution)
|
130 |
|
|
|
131 |
|
|
We'll describe the loopback device method:
|
132 |
|
|
|
133 |
|
|
1) make sure loopback block devices are configured into the kernel
|
134 |
|
|
2) create an empty file system of the appropriate size, e.g.
|
135 |
|
|
# dd if=/dev/zero of=initrd bs=300k count=1
|
136 |
|
|
# mke2fs -F -m0 initrd
|
137 |
|
|
(if space is critical, you may want to use the Minix FS instead of Ext2)
|
138 |
|
|
3) mount the file system, e.g.
|
139 |
|
|
# mount -t ext2 -o loop initrd /mnt
|
140 |
|
|
4) create the console device:
|
141 |
|
|
# mkdir /mnt/dev
|
142 |
|
|
# mknod /mnt/dev/console c 5 1
|
143 |
|
|
5) copy all the files that are needed to properly use the initrd
|
144 |
|
|
environment. Don't forget the most important file, /sbin/init
|
145 |
|
|
Note that /sbin/init's permissions must include "x" (execute).
|
146 |
|
|
6) correct operation the initrd environment can frequently be tested
|
147 |
|
|
even without rebooting with the command
|
148 |
|
|
# chroot /mnt /sbin/init
|
149 |
|
|
This is of course limited to initrds that do not interfere with the
|
150 |
|
|
general system state (e.g. by reconfiguring network interfaces,
|
151 |
|
|
overwriting mounted devices, trying to start already running demons,
|
152 |
|
|
etc. Note however that it is usually possible to use pivot_root in
|
153 |
|
|
such a chroot'ed initrd environment.)
|
154 |
|
|
7) unmount the file system
|
155 |
|
|
# umount /mnt
|
156 |
|
|
8) the initrd is now in the file "initrd". Optionally, it can now be
|
157 |
|
|
compressed
|
158 |
|
|
# gzip -9 initrd
|
159 |
|
|
|
160 |
|
|
For experimenting with initrd, you may want to take a rescue floppy and
|
161 |
|
|
only add a symbolic link from /sbin/init to /bin/sh. Alternatively, you
|
162 |
|
|
can try the experimental newlib environment [2] to create a small
|
163 |
|
|
initrd.
|
164 |
|
|
|
165 |
|
|
Finally, you have to boot the kernel and load initrd. Almost all Linux
|
166 |
|
|
boot loaders support initrd. Since the boot process is still compatible
|
167 |
|
|
with an older mechanism, the following boot command line parameters
|
168 |
|
|
have to be given:
|
169 |
|
|
|
170 |
|
|
root=/dev/ram0 rw
|
171 |
|
|
|
172 |
|
|
(rw is only necessary if writing to the initrd file system.)
|
173 |
|
|
|
174 |
|
|
With LOADLIN, you simply execute
|
175 |
|
|
|
176 |
|
|
LOADLIN initrd=
|
177 |
|
|
e.g. LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0 rw
|
178 |
|
|
|
179 |
|
|
With LILO, you add the option INITRD= to either the global section
|
180 |
|
|
or to the section of the respective kernel in /etc/lilo.conf, and pass
|
181 |
|
|
the options using APPEND, e.g.
|
182 |
|
|
|
183 |
|
|
image = /bzImage
|
184 |
|
|
initrd = /boot/initrd.gz
|
185 |
|
|
append = "root=/dev/ram0 rw"
|
186 |
|
|
|
187 |
|
|
and run /sbin/lilo
|
188 |
|
|
|
189 |
|
|
For other boot loaders, please refer to the respective documentation.
|
190 |
|
|
|
191 |
|
|
Now you can boot and enjoy using initrd.
|
192 |
|
|
|
193 |
|
|
|
194 |
|
|
Changing the root device
|
195 |
|
|
------------------------
|
196 |
|
|
|
197 |
|
|
When finished with its duties, init typically changes the root device
|
198 |
|
|
and proceeds with starting the Linux system on the "real" root device.
|
199 |
|
|
|
200 |
|
|
The procedure involves the following steps:
|
201 |
|
|
- mounting the new root file system
|
202 |
|
|
- turning it into the root file system
|
203 |
|
|
- removing all accesses to the old (initrd) root file system
|
204 |
|
|
- unmounting the initrd file system and de-allocating the RAM disk
|
205 |
|
|
|
206 |
|
|
Mounting the new root file system is easy: it just needs to be mounted on
|
207 |
|
|
a directory under the current root. Example:
|
208 |
|
|
|
209 |
|
|
# mkdir /new-root
|
210 |
|
|
# mount -o ro /dev/hda1 /new-root
|
211 |
|
|
|
212 |
|
|
The root change is accomplished with the pivot_root system call, which
|
213 |
|
|
is also available via the pivot_root utility (see pivot_root(8) man
|
214 |
|
|
page; pivot_root is distributed with util-linux version 2.10h or higher
|
215 |
|
|
[3]). pivot_root moves the current root to a directory under the new
|
216 |
|
|
root, and puts the new root at its place. The directory for the old root
|
217 |
|
|
must exist before calling pivot_root. Example:
|
218 |
|
|
|
219 |
|
|
# cd /new-root
|
220 |
|
|
# mkdir initrd
|
221 |
|
|
# pivot_root . initrd
|
222 |
|
|
|
223 |
|
|
Now, the init process may still access the old root via its
|
224 |
|
|
executable, shared libraries, standard input/output/error, and its
|
225 |
|
|
current root directory. All these references are dropped by the
|
226 |
|
|
following command:
|
227 |
|
|
|
228 |
|
|
# exec chroot . what-follows dev/console 2>&1
|
229 |
|
|
|
230 |
|
|
Where what-follows is a program under the new root, e.g. /sbin/init
|
231 |
|
|
If the new root file system will be used with udev and has no valid
|
232 |
|
|
/dev directory, udev must be initialized before invoking chroot in order
|
233 |
|
|
to provide /dev/console.
|
234 |
|
|
|
235 |
|
|
Note: implementation details of pivot_root may change with time. In order
|
236 |
|
|
to ensure compatibility, the following points should be observed:
|
237 |
|
|
|
238 |
|
|
- before calling pivot_root, the current directory of the invoking
|
239 |
|
|
process should point to the new root directory
|
240 |
|
|
- use . as the first argument, and the _relative_ path of the directory
|
241 |
|
|
for the old root as the second argument
|
242 |
|
|
- a chroot program must be available under the old and the new root
|
243 |
|
|
- chroot to the new root afterwards
|
244 |
|
|
- use relative paths for dev/console in the exec command
|
245 |
|
|
|
246 |
|
|
Now, the initrd can be unmounted and the memory allocated by the RAM
|
247 |
|
|
disk can be freed:
|
248 |
|
|
|
249 |
|
|
# umount /initrd
|
250 |
|
|
# blockdev --flushbufs /dev/ram0
|
251 |
|
|
|
252 |
|
|
It is also possible to use initrd with an NFS-mounted root, see the
|
253 |
|
|
pivot_root(8) man page for details.
|
254 |
|
|
|
255 |
|
|
|
256 |
|
|
Usage scenarios
|
257 |
|
|
---------------
|
258 |
|
|
|
259 |
|
|
The main motivation for implementing initrd was to allow for modular
|
260 |
|
|
kernel configuration at system installation. The procedure would work
|
261 |
|
|
as follows:
|
262 |
|
|
|
263 |
|
|
1) system boots from floppy or other media with a minimal kernel
|
264 |
|
|
(e.g. support for RAM disks, initrd, a.out, and the Ext2 FS) and
|
265 |
|
|
loads initrd
|
266 |
|
|
2) /sbin/init determines what is needed to (1) mount the "real" root FS
|
267 |
|
|
(i.e. device type, device drivers, file system) and (2) the
|
268 |
|
|
distribution media (e.g. CD-ROM, network, tape, ...). This can be
|
269 |
|
|
done by asking the user, by auto-probing, or by using a hybrid
|
270 |
|
|
approach.
|
271 |
|
|
3) /sbin/init loads the necessary kernel modules
|
272 |
|
|
4) /sbin/init creates and populates the root file system (this doesn't
|
273 |
|
|
have to be a very usable system yet)
|
274 |
|
|
5) /sbin/init invokes pivot_root to change the root file system and
|
275 |
|
|
execs - via chroot - a program that continues the installation
|
276 |
|
|
6) the boot loader is installed
|
277 |
|
|
7) the boot loader is configured to load an initrd with the set of
|
278 |
|
|
modules that was used to bring up the system (e.g. /initrd can be
|
279 |
|
|
modified, then unmounted, and finally, the image is written from
|
280 |
|
|
/dev/ram0 or /dev/rd/0 to a file)
|
281 |
|
|
8) now the system is bootable and additional installation tasks can be
|
282 |
|
|
performed
|
283 |
|
|
|
284 |
|
|
The key role of initrd here is to re-use the configuration data during
|
285 |
|
|
normal system operation without requiring the use of a bloated "generic"
|
286 |
|
|
kernel or re-compiling or re-linking the kernel.
|
287 |
|
|
|
288 |
|
|
A second scenario is for installations where Linux runs on systems with
|
289 |
|
|
different hardware configurations in a single administrative domain. In
|
290 |
|
|
such cases, it is desirable to generate only a small set of kernels
|
291 |
|
|
(ideally only one) and to keep the system-specific part of configuration
|
292 |
|
|
information as small as possible. In this case, a common initrd could be
|
293 |
|
|
generated with all the necessary modules. Then, only /sbin/init or a file
|
294 |
|
|
read by it would have to be different.
|
295 |
|
|
|
296 |
|
|
A third scenario is more convenient recovery disks, because information
|
297 |
|
|
like the location of the root FS partition doesn't have to be provided at
|
298 |
|
|
boot time, but the system loaded from initrd can invoke a user-friendly
|
299 |
|
|
dialog and it can also perform some sanity checks (or even some form of
|
300 |
|
|
auto-detection).
|
301 |
|
|
|
302 |
|
|
Last not least, CD-ROM distributors may use it for better installation
|
303 |
|
|
from CD, e.g. by using a boot floppy and bootstrapping a bigger RAM disk
|
304 |
|
|
via initrd from CD; or by booting via a loader like LOADLIN or directly
|
305 |
|
|
from the CD-ROM, and loading the RAM disk from CD without need of
|
306 |
|
|
floppies.
|
307 |
|
|
|
308 |
|
|
|
309 |
|
|
Obsolete root change mechanism
|
310 |
|
|
------------------------------
|
311 |
|
|
|
312 |
|
|
The following mechanism was used before the introduction of pivot_root.
|
313 |
|
|
Current kernels still support it, but you should _not_ rely on its
|
314 |
|
|
continued availability.
|
315 |
|
|
|
316 |
|
|
It works by mounting the "real" root device (i.e. the one set with rdev
|
317 |
|
|
in the kernel image or with root=... at the boot command line) as the
|
318 |
|
|
root file system when linuxrc exits. The initrd file system is then
|
319 |
|
|
unmounted, or, if it is still busy, moved to a directory /initrd, if
|
320 |
|
|
such a directory exists on the new root file system.
|
321 |
|
|
|
322 |
|
|
In order to use this mechanism, you do not have to specify the boot
|
323 |
|
|
command options root, init, or rw. (If specified, they will affect
|
324 |
|
|
the real root file system, not the initrd environment.)
|
325 |
|
|
|
326 |
|
|
If /proc is mounted, the "real" root device can be changed from within
|
327 |
|
|
linuxrc by writing the number of the new root FS device to the special
|
328 |
|
|
file /proc/sys/kernel/real-root-dev, e.g.
|
329 |
|
|
|
330 |
|
|
# echo 0x301 >/proc/sys/kernel/real-root-dev
|
331 |
|
|
|
332 |
|
|
Note that the mechanism is incompatible with NFS and similar file
|
333 |
|
|
systems.
|
334 |
|
|
|
335 |
|
|
This old, deprecated mechanism is commonly called "change_root", while
|
336 |
|
|
the new, supported mechanism is called "pivot_root".
|
337 |
|
|
|
338 |
|
|
|
339 |
|
|
Mixed change_root and pivot_root mechanism
|
340 |
|
|
------------------------------------------
|
341 |
|
|
|
342 |
|
|
In case you did not want to use root=/dev/ram0 to trigger the pivot_root
|
343 |
|
|
mechanism, you may create both /linuxrc and /sbin/init in your initrd image.
|
344 |
|
|
|
345 |
|
|
/linuxrc would contain only the following:
|
346 |
|
|
|
347 |
|
|
#! /bin/sh
|
348 |
|
|
mount -n -t proc proc /proc
|
349 |
|
|
echo 0x0100 >/proc/sys/kernel/real-root-dev
|
350 |
|
|
umount -n /proc
|
351 |
|
|
|
352 |
|
|
Once linuxrc exited, the kernel would mount again your initrd as root,
|
353 |
|
|
this time executing /sbin/init. Again, it would be the duty of this init
|
354 |
|
|
to build the right environment (maybe using the root= device passed on
|
355 |
|
|
the cmdline) before the final execution of the real /sbin/init.
|
356 |
|
|
|
357 |
|
|
|
358 |
|
|
Resources
|
359 |
|
|
---------
|
360 |
|
|
|
361 |
|
|
[1] Almesberger, Werner; "Booting Linux: The History and the Future"
|
362 |
|
|
http://www.almesberger.net/cv/papers/ols2k-9.ps.gz
|
363 |
|
|
[2] newlib package (experimental), with initrd example
|
364 |
|
|
http://sources.redhat.com/newlib/
|
365 |
|
|
[3] Brouwer, Andries; "util-linux: Miscellaneous utilities for Linux"
|
366 |
|
|
ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/
|