[Group.of.nepali.translators] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
** Changed in: cryptsetup (Debian) Status: New => 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: Fix Released 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: Fix Released Status in initramfs-tools source package in Bionic: Fix Released Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: Fix Released 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: Fix Released Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: Fix Released 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
[Group.of.nepali.translators] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
This bug was fixed in the package cryptsetup - 2:2.2.2-3ubuntu2.3 --- cryptsetup (2:2.2.2-3ubuntu2.3) focal; urgency=medium * Introduce retry logic for external invocations after mdadm (LP: #1879980) - Currently, if an encrypted rootfs is configured on top of a MD RAID1 array and such array gets degraded (e.g., a member is removed/failed) the cryptsetup scripts cannot mount the rootfs, and the boot fails. We fix that issue here by allowing the cryptroot script to be re-run by initramfs-tools/local-block stage, as mdadm can activate degraded arrays at that stage. There is an initramfs-tools counter-part for this fix, but alone the cryptsetup portion is harmless. - d/cryptsetup-initramfs.install: ship the new local-bottom script. - d/functions: declare variables for local-top|block|bottom scripts (flag that local-block is running and external invocation counter.) - d/i/s/local-block/cryptroot: set flag that local-block is running. - d/i/s/local-bottom/cryptroot: clean up the flag and counter files. - d/i/s/local-top/cryptroot: change the logic from just waiting 180 seconds to waiting 5 seconds first, then allowing initramfs-tools to run mdadm (to activate degraded arrays) and call back at least 30 times/seconds more. -- gpicc...@canonical.com (Guilherme G. Piccoli) Wed, 16 Sep 2020 17:40:05 -0300 ** Changed in: cryptsetup (Ubuntu Focal) Status: Fix Committed => Fix Released ** Changed in: cryptsetup (Ubuntu Bionic) 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: Fix Released 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: Fix Released Status in initramfs-tools source package in Bionic: Fix Released Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: Fix Released 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: Fix Released 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 mo
[Group.of.nepali.translators] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
This bug was fixed in the package initramfs-tools - 0.130ubuntu3.11 --- initramfs-tools (0.130ubuntu3.11) bionic; urgency=medium [ Guilherme G. Piccoli ] * 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. [ Jay Vosburgh ] * scripts/functions: Change netplan render for net_failover master devices. (LP: #1820929) Modify the _render_netplan function to check for network interfaces that are net_failover master devices. When found, such devices are matched only by name, not by MAC address, as the MAC is not a unique identifier for the net_failover case. In the net_failover architecture, the MAC address is used to manage the membership of the net_failover interface set, thus multiple interfaces will be assigned the same MAC address. -- gpicc...@canonical.com (Guilherme G. Piccoli) Wed, 12 Aug 2020 17:12:11 -0300 ** Changed in: initramfs-tools (Ubuntu Bionic) 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: Fix Released 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: Fix Released 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: Fix Released 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
[Group.of.nepali.translators] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
This bug was fixed in the package cryptsetup - 2:2.3.3-1ubuntu6 --- cryptsetup (2:2.3.3-1ubuntu6) groovy; urgency=medium * Introduce retry logic for external invocations after mdadm (LP: #1879980) - Currently, if an encrypted rootfs is configured on top of a MD RAID1 array and such array gets degraded (e.g., a member is removed/failed) the cryptsetup scripts cannot mount the rootfs, and the boot fails. We fix that issue here by allowing the cryptroot script to be re-run by initramfs-tools/local-block stage, as mdadm can activate degraded arrays at that stage. There is an initramfs-tools counter-part for this fix, but alone the cryptsetup portion is harmless. - d/cryptsetup-initramfs.install: ship the new local-bottom script. - d/functions: declare variables for local-top|block|bottom scripts (flag that local-block is running and external invocation counter.) - d/i/s/local-block/cryptroot: set flag that local-block is running. - d/i/s/local-bottom/cryptroot: clean up the flag and counter files. - d/i/s/local-top/cryptroot: change the logic from just waiting 180 seconds to waiting 5 seconds first, then allowing initramfs-tools to run mdadm (to activate degraded arrays) and call back at least 30 times/seconds more. -- gpicc...@canonical.com (Guilherme G. Piccoli) Wed, 16 Sep 2020 17:35:59 -0300 ** Changed in: cryptsetup (Ubuntu Groovy) Status: In Progress => 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: Fix Released 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: Fix Released 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 her
[Group.of.nepali.translators] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
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 o
[Group.of.nepali.translators] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
This bug was fixed in the package initramfs-tools - 0.137ubuntu12 --- initramfs-tools (0.137ubuntu12) groovy; urgency=medium * d/tests: Add explicit call to partprobe on net test, specially in prep-image and run-image. (LP: #1893675) initramfs-tools (0.137ubuntu11) groovy; 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. -- gpicc...@canonical.com (Guilherme G. Piccoli) Mon, 31 Aug 2020 18:04:00 -0300 ** Changed in: initramfs-tools (Ubuntu Groovy) Status: In Progress => 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: In Progress 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
[Group.of.nepali.translators] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
** Changed in: mdadm (Ubuntu) Status: Confirmed => Opinion ** Changed in: initramfs-tools (Ubuntu) Status: Confirmed => In Progress ** Also affects: mdadm (Ubuntu Groovy) Importance: Medium Assignee: Guilherme G. Piccoli (gpiccoli) Status: Opinion ** Also affects: cryptsetup (Ubuntu Groovy) Importance: Medium Assignee: Guilherme G. Piccoli (gpiccoli) Status: In Progress ** Also affects: initramfs-tools (Ubuntu Groovy) Importance: Medium Assignee: Guilherme G. Piccoli (gpiccoli) Status: In Progress ** Also affects: mdadm (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: cryptsetup (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: mdadm (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: cryptsetup (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: mdadm (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: cryptsetup (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: mdadm (Ubuntu Xenial) Status: New => Opinion ** Changed in: mdadm (Ubuntu Bionic) Status: New => Opinion ** Changed in: cryptsetup (Ubuntu Xenial) Status: New => Opinion ** Changed in: cryptsetup (Ubuntu Bionic) Status: New => In Progress ** Changed in: cryptsetup (Ubuntu Bionic) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: cryptsetup (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: cryptsetup (Ubuntu Xenial) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: cryptsetup (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: cryptsetup (Ubuntu Xenial) Status: Opinion => Won't Fix ** Changed in: cryptsetup (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: cryptsetup (Ubuntu Focal) Status: New => In Progress ** Changed in: cryptsetup (Ubuntu Focal) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: initramfs-tools (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: initramfs-tools (Ubuntu Xenial) Status: New => Won't Fix ** Changed in: initramfs-tools (Ubuntu Xenial) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: initramfs-tools (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: initramfs-tools (Ubuntu Bionic) Status: New => In Progress ** Changed in: initramfs-tools (Ubuntu Bionic) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: initramfs-tools (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: initramfs-tools (Ubuntu Focal) Status: New => In Progress ** Changed in: initramfs-tools (Ubuntu Focal) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: mdadm (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: mdadm (Ubuntu Xenial) Status: Opinion => Won't Fix ** Changed in: mdadm (Ubuntu Xenial) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: mdadm (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: mdadm (Ubuntu Bionic) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: mdadm (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: mdadm (Ubuntu Focal) Status: New => Opinion ** Changed in: mdadm (Ubuntu Focal) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) -- 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: In Progress 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: In Progress 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: In Progress Status in mdadm source package in Groovy: Opini
