LUKS password fails with different locale

[MaxXor]

When performing the installation with a different locale than English, the LUKS password doesn't work. I assume once the installation finished and you boot the system it's again using the English locale to decrypt the LUKS partition?

[ulisesvina]

It in fact uses the en_US locale.

[Torxed]

Which version of the ISO were you using? Because since a while back we've modified the HOOKS to contain keymap before encrypt, which should make it so that your locale/keymap should kick in before the disk encryption password.

This is what the mkinitcpio hook looks like if you're running encrypted setups: ["base", "udev", "autodetect", "keyboard", "keymap", "modconf", "block", "encrypt", "filesystems", "fsck"]

This assumes that /etc/vconsole.conf is properly configured before rebooting after the installation finishes, which archinstall should do. But could you please post your contents of /etc/vconsole.conf?

We should perhaps consider adding sd-vconsole if we're running systemd init.

[MaxXor]

I've used v2.2.0 at that time. I can give it a try at the weekend, didn't install my system this way.

[Torxed]

It would help a lot if you did!

[MaxXor]

I've tested it now with the Archboot ISO 2022.05.01-x86_64 and archinstall v2.4.2. The issue remains unchanged.

/etc/mkinitcpio.conf

MODULES=()
BINARIES=()
FILES=()
HOOKS=(base udev autodetect keyboard keymap modconf block encrypt filesystems fsck)

/etc/vconsole.conf

KEYMAP=de

After the installation and final reboot I tried to decrypt the partition, but it refused my password, so I changed the keyboard layout of my 2nd machine to US, checked which characters I needed to type and et voilà it unlocked using the US keyboard layout...

So I assume the correct keymap is not loaded with systemd-boot.

A workaround would be to switch the keyboard layout temporarily to US when the user enters the encryption password in the archinstall script and switch back after the input was submitted.

[Torxed]

It's weird, because I can't find any information that this should not work. dm-crypt#mkinitcpio dictates that:

HOOKS=(base udev autodetect keyboard keymap consolefont modconf block encrypt filesystems fsck)

Should work just fine. The only difference being consolefont which shouldn't matter.

I was wondering if we got the correct layout while setting the password? I've verified this by entering qwerty on my keyboard (Swedish) with a de layout I get qwertz as expected. And I verified this by checking /tmp/sda2.disk_pq and printed the password used here: https://github.com/archlinux/archinstall/blob/a748f3fba04e771a3c18e66efcd2cf48b42c778e/archinstall/lib/disk/filesystem.py#L126-L128

After rebooting, I've verified that this issue presents itself 100% as you describe. I'd expect to write qwerty (to input qwertz) but had to write qwertz as it uses us layout despite visibly loading keymap before the password prompt.

Changing the order of HOOKS appears to have little to no effect on the issue either. Login prompt accepts the keymap perfectly. grunts while debugging

[Torxed]

What appears to fix it is setting:

LANG=en_DE.UTF-8

In /etc/vconsole.conf for some reason. I don't find any mention of this, but without it the de profile appears to be broken with the keymap, de-latin1 appears to be working fine.

And it appears that this has been an on-going bug for ages:

• https://bbs.archlinux32.org/viewtopic.php?id=2953
• https://bbs.archlinux32.org/viewtopic.php?id=3002
• https://bbs.archlinux32.org/viewtopic.php?id=506

We can make sure to add LANG= to the vconsole, but I'm not sure how we can reliably determine it. As setting keyboard layout is pretty easy through localectl as it's pretty source agnostic and handles both X11 and console stuff for us. But I doubt LANG=$(localectl | grep 'VC Keymap').UTF-8 would work very well. So how do we map keymap into a LANG= variable, as LANG requires both the keymap and the system locale.

[Torxed]

Wait, maybe we can do LANG=$(localectl | grep 'X11 Layout') as that contains the shortened version in both de-latin1 and de cases. I wonder how risky this is tho..

[Torxed]

Scratch those two previous posts.. Re-did it again and now it's back to not functioning. I don't think I did anything, except tried to generate keymap.bin (loadkeys -q -u de -b > keymap.bin) and putting it on the boot partition. But that didn't fix anything the first go around..

[Torxed]

Ah, after one of the above changes I had to re-run mkinitcpio -P which I forgot to document. I'll try to figure out which of the steps above solved the issue. It's either:

1. LANG=de_US.UTF-8 <-- Winner
2. /boot/keymap.bin
3. LANGUAGE=de_US.UTF-8
4. LANG=en_DE.UTF-8
5. + mkinicpio -P after those changes <-- Winner

[MaxXor]

Thanks a lot for troubleshooting this problem. Let me know if I can help. Interestingly on a 2nd machine I have set up the encrypted root partition a bit differently using dm-crypt instead of LUKS. In that case everything works as expected with KEYMAP=de in /etc/vconsole.conf.

[Torxed]

I've added a PR to address this. Running tests against it now. I'm also looking into using sd-encrypt hook, which has sd-vconsole which would perhaps be more stable.

[Torxed]

So weird.. Implemented and it's executing the steps.. But now the fix doesn't work? Tried two different ways of populating the file and none of them works:

This is a really annoying one :P

[neitsab]

Just got bit by this bug with archiso 2023-04. After the install this was my vconsole.conf content:

KEYMAP=fr
XKBLAYOUT=fr
XKBMODEL=pc105
XKBOPTIONS=terminate:ctrl_alt_bksp

I changed it to:

KEYMAP=fr-latin9
FONT=lat9w-16
XKBLAYOUT=fr
XKBMODEL=pc105
XKBOPTIONS=terminate:ctrl_alt_bksp

and then after rebuilding the initramfs (and applying the fix for #1716), unlocking the root LUKS container with my French layout worked. This is pretty major for all the non-QWERTY/en_US using userbase...

Cheers

[Torxed]

KEYMAP=fr

Did you select fr-latin9 in the language/locale selection of archinstall?

[neitsab]

It baffles me because it is the option I always select anytime I get the choice, but after reviewing the install log it appears that indeed, I had only selected fr in archinstall... Sorry for the useless report.

On the flip side of the coin, doesn't that mean this issue is actually fixed?

[Torxed]

I think so yes, I'll go ahead and close it and can re-open if needed.

[lakano]

I had the same issue (arch ISO of 1st January 2024), installation in fr-latin9 ( correctly set in KEYMAP of /etc/vconsole.conf ), I had to fill the password in QWERTY rather than in AZERTY. But the problem have been solved after my 1st rebuild of initramfs => sudo mkinitcpio -P My boot setup is systemd-boot / UKI / default partitions / LUKS on full partition / btrfs

May be it's a little bug in the archinstall, perhaps the /etc/vconsole.conf is updated only after using mkinitcpio?

[codefiles]

May be it's a little bug in the archinstall, perhaps the /etc/vconsole.conf is updated only after using mkinitcpio?

You are correct. The mkinitcpio call will occur in Installer.minimal_installation() or Installer.add_bootloader(), if the unified kernel images option is used. The /etc/vconsole.conf file will be created by Installer.set_keyboard_language(). minimal_installation() will run pacstrap, setting up the environment, and that must be done first for set_keyboard_language() to function properly.

One way to fix this issue would be to have add_bootloader() take place after set_keyboard_language(), disable the mkinitcpio call in minimal_installation() using the mkinitcpio function parameter and instead use Installer.mkinitcpio(). Here is a patch to fix it for the guided installer in this way: https://github.com/archlinux/archinstall/commit/933ab054789a7833418316e62e71de8a6d9840e8

Another way to do this would be to just add a call to set_keyboard_language() inside of minimal_installation() before the mkinitcpio call but I am concerned with the following comment.

https://github.com/archlinux/archinstall/blob/f107104103b74ac065a56bd94a0878f0d263e177/archinstall/scripts/guided.py#L201-L203

@svartkanin, changes have been made to profiles since this comment was added, do you know if this comment is still accurate or not? I cannot figure out what it is referring to and your help would be appreciated.

[svartkanin]

The profile installation process installs xorg and other stuff, so I think for the set kb lang to work properly on x11 it would need to be after. But I'd have to dig through the code to be absolutely sure

[codefiles]

Would you mind reopening the issue? Thanks.

Here is what /etc/vconsole.conf looks like after set_keyboard_language() when the keymap is us.

# Written by systemd-localed(8) or systemd-firstboot(1), read by systemd-localed
# and systemd-vconsole-setup(8). Use localectl(1) to update this file.
KEYMAP=us
XKBLAYOUT=us
XKBMODEL=pc105+inet
XKBOPTIONS=terminate:ctrl_alt_bksp

This will be the result of executing localectl set-keymap us, the underlying command of set_keyboard_language() when the keymap is us, and will be the same with or without Xorg installed (note that XKBLAYOUT is set either way). This is part of the reason I am unsure that this really needs to come after the profile installation process. I am also confused by the mention of 'language pre-requisites' in the comment because I do not know what that is referring to.

I did some digging through the code but did not find anything.

[zenlord]

I just encountered the same issue. My setup and experience is similar to that one of @lakano , except that I did not select the UKI option. Rebuilding the initramfs after install resulted in a correct keymap being used during initramfs.

[codefiles]

After some more research I would say the following code comment is not accurate.

https://github.com/archlinux/archinstall/blob/624d3d5bf64b05388623d817454389832d1711af/archinstall/scripts/guided.py#L196-L198

Here is what is wrong with the code comment.

1. profiles_bck should be default_profiles
2. no mention of any "language pre-requisites" on the ArchWiki [1][2]
3. set_keyboard_layout() functions the same whether xorg-server is installed or not and creates the following:
   • /etc/vconsole.conf for the Linux console keyboard configuration
   • /etc/X11/xorg.conf.d/00-keyboard.conf for X11 keyboard configuration

Considering this, moving the set_keyboard_language() call to inside of minimal_installation(), before the mkinitcpio call, appears to be the best fix.

[1] https://wiki.archlinux.org/title/Linux_console/Keyboard_configuration [2] https://wiki.archlinux.org/title/Xorg/Keyboard_configuration