event based initramfs

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/17/2012 12:54 PM, Dmitrijs Ledkovs wrote:
> At this point for boot performance, you do want to run udev/init as soon
> as possible. And pass the state of udev/init as soon as possible to real
> rootfs/real init.

Last I heard, the consensus was that the time wasted restarting udev was like 200ms, so no big deal.  In order to avoid having to restart udev, you would have to include all udev rules, and their dependencies in the initramfs, and couldn't remove them after pivoting to the real root.

> Do you have suggestions on how to make booting reliable with rootfs on
> arbitrary nested LUKS/LVM/RAID without doing it event driven, nor
> designing a poor-man's-udev-based init system for initramfs?

Arbitrarily nested lvm/raid already is event driven and works well, except for the case of nested degraded arrays, which can be fixed just by changing the failure hooks to repeatedly execute all hooks until none report they have done some recovery, rather than stopping at the first that does some recovery.  LUKS probably should be converted to event driven, but udev is event driven and already in the initramfs, so why not use that rather than upstart?

> * Running multipath daemon & mounting iSCSI rootfs drives

That, I am not really familiar with.  I would think iSCSI wouldn't be much different than NFS root though.

> * Bring up networking & mount nfsroot and not drop network during
> initrmafs->real system transition

Can't upstart see from the kernel command line that it's a network boot and skip reinitializing the network, without needing statefull rexec?

> * Booting of a RAID array brought over from another system

This should work if mdadm.conf is reconfigured to finally stop requiring arrays to be explicitly listed.

> In the event of an error:
> * you can attempt automatic recovery with fsck / similar tools

That means yet more stuff that is only rarely needed crammed into the initramfs.  I think it would be better to set up a dedicated recovery partition and configure grub to automatically fail over into it.

> * drop into busybox
> * Interesting suggestion: have emacs & w3m to give a fully-functional
> minimal operating system for the user to get onto irc / help forums /
> wiki pages, or even boot into something like chromium-os

This definitely belongs in a recovery partition, not the initramfs.

>> So you also want to put all of the fscks and their dependencies in the
>> initramfs?  Or it would only do this for non root filesystems?  Why
>> would we want to do this in the initramfs instead of when the real init
>> runs?
>>
> 
> Speed.
> 
> We can start & continue fsck on e.g. unencrypted partitions, while the
> user is slowly trying to unlock some other LUKS partition with a 64
> character password. And magically, handover / continue fsck.

So if you use LUKS on your root, and not on /home, then the fsck of /home could be started while waiting for the root LUKS password?  Why would you encrypt the root but not /home?  This seems like a microoptimization for an odd setup.

> ...and actually reliably bringing up luks promts, when needed, and not
> timeout & drop into busybox while typing the password in... </rant> ;-)

That doesn't require upstart.  In fact, I don't see how you would do this with upstart.  Instead, wait-for-root could grow a flag to stop the timeout while waiting for user input.  If you do have plymouth in the initramfs, it could invoke that automatically when it is prompting for input.  The udev rules for raid/lvm/luks could run plymouth to prompt for input.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPuvTxAAoJEJrBOlT6nu75NcsIAJ4N8wt6xYcp0YbeHnegBOF1
V9B5tYzOV6D76AqXV+x16FrRqxRT+iDBNCAwZ8yh/YDV/nGS05B/UJ0nFThc0ifa
wJ025y1w1HGIp271y40UwdfRpiP3VJIcF3Z6VNU3knu9DGdfPEUGy6rk3mEANv+k
EmIO/nrRvWxctHG+VmD/FEhqKAbBWriiynYQ8VTdzRZOJ/GbCRnq7uKkanR4oxdO
4MKl/0I3c9jWlwHHyoNb/4BCb4TNGSLEnOk6kchTc7Vku42Yy75Cxol9szEQNEML
9Sy32HqCHCbZgpFHrcjgV6A5vKJYupWVszQRtUYAtJry6siNI9hKxizaAhzbGyY=
=TuLz
-----END PGP SIGNATURE-----