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?)
--
crypdisk setup does not wait properly for its source devices to appear
https://bugs.launchpad.net/bugs/251164
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
