Comment 15 for bug 251164

copying this conclusion from #531240 as it rather belongs here

----
As far as I can see cryptsetup in initramfs is not called on the event that a crypt device appears. It seems cryptsetup in initramfs is currently rather linear script driven: the cryptsetup script has its own while loop waiting for $cryptsource after all other "local top" scripts. "Failure hooks" have been introduced in initramfs and mdadm, but I don't see one for cryptsetup. And I have doubts that such a two step design can cope with the general case of devices depending on others.)

The simple case: rootfs on lvm on crypt on raid:

0) The md0 raid (sda,sdb) got degraded during power down,
1 udev/mdadm does not start the array,
2) crypt on raid does not come up for 2,5 minutes until ROOTDELAY timeout and init-top fails (putting aside this bug, that cryptsetup is wrongly opening a member device)
3) mdadm failure hook runs the array degraded
4) boot currently fails never the less #531240 (but could be made to work with a cryptsetup failure-hook for this case)

If however the rootfs is actually located on md1 assembled of md0 (the internal disks) an sdc, with the failure hook design there is no further timeout given or failurehook available after md0 is started degraded to bring the rootfs up if the (external backup disk) sdc is not connected.

(This is not far fetched because only stacking raids this way allows to take advantage of write intent bitmaps for a (backup) disk that are not connected all the time. (sdc in this case))

So to handle the genreal case with unforeseen combinations, I think in initramfs:

- cryptsetup udev rules should be supplied into initrams as well (new_crypt_device event, restriced to the rootfs dependency devices)
- The initramfs should have just one ROOTDELAY waiting loop in its script (or faster loading upstart/mountall binary?) started upon initramfs_start, that is paused however while cryptsetup it is prompting for a passphrase (prompt_start/stop events).
- Package mdadm needs to supply a MIN_COMPLETION_WAIT value and the dependency tree of arrays for the root device on mkinitramfs.
- During boot when time_elapsed == MIN_COMPLETION_WAIT (raid_start_degrated event)
   -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.