This bug was fixed in the package initramfs-tools - 0.136ubuntu6.3
---------------
initramfs-tools (0.136ubuntu6.3) focal; urgency=medium
* scripts/functions: Prevent printf error carry over if the wrong
console is set. (LP: #1879987)
The function _log_msg() is "void" typed, returning whatever its
last command returns. This function is the basic building block
for all error/warning messages in initramfs-tools. If a bad console
is provided to kernel on command-line, printf returns error, and so
this error is carried over in _log_msg(). Happens that checkfs()
function has a loop that runs forever in this scenario (*if* fsck
is not present in initramfs and "quiet" is not passed in the
command-line). If that happens, boot is stuck and cannot progress.
The simple fix hereby merged is to return zero on _log_msg().
* scripts/local: Re-execute cryptroot local-block script. (LP: #1879980)
Currently, if an encrypted rootfs is configured on top of a MD RAID1
array and such array gets degraded (like a member is removed/failed),
initramfs-tools cannot mount the rootfs and the boot fails. We fix
that issue here by allowing cryptroot script to re-run on local-block
stage, given that mdadm is able to activate a degraded array in that
point. There is a cryptsetup counter-part for this fix, but alone the
initramfs-tools portion is innocuous.
* d/tests: Add explicit call to partprobe on net test, specially in
prep-image and run-image. (LP: #1893675)
-- gpicc...@canonical.com (Guilherme G. Piccoli) Mon, 31 Aug 2020
13:43:29 -0300
** Changed in: initramfs-tools (Ubuntu Focal)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1879980
Title:
Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
Status in cryptsetup package in Ubuntu:
In Progress
Status in initramfs-tools package in Ubuntu:
Fix Released
Status in mdadm package in Ubuntu:
Opinion
Status in cryptsetup source package in Xenial:
Won't Fix
Status in initramfs-tools source package in Xenial:
Won't Fix
Status in mdadm source package in Xenial:
Won't Fix
Status in cryptsetup source package in Bionic:
In Progress
Status in initramfs-tools source package in Bionic:
In Progress
Status in mdadm source package in Bionic:
Opinion
Status in cryptsetup source package in Focal:
In Progress
Status in initramfs-tools source package in Focal:
Fix Released
Status in mdadm source package in Focal:
Opinion
Status in cryptsetup source package in Groovy:
In Progress
Status in initramfs-tools source package in Groovy:
Fix Released
Status in mdadm source package in Groovy:
Opinion
Status in cryptsetup package in Debian:
New
Bug description:
[Impact]
* Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu
is currently unable to decrypt the rootfs if the array gets degraded, like for
example if one of the array's members gets removed.
* The problem has 2 main aspects: first, cryptsetup initramfs script
attempts to decrypt the array only in the local-top boot stage, and in
case it fails, it gives-up and show user a shell (boot is aborted).
* Second, mdadm initramfs script that assembles degraded arrays
executes later on boot, in the local-block stage. So, in a stacked
setup of encrypted root on top of RAID, if the RAID is degraded,
cryptsetup fails early in the boot, preventing mdadm to assemble the
degraded array.
* The hereby proposed solution has 2 components: first, cryptsetup
script is modified to allow a gentle failure on local-top stage, then
it retries for a while (according to a heuristic based on ROOTDELAY
with minimum of 30 executions) in a later stage (local-block). This
gives time to other initramfs scripts to run, like mdadm in local-
block stage. And this is meant to work this way according to
initramfs-tools documentation (although Ubuntu changed it a bit with
wait-for-root, hence we stopped looping on local-block, see next
bullet).
* Second, initramfs-tools was adjusted - currently, it runs for a
while the mdadm local-block script, in order to assemble the arrays in
a non-degraded mode. We extended this approach to also execute
cryptsetup, in a way that after mdadm ends its execution, we execute
at least once more time cryptsetup. In an ideal world we should loop
on local-block as Debian's initramfs (in a way to remove hardcoded
mdadm/cryptsetup mentions from initramfs-tools code), but this would
be really a big change, non-SRUable probably. I plan to work that for
future Ubuntu releases.
[Test case]
* Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to
create a RAID1 volume and an encrypted root on top of it.
* Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
from one of the RAID members. Reboot and it will fail to mount rootfs
and continue boot process.
* If using the initramfs-toos/cryptsetup patches hereby proposed, the
rootfs can be mounted normally.
[Regression potential]
* There are potential for regressions, since this is a change in 2
boot components. The patches were designed in a way to keep the
regular case working, it changes the failure case which is not
currently working anyway.
* A modification in the behavior of cryptsetup was introduced: right
now, if we fail the password 3 times (the default maximum attempts),
the script doesn't "panic" and drop to a shell immediately; instead it
runs once more (or twice, if mdadm is installed) before failing. This
is a minor change given the benefit of the being able to mount rootfs
in a degraded RAID1 scenario.
* Other potential regressions could show-up as boot problems, but the
change in initramfs-tools specifically is not invasive, it just may
delay boot time a bit, given we now run cryptsetup multiple times on
local-block, with 1 sec delays between executions.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
