Comment 6 for bug 251164

Ah, packages server is back up.

I see the whole rootdelay loop has been copied from the local script and also the dropping to the console when ${cryptsource} is missing.

But the recent local script will execute additional failure hooks. For example degraded arrays will only get started by these.

When cryptroot drops to a console is like it does now it will basically prevent the local script from running any failure hooks. A system with a degraded array that contains the cryptroot for example won't come up. The array will only be run degraded after the rootdelay in local has timed out.
(Relevant is Bug 120375 and the updated mdadm packages from
https://launchpad.net/~kirkland/+archive)

It should be save to just remove the loop that drops to the console in init-top/cryptroot and exit to local instead. That would mean another rootdelay loop will have timeout for sure, though, until failure hooks might eventually help out. (And if for example the array can be started degraded, init-top/cryptsetup will still need to provide a failurehook, or won't be run again to open the rootdevice).

But here is a suggestion for further improvement:

Have the local script call cryptroot (or better an "eventhook", registerd on the first run just like the failure hooks) from within the rootdelay loop in the local script.

The eventhook of local-top/cryptroot should be called (once) if ${cryptsource} comes available.

The eventhook would only be needed for things like cryptsetup that may not be set up by udev rules in an coldplug driven boot process.
Instead, they would set a trigger within the single rootdelay loop in local.

(Or would it be possible to generate special udev rules during initramfs generation that can recognize non-luks partitions, and have a fully coldpluggable system?)