Lines Matching refs:the
1 Using the initial RAM disk (initrd)
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
15 where the kernel comes up with a minimum set of compiled-in drivers, and
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].
25 When using initrd, the system typically boots as follows:
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
33 4) root device is mounted. if it is /dev/ram0, the initrd image is
38 6) init mounts the "real" root file system
39 7) init places the root file system at the root directory using the
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
45 Note that changing the root directory does not involve unmounting it.
54 initrd adds the following new options:
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
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
71 as the last process has closed it, all data is freed and /dev/initrd
76 initrd is mounted as root, and the normal boot procedure is followed,
77 with the RAM disk mounted as root.
83 archive. On such systems, the creation of a ramdisk image doesn't need to
85 disk with the desired initrd content, cd to that directory, and run (as an
90 Examining the contents of an existing image file is just as simple:
99 First, a directory for the initrd file system has to be created on the
104 The name is not relevant. More details can be found on the pivot_root(2)
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.
112 accessible if the following device has been created:
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
120 system) must be compiled into the kernel.
122 Third, you have to create the RAM disk image. This is done by creating a
124 copying the content of the block device to the initrd file. With recent
129 - a loopback device (the most elegant solution)
131 We'll describe the loopback device method:
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.
137 (if space is critical, you may want to use the Minix FS instead of Ext2)
138 3) mount the file system, e.g.
140 4) create the console device:
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
146 6) correct operation the initrd environment can frequently be tested
147 even without rebooting with the command
149 This is of course limited to initrds that do not interfere with the
154 7) unmount the file system
156 8) the initrd is now in the file "initrd". Optionally, it can now be
162 can try the experimental newlib environment [2] to create a small
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
172 (rw is only necessary if writing to the initrd file system.)
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.
189 For other boot loaders, please refer to the respective documentation.
194 Changing the root device
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.
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
206 Mounting the new root file system is easy: it just needs to be mounted on
207 a directory under the current root. Example:
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
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
223 Now, the init process may still access the old root via its
225 current root directory. All these references are dropped by the
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
236 to ensure compatibility, the following points should be observed:
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
246 Now, the initrd can be unmounted and the memory allocated by the RAM
252 It is also possible to use initrd with an NFS-mounted root, see the
264 (e.g. support for RAM disks, initrd, a.out, and the Ext2 FS) and
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
269 done by asking the user, by auto-probing, or by using a hybrid
271 3) /sbin/init loads the necessary kernel modules
272 4) /sbin/init creates and populates the root file system (this doesn't
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
281 8) now the system is bootable and additional installation tasks can be
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.
291 (ideally only one) and to keep the system-specific part of configuration
293 generated with all the necessary modules. Then, only /sbin/init or a file
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
305 from the CD-ROM, and loading the RAM disk from CD without need of
312 The following mechanism was used before the introduction of pivot_root.
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
320 such a directory exists on the new root file system.
322 In order to use this mechanism, you do not have to specify the boot
324 the real root file system, not the initrd environment.)
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
332 Note that the mechanism is incompatible with NFS and similar file
336 the new, supported mechanism is called "pivot_root".
342 In case you did not want to use root=/dev/ram0 to trigger the pivot_root
345 /linuxrc would contain only the following:
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.
361 [1] Almesberger, Werner; "Booting Linux: The History and the Future"