1 Using the initial RAM disk (initrd)
2 ===================================
3
4 Written 1996,2000 by Werner Almesberger <werner
5 Hans Lermen <lermen@fgan.de>
6
7
8 initrd provides the capability to load a RAM d
9 This RAM disk can then be mounted as the root
10 can be run from it. Afterwards, a new root fil
11 from a different device. The previous root (fr
12 to a directory and can be subsequently unmount
13
14 initrd is mainly designed to allow system star
15 where the kernel comes up with a minimum set o
16 where additional modules are loaded from initr
17
18 This document gives a brief overview of the us
19 discussion of the boot process can be found in
20
21
22 Operation
23 ---------
24
25 When using initrd, the system typically boots
26
27 1) the boot loader loads the kernel and the
28 2) the kernel converts initrd into a "normal
29 frees the memory used by initrd
30 3) if the root device is not ``/dev/ram0``,
31 change_root procedure is followed. see th
32 mechanism" section below.
33 4) root device is mounted. if it is ``/dev/r
34 then mounted as root
35 5) /sbin/init is executed (this can be any v
36 shell scripts; it is run with uid 0 and c
37 init can do).
38 6) init mounts the "real" root file system
39 7) init places the root file system at the r
40 pivot_root system call
41 8) init execs the ``/sbin/init`` on the new
42 the usual boot sequence
43 9) the initrd file system is removed
44
45 Note that changing the root directory does not
46 It is therefore possible to leave processes ru
47 procedure. Also note that file systems mounted
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 RA
59 have to specify the RAM disk image file in
60 INITRD configuration variable.
61
62 noinitrd
63
64 initrd data is preserved but it is not con
65 the "normal" root file system is mounted.
66 from /dev/initrd. Note that the data in in
67 in this case and doesn't necessarily have
68 This option is used mainly for debugging.
69
70 Note: /dev/initrd is read-only and it can
71 as the last process has closed it, all dat
72 can't be opened anymore.
73
74 root=/dev/ram0
75
76 initrd is mounted as root, and the normal
77 with the RAM disk mounted as root.
78
79 Compressed cpio images
80 ----------------------
81
82 Recent kernels have support for populating a r
83 archive. On such systems, the creation of a ra
84 involve special block devices or loopbacks; yo
85 disk with the desired initrd content, cd to th
86 example)::
87
88 find . | cpio --quiet -H newc -o | gzi
89
90 Examining the contents of an existing image fi
91
92 mkdir /tmp/imagefile
93 cd /tmp/imagefile
94 gzip -cd /boot/imagefile.img | cpio -i
95
96 Installation
97 ------------
98
99 First, a directory for the initrd file system
100 "normal" root file system, e.g.::
101
102 # mkdir /initrd
103
104 The name is not relevant. More details can be
105 :manpage:`pivot_root(2)` man page.
106
107 If the root file system is created during the
108 you're building an install floppy), the root f
109 procedure should create the ``/initrd`` direct
110
111 If initrd will not be mounted in some cases, i
112 accessible if the following device has been cr
113
114 # mknod /dev/initrd b 1 250
115 # chmod 400 /dev/initrd
116
117 Second, the kernel has to be compiled with RAM
118 support for the initial RAM disk enabled. Also
119 needed to execute programs from initrd (e.g. e
120 system) must be compiled into the kernel.
121
122 Third, you have to create the RAM disk image.
123 file system on a block device, copying files t
124 copying the content of the block device to the
125 kernels, at least three types of devices are s
126
127 - a floppy disk (works everywhere but it's pa
128 - a RAM disk (fast, but allocates physical me
129 - a loopback device (the most elegant solutio
130
131 We'll describe the loopback device method:
132
133 1) make sure loopback block devices are confi
134 2) create an empty file system of the appropr
135
136 # dd if=/dev/zero of=initrd bs=300k co
137 # mke2fs -F -m0 initrd
138
139 (if space is critical, you may want to use
140 3) mount the file system, e.g.::
141
142 # mount -t ext2 -o loop initrd /mnt
143
144 4) create the console device::
145
146 # mkdir /mnt/dev
147 # mknod /mnt/dev/console c 5 1
148
149 5) copy all the files that are needed to prop
150 environment. Don't forget the most importa
151
152 .. note:: ``/sbin/init`` permissions must
153
154 6) correct operation the initrd environment c
155 even without rebooting with the command::
156
157 # chroot /mnt /sbin/init
158
159 This is of course limited to initrds that
160 general system state (e.g. by reconfigurin
161 overwriting mounted devices, trying to sta
162 etc. Note however that it is usually possi
163 such a chroot'ed initrd environment.)
164 7) unmount the file system::
165
166 # umount /mnt
167
168 8) the initrd is now in the file "initrd". Op
169 compressed::
170
171 # gzip -9 initrd
172
173 For experimenting with initrd, you may want to
174 only add a symbolic link from ``/sbin/init`` t
175 can try the experimental newlib environment [#
176 initrd.
177
178 Finally, you have to boot the kernel and load
179 boot loaders support initrd. Since the boot pr
180 with an older mechanism, the following boot co
181 have to be given::
182
183 root=/dev/ram0 rw
184
185 (rw is only necessary if writing to the initrd
186
187 With LOADLIN, you simply execute::
188
189 LOADLIN <kernel> initrd=<disk_image>
190
191 e.g.::
192
193 LOADLIN C:\LINUX\BZIMAGE initrd=C:\LIN
194
195 With LILO, you add the option ``INITRD=<path>`
196 or to the section of the respective kernel in
197 the options using APPEND, e.g.::
198
199 image = /bzImage
200 initrd = /boot/initrd.gz
201 append = "root=/dev/ram0 rw"
202
203 and run ``/sbin/lilo``
204
205 For other boot loaders, please refer to the re
206
207 Now you can boot and enjoy using initrd.
208
209
210 Changing the root device
211 ------------------------
212
213 When finished with its duties, init typically
214 and proceeds with starting the Linux system on
215
216 The procedure involves the following steps:
217 - mounting the new root file system
218 - turning it into the root file system
219 - removing all accesses to the old (initrd) r
220 - unmounting the initrd file system and de-al
221
222 Mounting the new root file system is easy: it
223 a directory under the current root. Example::
224
225 # mkdir /new-root
226 # mount -o ro /dev/hda1 /new-root
227
228 The root change is accomplished with the pivot
229 is also available via the ``pivot_root`` utili
230 man page; ``pivot_root`` is distributed with u
231 [#f3]_). ``pivot_root`` moves the current root
232 root, and puts the new root at its place. The
233 must exist before calling ``pivot_root``. Exam
234
235 # cd /new-root
236 # mkdir initrd
237 # pivot_root . initrd
238
239 Now, the init process may still access the old
240 executable, shared libraries, standard input/o
241 current root directory. All these references a
242 following command::
243
244 # exec chroot . what-follows <dev/cons
245
246 Where what-follows is a program under the new
247 If the new root file system will be used with
248 ``/dev`` directory, udev must be initialized b
249 to provide ``/dev/console``.
250
251 Note: implementation details of pivot_root may
252 to ensure compatibility, the following points
253
254 - before calling pivot_root, the current dire
255 process should point to the new root direct
256 - use . as the first argument, and the _relat
257 for the old root as the second argument
258 - a chroot program must be available under th
259 - chroot to the new root afterwards
260 - use relative paths for dev/console in the e
261
262 Now, the initrd can be unmounted and the memor
263 disk can be freed::
264
265 # umount /initrd
266 # blockdev --flushbufs /dev/ram0
267
268 It is also possible to use initrd with an NFS-
269 :manpage:`pivot_root(8)` man page for details.
270
271
272 Usage scenarios
273 ---------------
274
275 The main motivation for implementing initrd wa
276 kernel configuration at system installation. T
277 as follows:
278
279 1) system boots from floppy or other media w
280 (e.g. support for RAM disks, initrd, a.ou
281 loads initrd
282 2) ``/sbin/init`` determines what is needed
283 (i.e. device type, device drivers, file s
284 distribution media (e.g. CD-ROM, network,
285 done by asking the user, by auto-probing,
286 approach.
287 3) ``/sbin/init`` loads the necessary kernel
288 4) ``/sbin/init`` creates and populates the
289 have to be a very usable system yet)
290 5) ``/sbin/init`` invokes ``pivot_root`` to
291 execs - via chroot - a program that conti
292 6) the boot loader is installed
293 7) the boot loader is configured to load an
294 modules that was used to bring up the sys
295 modified, then unmounted, and finally, th
296 ``/dev/ram0`` or ``/dev/rd/0`` to a file)
297 8) now the system is bootable and additional
298 performed
299
300 The key role of initrd here is to re-use the c
301 normal system operation without requiring the
302 kernel or re-compiling or re-linking the kerne
303
304 A second scenario is for installations where L
305 different hardware configurations in a single
306 such cases, it is desirable to generate only a
307 (ideally only one) and to keep the system-spec
308 information as small as possible. In this case
309 generated with all the necessary modules. Then
310 read by it would have to be different.
311
312 A third scenario is more convenient recovery d
313 like the location of the root FS partition doe
314 boot time, but the system loaded from initrd c
315 dialog and it can also perform some sanity che
316 auto-detection).
317
318 Last not least, CD-ROM distributors may use it
319 from CD, e.g. by using a boot floppy and boots
320 via initrd from CD; or by booting via a loader
321 from the CD-ROM, and loading the RAM disk from
322 floppies.
323
324
325 Obsolete root change mechanism
326 ------------------------------
327
328 The following mechanism was used before the in
329 Current kernels still support it, but you shou
330 continued availability.
331
332 It works by mounting the "real" root device (i
333 in the kernel image or with root=... at the bo
334 root file system when linuxrc exits. The initr
335 unmounted, or, if it is still busy, moved to a
336 such a directory exists on the new root file s
337
338 In order to use this mechanism, you do not hav
339 command options root, init, or rw. (If specifi
340 the real root file system, not the initrd envi
341
342 If /proc is mounted, the "real" root device ca
343 linuxrc by writing the number of the new root
344 file /proc/sys/kernel/real-root-dev, e.g.::
345
346 # echo 0x301 >/proc/sys/kernel/real-root-dev
347
348 Note that the mechanism is incompatible with N
349 systems.
350
351 This old, deprecated mechanism is commonly cal
352 the new, supported mechanism is called ``pivot
353
354
355 Mixed change_root and pivot_root mechanism
356 ------------------------------------------
357
358 In case you did not want to use ``root=/dev/ra
359 mechanism, you may create both ``/linuxrc`` an
360 image.
361
362 ``/linuxrc`` would contain only the following:
363
364 #! /bin/sh
365 mount -n -t proc proc /proc
366 echo 0x0100 >/proc/sys/kernel/real-roo
367 umount -n /proc
368
369 Once linuxrc exited, the kernel would mount ag
370 this time executing ``/sbin/init``. Again, it
371 to build the right environment (maybe using th
372 the cmdline) before the final execution of the
373
374
375 Resources
376 ---------
377
378 .. [#f1] Almesberger, Werner; "Booting Linux:
379 https://www.almesberger.net/cv/papers/ols2
380 .. [#f2] newlib package (experimental), with i
381 https://www.sourceware.org/newlib/
382 .. [#f3] util-linux: Miscellaneous utilities f
383 https://www.kernel.org/pub/linux/utils/uti
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.