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