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):
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
Fails (see screenshot)
Just to be extra clear, there are two layouts possible in Anaconda:
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.
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.
Created attachment 1768993 [details]
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.
Discussed during the 2021-04-05 blocker review meeting: 
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"
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
*** Bug 1945596 has been marked as a duplicate of this bug. ***
According to the dupe, https://github.com/dracutdevs/dracut/commit/ba4bcf5f4f11ad624c647ddf4f566997186135e7 resolves this. So marking as POST.
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.
FEDORA-2021-50707f8501 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-50707f8501
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.
*** Bug 1947952 has been marked as a duplicate of this bug. ***
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?
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.
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).
*** Bug 1948063 has been marked as a duplicate of this bug. ***
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.