Hi Ubuntu Security Team, I've subscribed you to this bug for a patch review asked by the SRU team. Please find a request summary below, and feel free to ask for details.
There's a change being proposed to the cryptsetup boot logic (debdiff in comment #44) so to allow an encrypted device on top of MD RAID1 devices to have a chance to be detected and boot at all if the raid array is degraded (e.g., lost disk.) Currently, the system cannot boot in that scenario (a degraded array is not yet activated when cryptsetup runs, so the encrypted device with rootfs does not yet exist.) The proposed patch introduces a retry logic that runs after mdadm runs (as mdadm can activate the degraded array anyway) and then re-check for the encrypted device (as it now exists.) However, that introduces some behavior changes like the time that is waited for the encrypted device before giving up and trying mdadm, and the number of times asking for passphrase. A summary of those changes is in comment #51 and description, and the request from the SRU team in comment #48 with detail suggestions in #49. Thank you, Mauricio -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
