Boot from persistent file system

[Jiri Svoboda]

Currently we always boot HelenOS from the initial ram disk (initrd). The boot stage (bootimage, Multiboot, etc.) loads the kernel, a set of initial servers and the initial ram disk. This initial ram disk contains the entire system image. It is possible to mount a persistent file system to a non-root location, though.

This has several drawbacks. As the system becomes larger the boot takes longer since the entire initial ram disk must be loaded immediately (and possibly decompressed and also deserialized, if it's using tmpfs). If we placed configuration files in the image they would not be preserved across reboots.

It is currently possible to set up a HelenOS system image manually on a persistent file system. However this assumes the set of initial servers is able to mount the root file system (without using a file system). This only works with non-DDF driver as Devman requires the file system (with driver binaries and .ma files).

This means that, for example, booting the system directly from an ATA disk will only work until #415 (Convert the ATA block device driver into a regular DDF driver) is implemented.

There are two main proposed strategies for making persistent boot work in this case:

• extend DDF to work (possibly in a limited fashion) even without a root file system
• use a two-stage boot with initrd and then, somehow, switch to the persistent file system (initrd needs to contain a sufficiently large subset of the system that allows mounting the persistent file system)

There were several variants proposed to address the 'switch' from initrd to the persistent file system:

• mount the persistent file system in a non-root (/) location, ask all servers that are already running (and using the file system) to switch to the new location
• same as above, but combined with chrooting into the persistent file system so that it becomes root (/)
• swap the initrd with the persistent file system transparently in VFS (pivot mount), as seen in Linux

We need to design an implement a strategy for booting from persistent file systems.

An interesting read is ​Ghosts of Unix past, part 2: Conflated designs which suggests an interesting alternative approach to pivot mounts, lazy unmounts etc. Also ​Ghosts of Unix past, part 3: Unfixable designs has more on Linux mounting and signals.

[Jiri Svoboda]

Couple of additional notes:

• while the flip-mount or chroot is not absolutely necessary, without it everything will need to be under an additional directory such as /sys, /w which will not be very nice
• chroot is probably the easiest thing to implement. We can chroot the entire VFS. Allowing different tasks to use different roots is not that easy ATM
• In case of live CD the root FS will be readonly and we can mount a writable FS (tmpfs or stash) to /cfg
• Need a way to locate the root fs. If we passed e.g. GRUB path to the OS command line, that would require translating from GRUB path to HelenOS device path, which would be difficult
• We can identify based on volume name or FS ID. Volume server will e.g. automatically mount the HelenOS CD into /vol/HelenOS-CD and we can just chroot there
• The problem is there are asynchronous steps in the device enumeration, filesystem mounting so we can't say when it's failed and not found… until fixed, we would just need to wait (possibly with some timeout)
• We need to define the contents of the minimized initial ram disk