Created attachment 1770877 [details]
kernel logs

1. Please describe the problem:
After upgrading to Fedora 34 I'm unable to boot my system using an f34 kernel, I can however boot it with a f33 kernel that is still installed even though the version is the very same (5.11.11-200).

Once I select a Fedora 34 kernel the system boots but when it comes to unlocking my encrypted partitions it hangs stating that it's waiting for the availability of my partitions. It's the same thing that happens if you enter the wrong password too many times or list a non-existing devices in fstab. After waiting for the timeout I'm able to drop to a shell and from there I've checked that the partitions for /boot, /boot/efi, / and swap are all visible trough /dev/disk/by-uuid and all the LVM partitions are inactive (according to lvm_scan).

See the attached system_boot.txt there's a line which looks related to the issue:
Apr 10 10:36:41 systemd-tty-ask-password-agent[721]: Invalid password file /run/systemd/ask-password/ask.HjS9QF
Apr 10 10:36:41 systemd-tty-ask-password-agent[721]: Failed to process password: Bad message

2. What is the Version-Release number of the kernel:
both 5.11.11-200.f34 and 5.11.12-200.f34

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
As I said I can still boot fine with 5.11.11-200.f33

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
Always. I just need to boot my system with an f34 kernel.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
No yet checked.

6. Are you running any modules that not shipped with directly Fedora's kernel?:
No

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.