After a kernel update cannot decrypt the lux partition due to the change of keyboard layout
I'm using Fedora 23, LUKS encrypted disk and multiple keyboard input sources for all the languages I'm daily using and switching between. When there is kernel update available and I forget to switch to enUS as primary keyboard layout then I can not decrypt LUKS partition since wrong keyboard layout is set when I update kernel.
So I solved this issue by booting up to previous kernel which worked before update and just verify current kernel used.
[root@local ]# uname -a
Linux local.localhost 4.2.3-300.fc23.x86_64 #1 SMP Mon Oct 5 15:42:54 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
then found last updated/downloaded kernel...
[root@local ]# rpm -qa | grep kernel
kernel-4.2.5-300.fc23.x86_64
kernel-core-4.2.5-300.fc23.x86_64
kernel-modules-4.2.5-300.fc23.x86_64
kernel-4.2.3-300.fc23.x86_64
kernel-core-4.2.3-300.fc23.x86_64
kernel-modules-4.2.3-300.fc23.x86_64
kernel-4.2.0-300.fc23.x86_64
kernel-core-4.2.0-300.fc23.x86_64
kernel-modules-4.2.0-300.fc23.x86_64
libreport-plugin-kerneloops-2.6.3-1.fc23.x86_64
abrt-addon-kerneloops-2.7.0-1.fc23.x86_64
so from the list took obviously highest version nr, one which was causing problem and removed the listed kernel packages.
[root@local ]# dnf remove kernel-4.2.5-300.fc23.x86_64 kernel-modules-4.2.5-300.fc23.x86_64 kernel-core-4.2.5-300.fc23.x86_64
then made sure that my primary language enUS is selected and updated kernel again
[root@local ]# dnf upgrade
After the kernel update is done I can decrypt my LUKS partition and everything is fine but my question is. Can this issue if occurs be solved some other way (faster) or is there way to prevent that happening even when I use many keyboard layouts? And which input source, kernel update uses. One which is currently active or one which is set as primary (first in the list) PS: I'm using gnome
That sounds like a bug to me. Changing the keyboard layout should not affect the keyboard layout in an early stage like LUKS password dialog.
And you can't enter your password knowing that one of your other layouts is active (non EN)? Using different layouts in Gnome you probably know where the keys are located... or are you using something fancy like urdu, kyrillic, or hebrew?
@Florian Well I use in my pass lot of special characters so these are the ones messing it up and my pass lengths are avg 15+ char :).
Indeed I can just enter my pass as test driven so if it does not accept it, then try key combination of other language if not then another.
It only occurs when you change you input source before kernel update. I believe key change was also warned in Fedora installation progress while setting up LUKS
Sounds like it is related to the initial ramdisk. Normally the `/etc/vconsole.conf' should be used for creating the keymaps within the initramfs.
Avoiding a complete reinstall of the kernel, you could try to set your preferred keyboard layout and then run
to create a new ramdisk which should include the correct keymap then.
I have seen that there is also a kernel append option
rd.vconsole.keymap
which could occur in the/etc/grub2.cfg
. You should check that as well, if the problem is related to that.