This page collects detailed discussion and possible solutions to the problem described here.



Jonas has recently started a discussion on this at debian-devel, IIRC. event-based init-systems were mentioned there, but I'm not sure whether they really would help us here, but perhaps I just misunderstand something.''


 * Right, it's best if it is "not (necessary) to tell" (hardcode/configure) any layering, but having the layers hotpluged as they come up. It should suffice for cryptsetup/mdadm (and others that may have to do (user) interventions) in the initirams to watch udev/upstart events and look for required UUIDs (similar to what ubuntu's "mountall" already does in the init-system). For stacked raid devices the initramfs would need to be kept up to date (possibly during install/shutdown) with any tree of dependencies of raid devices necessary to mount for the rootfs. (See "How would you decide what devices are needed?" for more detail.)

   To handle the general case of unforeseen combinations: (ubuntu is almost there, adopted from

   * cryptsetup udev rules should be supplied into initrams as well (triggering cryptsetup on new_crypt_device event, though auto-opening is restriced to the rootfs dependency devices)
   * (ubuntu's initramfs scripts should have just one ROOTDELAY waiting loop in its script (or implement the faster upstart/mountall binaries in initramfs, and that timeout should be paused i.e. while cryptsetup is prompting for a passphrase (prompt_start/stop events).
   * Package mdadm needs to have a MIN_COMPLETION_WAIT setting and keep the dependency tree of required arrays for the root device on mkinitramfs up to date. (
    * During boot when time_elapsed == MIN_COMPLETION_WAIT a raid_start_degrated event should be triggered:
     * If a next level in the dependency tree exists and the remaining root delay timer is lower then MIN_COMPLETION_WAIT the rootdelay_timer is increased by MIN_COMPLETION_WAIT.
     * The degraded arrays of the current dependency level are started degraded.


Christian, I rather doubt that an event-based init-system will solve any of the problems.
I mean what could it do? For example it could have an event like "need the root-filesystem",.. but this does still not give the order in which we have to call the separate tools (lvm,cryptsetup,mdadm) nor if we have to call them multiple times (e.g. there could be setups like ...-->lvm-->dm-crypt-->lvm).
And I guess it's a bad idea to simply try to set up anything that we detect. This would be bad for initramfs images, which should be small in size, and only lood the really necessary filesystems.
Also, not everything may provide UUIDs, some block layers might require "extensive" configuration or user-interaction (e.g. crpytsetup).
Further, I guess that events wouldn't help you with stuff like nbd/losetup devices, etc.
Also, it seems that it would force users to use udev.

Nevertheless, let's discuss this further, in the meanwhile I'm also planning a rather mighty (I guess) solution for all this,... as soon as I'm finished, I'll present it here.