I have KDE Neon with the disk encrypted, so the first screen I see when I boot the computer (grub apart) is the LUKS input for the password to decrypt the disk.
The thing is that a few weeks ago, after an update aplied by the Discover program, that LUKS screen doesn´t allow me to write any input. In fact. the keyboard does nothing (Ctrl+alt+F2, Ctrl+c, nothing works). I know that the PC is not freezed because de password screen has the KDE logo rotating.
The only way I have found to successfully boot is to launch via KDE advanced options in the grub an older kernel, which takes me to a console-like version of the luks password screen and there the keyboard is able to write the password. The kernel that is not working is the 6.8.0-51-generic, and the one that works is the 6.8.0-49-generic.
As a curiosity, if I start pressing keyboard letters just in the moment that the luks screen loads, some of them are registered in the password input, but then the keyboard stops working. It is a laptop, and i have tried its own keyboard and an external one. The issue is still the same.
I think maybe its a driver problem, maybe the usb? I am running it on a Lenovo Thinkpad E15 gen 2, and everything is up to date.
Unfortunately I don’t know the solution but I have the exact same problem, in my case on a Lenovo ThinkPad X1 Yoga 2nd.
Unlocking works with 6.8.0.49, but neither with 6.8.0.51 nor 6.8.0.52
I had a similar issue with my laptop after a kernel update, where the keyboard wouldn’t respond on the LUKS screen, but everything else seemed fine. In my case, it turned out to be a kernel bug affecting the USB drivers. I tried rolling back to an older kernel and it worked, just like you’re doing with 6.8.0-49. I’d suggest checking for any new updates for the kernel or the USB drivers. If that doesn’t help, maybe try reinstalling them or looking up specific fixes for your ThinkPad model in the changelogs for that kernel version. Sometimes, newer kernels can cause these compatibility issues until they get patched.
Yes, that was the problem! Removing the ‘quiet splash’ option let me boot using the newer kernels, though it makes the boot process uglier. Let’s hope for a fix in future updates.
I have successfully applied a cleaner workaround on my machine now: This comment Comment #7 : Bug #2091753 : Bugs : linux package : Ubuntu on the bug report that @johnandmegh posted above mentioned that adding your GPU’s kernel module to /etc/initramfs-tools/modules would solve the issue. I tried it and it worked, even after the next kernel update, and wit Plymouth still active.
So now I have a working, good-looking boot process with decryption again