1
by Tim Gardner, Andy Whitcroft, Tim Gardner
[ Andy Whitcroft ] |
1 |
Using the initial RAM disk (initrd) |
2 |
=================================== |
|
3 |
||
4 |
Written 1996,2000 by Werner Almesberger <werner.almesberger@epfl.ch> and |
|
5 |
Hans Lermen <lermen@fgan.de> |
|
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=<path> (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 -H newc -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 <kernel> initrd=<disk_image> |
|
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=<path> 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 >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/ |