Ask Your Question

After a kernel update cannot decrypt the lux partition due to the change of keyboard layout

asked 2016-01-15 04:50:38 -0500

mkungla gravatar image

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

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

edit retag flag offensive close merge delete


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 gravatar imageflorian ( 2016-01-15 10:29:05 -0500 )edit

@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 :).

probably know where the keys are located

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.

Changing the keyboard layout should not affect the keyboard layout in an early stage like LUKS password dialog

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

mkungla gravatar imagemkungla ( 2016-01-15 11:05:47 -0500 )edit

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

kernel-install add <kernel-version>

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.

thomaswood gravatar imagethomaswood ( 2016-01-16 05:29:34 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2016-01-16 09:41:02 -0500

mkungla gravatar image

updated 2016-01-16 10:18:26 -0500

When you can not decrypt your LUKS partition after kernel update and you have possibility that this is because you use multiple keyboard layouts then here are following two of the solutions.

  • 1th Try to enter your passphrase by using key's matching your input sources used. You just might be lucky to use correct keymap and you can decrypt you partition. And you have to remember that for now-on that this is the input source layout you have to use while entering your LUKS pass phrase.

So if you installed Fedora and created your LUKS partition with en_US layout and
now updated your kernel while using for instance nl_NL input source then from now on you
you have to use nl_NL layout for your LUKS pass phrase.
That repeats it's self over and over again every time when you upgrade the kernel, so if next time upgrading
the Kernel and you happend to have en_US active then LUKS passphrase will map to this.

  • 2nd option is to remove last updated kernel

1. Boot up to previous kernel which worked before update and just verify current kernel used.

[root@local ]# uname -a

2. Find last downloaded kernel.

root@local ]# rpm -qa | grep kernel

3. From the list find kernel packages choose one which cause you a trouble and run following by replacing package names with ones you want to remove.

[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

4. Set your keyboard language to one which is your primary or you used when creating the LUKS passphrase for your disk,

5. and update the kernel.

[root@local ]# dnf upgrade

and you are good to go and boot with updated kernel and use your passphrase mapping to input source you want.


While installing Fedora and checking option

Encrypt my data. You'll set a passphrase next

Then in DISK ENCRYPTION PASSPHRASE dialog you'll get following warning.

Warning: You won't be able to switch between keyboard layouts (from the default one) when you decrypt your disk after install.

So that is not entirely true, since you can change it when you change you input source before kernel update. So after kernel update keyboard layout set before is used instead of your (default one).

edit flag offensive delete link more

Question Tools



Asked: 2016-01-15 04:50:38 -0500

Seen: 1,593 times

Last updated: Jan 16 '16