1. Please describe the problem: Keyboard is not working at LUKS password prompt during boot with kernel 5.19.7. I can see the prompt, but unable to type the password. Keyboard works fine in the GRUB menu. May be worth noting: $ localectl status | grep VC VC Keymap: ruwin_cplk-UTF-8 2. What is the Version-Release number of the kernel: Name : kernel Version : 5.19.7 Release : 200.fc36 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 : This problem didn't occur with any previous kernel versions since Fedora 36 installation. The first problematic version is 5.19.7. Creating this issue with 5.19.6, which works fine. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: 1. Encrypt root partition with LUKS during Fedora installation. 2. Install and boot the kernel 5.19.7. 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``: Didn't test. 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. Since I cannot boot, I cannot attach any logs. If I disable `quiet` boot option in the GRUB menu, I can see logs for a split second, but then LUKS password prompt fills the screen.
After updating to kernel 5.19.8 the behavior is even worse: an attempt to boot with 5.19.8 kernel results in a black screen, i.e. LUKS password prompt is not shown anymore. If I remove the `quiet` boot options from the 5.19.8 kernel command line via the GRUB menu, then the behavior is similar to the 5.19.7, i.e. LUKS password prompt is shown, but I am unable to enter password. I've increased the priority to high, as the last working kernel 5.19.6 is only one kernel update away from being autoremoved from the system.
> After updating to kernel 5.19.8 the behavior is even worse: an attempt to boot with 5.19.8 kernel results in a black screen, i.e. LUKS password prompt is not shown anymore. If I remove the `quiet` boot options from the 5.19.8 kernel command line via the GRUB menu, then the behavior is similar to the 5.19.7, i.e. LUKS password prompt is shown, but I am unable to enter password. Are you perhaps using an amdgpu ? There have been several reports of problems with the amdgpu after the latest update to linux-firmware. Booting older kernels still works because the old firmware is in the initrd, which gets generated once at kernel install time. Try downgrading linux-firmware and then regenerating the initrd for the troublesome kernels using the dracut tool. > as the last working kernel 5.19.6 is only one kernel update away from being autoremoved from the system. dnf will never remove the currently running kernel, so that should not happen, assuming that you are booting 5.19.6 to avoid the problem.
(In reply to Hans de Goede from comment #2) > > After updating to kernel 5.19.8 the behavior is even worse: an attempt to boot with 5.19.8 kernel results in a black screen, i.e. LUKS password prompt is not shown anymore. > If I remove the `quiet` boot options from the 5.19.8 kernel command line via > the GRUB menu, then the behavior is similar to the 5.19.7, i.e. LUKS > password prompt is shown, but I am unable to enter password. > > Are you perhaps using an amdgpu ? There have been several reports of > problems with the amdgpu after the latest update to linux-firmware. Booting > older kernels still works because the old firmware is in the initrd, which > gets generated once at kernel install time. Yes, I have Lenovo Thinkpad E14 with AMD Ryzen 5700U with integrated AMD GPU. > Try downgrading linux-firmware and then regenerating the initrd for the > troublesome kernels using the dracut tool. After downgrading to linux-firmware-20220708-136.fc36.noarch.rpm and rebuilding initrd with `dracut --force --kver 5.19.8-200.fc36.x86_64` I can successfully enter LUKS password and the system proceeds to boot as normal with kernel 5.19.8. Thank you very much. > > as the last working kernel 5.19.6 is only one kernel update away from being autoremoved from the system. > > dnf will never remove the currently running kernel, so that should not > happen, assuming that you are booting 5.19.6 to avoid the problem. Thanks, I didn't know that. This is a nice feature.
I can also confirm that after installing the latest linux-firmware, manually installing amd-gpu-firmware as suggested in https://bugzilla.redhat.com/show_bug.cgi?id=2125536#c11 and rebuilding initrd, I can successfully boot into 5.19.8 kernel. I've also found this note https://bodhi.fedoraproject.org/updates/FEDORA-2022-9e00b7b7c8#comment-2705613 and indeed I have `install_weak_deps=False` in my dnf.conf. I feel that at least a warning would be good to have to prevent this breakage for people with disabled weak deps. So, should I close this bug as fixed now?
(In reply to Coacher from comment #4) > I can also confirm that after installing the latest linux-firmware, manually > installing amd-gpu-firmware as suggested in > https://bugzilla.redhat.com/show_bug.cgi?id=2125536#c11 and rebuilding > initrd, I can successfully boot into 5.19.8 kernel. > > I've also found this note > https://bodhi.fedoraproject.org/updates/FEDORA-2022-9e00b7b7c8#comment- > 2705613 and indeed I have `install_weak_deps=False` in my dnf.conf. I feel > that at least a warning would be good to have to prevent this breakage for > people with disabled weak deps. > > So, should I close this bug as fixed now? The split of the linux-firmware package was suppsed to only be a F37 thing AFAIK, since this has been breaking things for users left and right I think we should keep tracking this. I will mark this as a duplicate of 2125536. *** This bug has been marked as a duplicate of bug 2125536 ***