event based initramfs

[Phillip Susi]

On 5/16/2012 9:01 AM, James Hunt wrote:
> The most obvious reason is that the initramfs has it's own init
> system (a big shell script). So, an Ubuntu system with an initramfs
> has two different init systems. By reducing this down to just
> Upstart, we get a simpler and hence more readily maintainable system
> that:

It has its own system because it isn't really an init system at all.
The goal of upstart is to bring up and maintain the system.  The goal of
the initramfs is only to find the root filesystem.

> - has the advantage of being event-based (but which of course can
> also run jobs effectively "serially" too if desired).

> LUKS support in the initramfs is currently handled using calls to
> "sleep 0.1". Who chose this value? How did they decide upon this
> value? Why 0.1 seconds? Why not just wait until the device appears?
> By having an event-based system, we can adopt a saner approach where
> the system simply reacts to the udev event when the kernel generates
> it - no polling required.

Isn't this what udev is for?  Event based handling of hardware.  What do 
we need upstart for?

> My non-LVM, non-RAID systems initramfs contains 16 calls to
> mount. By using mountall you end up with a single mountall.conf job
> that handles all that complexity.

I only see one call to mount.  There is only one filesystem to mount, so 
where does 16 come from?  mountall is somewhat complex because it needs 
to mount multiple filesystems, in the correct order.  The initramfs just 
needs one.

> A number of upstream projects are starting to move functionality from
> / to /usr (see [3]), hence we intend to support this model too.

If getting to mountall depends on a file in /usr, then that is an FHS 
violation and fundamentally incompatible with having /usr on its own 
filesystem.  Having the initramfs have its own copy of mountall and its 
dependencies in order to mount /usr before the real mountall runs is a 
kludgy workaround.  If you want to boot without an initramfs at all, 
this workaround won't help ( since the kernel only knows how to mount 
the root and it is expected to contain everything needed to mount /usr 
or other filesystems ), so the proper thing to do is make sure that 
dependencies of mountall go in /.

What does it matter where upstream installs to anyhow?  They normally go 
to /usr/local and we move them to /usr with a configure switch.  Moving 
to / instead should be trivial.

> - By utilizing Upstart, we get a clean, fast framework for mounting
> the root FS. We should also be able to simplify the initramfs by
> removing duplicate code. - the initramfs spawns daemons (such as
> udevd) which can be better managed via upstart. -  the current
> initramfs kills the daemons it starts requiring them to be restarted
> in the main system. This has caused a few race conditions and clearly
> disallows state passing between the two systems. By enhancing Upstart
> to support stateful re-exec [4] we get huge benefits as we can retain
> state on processes started in the initramfs and hence don't
> necessarily need to restart them. I don't know of any other system
> that is capable of this. - there is potential for extra "smarts" that
> cannot be achieved easily/cleanly with the current shell approach.

udev still will need restarted to transition to the real root so it 
gains access to the full set of udev rules and the initramfs can be freed.

What sort of "smarts" do you have in mind?