The initial boot image is supposed to load enough modules to let the real root device be mounted cleanly. It starts up in a very bare environment and it has to do tricky stuff like juggling root filesystems; to pull that off successfully it makes sense to take a close look at the environment that the kernel creates for the image and what the kernel expects it to do. This section contains raw design notes based on kernel 2.6.8. The processing of the image starts even before the kernel is activated. The bootloader, grub or lilo for example, reads two files from the boot file system into ram: the kernel and image. The bootloader somehow manages to set two variables in the kernel: initrd_start and initrd_end; these variables point to the copy of the image in ram. The bootloader now hands over control to the kernel. During setup, the kernel creates a special file system, rootfs. This mostly reuses ramfs code, but there are a few twists: it can never be mounted from userspace, there's only one copy, and it's not mounted on top of anything else. The existence of rootfs means that the rest of the kernel always can assume there's a place to mount other file systems. It also is a place where temporary files can be created during the boot sequence. In initramfs.c:populate_rootfs(), there are two possibilities. If the image looks like a cpio.gz file, it is unpacked into rootfs. If the file /init is among the files unpacked from the cpio file, the initramfs model is used; otherwise we get a more complex interaction between kernel and initrd, discussed in . If the image was a cpio file, and it contains a file /init, the initram model is used. The kernel does some basic setup and hands over control to /init; it is then up to /init to make a real root available and to transfer control to the /sbin/init command on the real root. The tricky part is to do that in such a way that there is no way for user processes to gain access to the rootfs filesystem; and in such a way that rootfs remains empty and hidden under the user root file system. This is best done using some C code; yaird uses run_init, a small tool based on klibc. # invoked as last command in /init, with no other processes running, # as follows: # exec run_init /newroot /sbin/init "$@" - chdir /newroot # following after lots of sanity checks and not across mounts: - rm -rf /* - mount --move . / - chroot . - chdir / - open /dev/console - exec /sbin/init "$@" If the image was not a cpio file, the kernel copies the initrd image from where ever the boot loader left it to rootfs:/initrd.image, and frees the ram used by the bootloader for the initrd image. After reading initrd, the kernel does more setup to the point where we have: working CPU and memory management working process management compiled in drivers activated a number of support processes such as ksoftirqd are created. (These processes have the rootfs as root; they can get a new root when the pivot_root() system call is used.) something like a console. Console_init() is called before PCI or USB probes, so expect only compiled in console devices to work. At this point, in do_mounts.c:prepare_namespace(), the kernel looks for a root filesystem to mount. That root file system can come from a number of places: NFS, a raid device, a plain disk or an initrd. If it's an initrd, the sequence is as follows (where devfs can fail if it's not compiled into the kernel) - mount -t devfs devfs /dev - md_run_setup() - process initrd - umount /dev - mount --move . / - chroot . - mount -t devfs devfs /dev Once that returns, in init/main.c:init(), initialisation memory is freed and /sbin/init is executed with /dev/console as file descriptor 0, 1 and 2. /sbin/init can be overruled with an init=/usr/bin/firefox parameter passed to the boot loader; if /sbin/init is not found, /etc/init and a number of other fallbacks are tried. We're in business. The processing of initrd starts in do_mounts_initrd.c:initrd_load(). It creates rootfs:/dev/ram, then copies rootfs:/initrd.image there and unlinks rootfs:/initrd.image. Now we have the initrd image in a block device, which is good for mounting. It calls handle_initrd(), which does: # make another block special file for ram0 - mknod /dev/root.old b 1 0 # try mounting initrd with all known file systems, # optionally read-only - mount -t xxx /dev/root.old /root - mkdir rootfs:/old - cd /root - mount --move . / - chroot . - mount -t devfs devfs /dev - system ("/linuxrc"); - cd rootfs:/old - mount --move / . - cd rootfs:/ - chroot . - umount rootfs:/old/dev - ... more ... So initrd:/linuxrc runs in an environment where initrd is the root, with devfs mounted if available, and rootfs is invisible (except that there are open file handles to directories in rootfs, needed to change back to the old environment). Now the idea seems to have been that /linuxrc would mount the real root and pivot_root into it, then start /sbin/init. Thus, linuxrc would never return. However, main.c:init() does some usefull stuff only after linuxrc returns: freeing init memory segments and starting numa policy, so in eg Debian and Fedora, /linuxrc will end, and /sbin/init is started by main.c:init(). After linuxrc returns, the variable real_root_dev determines what happens. This variable can be read and written via /proc/sys/kernel/real-root-dev. If it is 0x0100 (the device number of /dev/ram0) or something equivalent, handle_initrd() will change directory to /old and return. If it is something else, handle_initrd() will decode it, mount it as root, mount initrd as /root/initrd, and again start /sbin/init. (if mounting as /root/initrd fails, the block device is freed.) Remember handle_initrd() was called via load_initrd() from prepare_namespace(), and prepare_namespace() ends by chrooting into the current directory: rootfs:/old. Note that rootfs:/old was move-mounted from '/' after /linuxrc returned. When /linuxrc started, the root was initrd, but /linuxrc may have done a pivot_root(), replacing the root with a real root, say /dev/hda1. Thus: /linuxrc is started with initrd mounted as root. There is working memory management, processes, compiled in drivers, and stdin/out/err are connected to a console, if the relevant drivers are compiled in. Devfs may be mounted on /dev. /linuxrc can pivot_root. If you echo 0x0100 to /proc/sys/kernel/real-root-dev, the pivot_root will remain in effect after /linuxrc ends. After /linuxrc returns, /dev may be unmounted and replaced with devfs. Thus a good strategy for /linuxrc is to do as little as possible, and defer the real initialisation to /sbin/init on the initrd; this /sbin/init can then pivot_root into the real root device. #!/bin/dash set -x mount -nt proc proc /proc # root=$(cat proc/sys/kernel/real-root-dev) echo 256 > proc/sys/kernel/real-root-dev umount -n /proc The kernel passes more information than just an initial file system to the initrd or initramfs image; there also are the kernel boot parameters. The bootloader passes these to the kernel, and the kernel in turn passes them on via /proc/cmdline. An old version of these parameters is documented in the bootparam 7 manual page; more recent information is in the kernel documentation file kernel-parameters.txt. Mostly, these parameters are used to configure non-modular drivers, and thus not very interesting to yaird. Then there are parameters such as noapic, which are interpreted by the kernel core and also irrelevant to yaird. Finally there are a few parameters which are used by the kernel to determine how to mount the root file system. Whether the initial image should emulate these options or ignore them is open to discussion; you can make a case that the flexibility these options offer has become irrelevant now that initrd/initramfs offers far more fine grained control over the way in which the system is booted. Support for these options is mostly a matter of tuning the distribution specific templates, but it is possible that the templates need an occassional hint from the planner. To find out just how much "mostly" is, we'll try to implement full support for these options and see where we run into limitations. An inventarisation of relevant options. ydebug The kernel does not know about this option, so we can use it to enable debugging in the generated image. ide These are options for the modular ide-core driver. This could be supported by adding an attribute "isIdeCore" to insmod actions, and expanding the ide kernel options only for insmod actions where that attribute is true. It seems cleaner to support the options from /etc/modprobe.conf. Unsupported for now. init The first program to be started on the definitive root device, default /sbin/init. Supported. ro Mount the definitive root device read only, so that it can be submitted to fsck. Supported; this is the default behaviour. rw Three guesses. Supported. resume, noresume Which device (not) to use for software suspend. To be done. root The device to mount as root. This is a nasty one: the planner by default only creates device nodes that are needed to mount the root device, and even if you were to put hotplug on the inital image to create all possible device nodes, there's still the matter of putting support for the proper file system on the initial image. We could make an option to yaird to specify a list of possible root devices and load the necessary modules for all of them. Unsupported until there's a clear need for it. rootflags Flags to use while mounting root file system. Implement together with root option. rootfstype File system type for root file system. Implement together with root option. ip, nfsaddrs = <client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf> These two are aliases, with "ip" being the preferred form. This option may appear more than once. It tells the kernel to configure a network device, either based on values that are part of the option string or based values supplied by DHCP. In yaird, it also triggers the mounting of an NFS root. The idea that the "ip=" kernel command line option implies mounting an NFS root is debatable. Since the only use of the network for now is mounting NFS we can get away with it, and it simplifies passing a DHCP supplied boot path to the NFS mount code. If we find situations where IP is needed but NFS is not, we'll have to trigger NFS mount when "root=/dev/nfs". See and the kernel documentation file nfsroot.txt for details. nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>] Where the root file system to be mounted is coming from. If you don't give any options, we try first with NFS over TCP, then over UDP and finally NFSv2. If DHCP specifies a root directory, server and root are based on DHCP, but options in nfsroot are still applied. If nfsroot does not give server-ip, the server IP given by DHCP is used.