Bug 1946074 - boot failure when LV is a cryptoluks device used as sysroot
Summary: boot failure when LV is a cryptoluks device used as sysroot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 1945596 1947952 1948063 (view as bug list)
Depends On:
Blocks: F34FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2021-04-04 03:59 UTC by Chris Murphy
Modified: 2021-04-13 01:34 UTC (History)
17 users (show)

Fixed In Version: dracut-053-2.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-04-13 01:34:32 UTC
Type: Bug


Attachments (Terms of Use)
screenshot of failure (423.53 KB, image/png)
2021-04-04 03:59 UTC, Chris Murphy
no flags Details
rdsosreport.txt (203.76 KB, text/plain)
2021-04-04 04:00 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2021-04-04 03:59:50 UTC
Created attachment 1768992 [details]
screenshot of failure

Description of problem:

When an LVM LV used as sysroot is LUKS encrypted (as contrasted to a LUKS partition as LVM PV, making all LV's encrypted as a group - Anaconda supports both layouts), boot fails in initramfs, when it was created with dracut 053.


Version-Release number of selected component (if applicable):
dracut-053-1.fc34.x86_64

How reproducible:
Always, in this configuration.


Steps to Reproduce:
1. Custom installation is required to only check encryption on the '/' mountpoint encrypt checkbox, thereby encrypting this LV. Fedora-Workstation-Live-x86_64-34-20210401.n.0.iso is what I used because it has dracut 053 in it, but didn't get the bump to systemd-248; it still has rc4.
2. Complete the installation
3. Reboot

Actual results:

Fails (see screenshot)

Expected results:

Should boot

Additional info:

Just to be extra clear, there are two layouts possible in Anaconda:
A. LVM->LUKS->FS
B. LUKS->LVM->FS

The (A) layout is what this bug affects. We can get here in Custom partitioning by creating an LVM layout as in Figure 20 [https://docs.fedoraproject.org/en-US/fedora/f33/install-guide/install/Installing_Using_Anaconda/#sect-installation-gui-manual-partitioning-lvm] and selecting the '/' mountpoint and checking the 'Encrypt' box to the right of Device Type: LVM popup.

(B) layout is what we used to get with Fedora 32 Automatic + "Encrypt my data" checked; and in Fedora 34 Custom if you check the new "Encrypt my data" box. The partition is cryptoluks, the dmcrypt device is made a PV-VG and all LVs made from that one crypto luks device. That layout still works.

See also bug 1945596 where quite a lot debugging was done including finding the (unexpected) fix which I've tested.
https://github.com/dracutdevs/dracut/commit/ba4bcf5f4f11ad624c647ddf4f566997186135e7

Likely also related but are updates, and not failed clean installs, so I'm not going to flag them as dups: bug 1945901, bug 1945950, bug 1945530.

Comment 1 Chris Murphy 2021-04-04 04:00:24 UTC
Created attachment 1768993 [details]
rdsosreport.txt

Comment 2 Fedora Blocker Bugs Application 2021-04-04 04:02:43 UTC
Proposed as a Blocker for 34-final by Fedora user chrismurphy using the blocker tracking app because:

 Final: The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. 

Basic: All release-blocking images must boot in their supported configurations.

Comment 3 Geoffrey Marr 2021-04-05 23:43:07 UTC
Discussed during the 2021-04-05 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration"

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-04-05/f34-blocker-review.2021-04-05-16.02.txt

Comment 4 Chris Murphy 2021-04-07 05:32:23 UTC
Small detail, I got the wrong basic criterion in comment 2. The ISO image boots OK. 

The problem is the resulting installation doesn't boot. That's in the section Post-install requirements -> Expected installed system boot behavior, which has three bullets all of which require boot to work.  https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior

Comment 5 Adam Williamson 2021-04-07 20:54:55 UTC
*** Bug 1945596 has been marked as a duplicate of this bug. ***

Comment 6 Adam Williamson 2021-04-07 20:56:07 UTC
According to the dupe, https://github.com/dracutdevs/dracut/commit/ba4bcf5f4f11ad624c647ddf4f566997186135e7 resolves this. So marking as POST.

Comment 7 Steeve McCauley 2021-04-07 21:52:43 UTC
The update to /usr/lib/dracut/modules.d/35network-manager/nm-run.service also fixed this for me.

I originally just tried reinstalling the kernel, but it still wouldn't boot.  I had to rebuild initramfs manually,

$ sudo dracut --force --kver 5.11.11-300.fc34.x86_64

after which the fc34 kernel booted.

Comment 8 Fedora Update System 2021-04-09 00:46:33 UTC
FEDORA-2021-50707f8501 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-50707f8501

Comment 9 Fedora Update System 2021-04-09 13:34:24 UTC
FEDORA-2021-50707f8501 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-50707f8501`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-50707f8501

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Justin M. Forbes 2021-04-09 17:01:20 UTC
*** Bug 1947952 has been marked as a duplicate of this bug. ***

Comment 11 Horst H. von Brand 2021-04-09 19:11:38 UTC
Running the cited `dnf upgrade` command says there are no packages to update.

As far as I see, this is a new `dracut`, i.e., a tool to (re)create the `initrd` image. Isn't a further step to update said image required as part of the fix?

Comment 12 Horst H. von Brand 2021-04-09 21:56:03 UTC
Updated `dracut` as directed, rebuilt `initramfs` for the latest Fedora 34 kernel with:

```
dracut --force /boot/initramfs-5.11.12-300.fc34.x86_64.img 5.11.12-300.fc34.x86_64
```

The result now boots fine.

Comment 13 Adam Williamson 2021-04-09 23:04:09 UTC
The message is auto-generated, it's not smart enough to be adjusted for specific foibles like that. (I actually also thought a scriptlet should trigger a rebuild when updating dracut, though it seems not).

Comment 14 Niki Guldbrand 2021-04-11 06:59:41 UTC
*** Bug 1948063 has been marked as a duplicate of this bug. ***

Comment 15 Fedora Update System 2021-04-13 01:34:32 UTC
FEDORA-2021-50707f8501 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.