Re: How to supervise an early process [s6-svscan root pivot]

From: Martin \ <et.code_at_ethome.sk>
Date: Wed, 22 Jun 2016 09:06:33 +0200

On Tue, 21 Jun 2016 13:36:38 -0400
Steve Litt <slitt_at_troubleshooters.com> wrote:

> ... doesn't the bootloader config already contain the
> info to know which device, and isn't that device mounted before the
> initramfs does the switch_root or pivot_root? What do they need udevd
> for? They have the UUID, for gosh sakes.

On Linux bootloader usually loads ramdisk from /boot. On
FreeBSD it loads kernel and modules which reside in /boot/kernel and ramdisk is
usually not needed at all.

The thing is though, /boot is not exactly directly related to actual "cruise"
root in many cases.

Take for example ZFS, where rootfs (/) can be any nested ZFS filesystem in any
ZFS pool present on the machine. Although it contains /boot inside, it's not
even partition in such setups. There might be even multiple(!) rootfses present
with only one being active.

There is no way for bios/uefi to know about this. More over firmware doesn't
even understand ZFS. Thus you need kernel with drivers/modules loaded to access
the root.

Hopefully loader on FreeBSD understands enough of ZFS and pool properties
to find "rootfs", /boot/kernel in it and fire the machine up.

Some similar dance is necessary on Linux as well. There you can also have ext*
root and use ZFS for rest of the system only.

This is IMHO correct, I personally would rather see "bootloader/ramdisk" state
extended with features than to see uefi "inflated" with ZFS support (or any
other futre fs for that matter). Uefi is big and complex enough as it is
already.

Same situation happens with convoluted md raid setups and such.

This is unfortunate bootstrapping problem.

Regarding rising Linux ramdisk complexity, it seems to me like FreeBSD' reroot
way of preserving kernel state, but killing everything and respawning init,
removes the need to concern oneself with pivoting. One could just exec into new
s6-svscan instance from (finally located) actual rootfs at the end of the
ramdisk stage.

That way one can have have supervision running both from ramdisk and during
"cruise" as well. Maybe it's approach worth emulating in Linux ramdisks as well?

I am not very experienced with Linux ramdisks. As user, I personally liked
archlinux's mkinitcpio more than dracut. But I just use what distribution gives
me. All these "frameworks" make heavy assumnptions about how system is supposed
to work.

Maybe we need s6-mkramdisk at some point in the future?

  eto
Received on Wed Jun 22 2016 - 07:06:33 UTC