Keymap at boot time & LUKS

[Myu]

Hello there,

Since a recent update (udev?), my custom keymap at boot time is not loaded, hence I need to type my LUKS password as if I'm using a QWERTY keyboard which is pretty annoying...

Is there a "proper" way to fix that ?

Right now my openRC is setup like this :

Code: Select all

rc-config list | grep "dmcrypt\|keymaps"
  dmcrypt                   boot
  keymaps                   boot

My /etc/conf.d/keymaps is properly configured.

Appreciate any insight

[Myu]

Small bump (sorry if not allowed) ?

I tried to play with rc_need and the like but no luck so far.

[NeddySeagoon]

Myu,

I guess its the keymap in the initrd if you have everything except /boot encrypted.
openRC isn't normally in the initrd.

[weiypan_us]

Hi, are your directory /usr on root fs or on an independent volume mounted on root fs?

Could you try command 'udevadm trigger' to see any errors ?

Small bump (sorry if not allowed) ?

I tried to play with rc_need and the like but no luck so far.

[Myu]

Myu,

I guess its the keymap in the initrd if you have everything except /boot encrypted.
openRC isn't normally in the initrd.

Hello Neddy !

Actually, no only my /home is encrypted, / and /boot are in clear and I don't have an initrd, so just setting up /etc/conf.d/keymaps + enabling the openrc service should be (and has been for years) enough but somehow now the order is messed up and keymaps is loaded waaay after.

Hi, are your directory /usr on root fs or on an independent volume mounted on root fs?

Could you try command 'udevadm trigger' to see any errors ?

Hi weiypan_us !

Nope, my /usr in an integral part of my rootfs, same partition

udevadm trigger seems ok, looks present in rc-config list

Code: Select all

Dwarf ~ # udevadm trigger
Dwarf ~ # echo $?
0
Dwarf ~ # rc-config list | grep "udev"
  udev                      sysinit
  udev-settle
  udev-trigger              sysinit

[freifunk_connewitz]

I can confirm this, same setup, same error.

last possibly relevant packages updated since this occurs: udev, curl, busybox

(edited)

[freifunk_connewitz]

Maybe a hint: one update that happened before the problem occured was the keymaps under /usr/share/keymaps. that would be the package sys-apps/kbd.

I tried to find a probable reason there but to no avail.

Anybody else an idea?

[NeddySeagoon]

freifunk_connewitz,

Unpack your initrd and look for the keymap being provided and set.
There will need to be a line in the init script and the keymap you want to use will need to be included too.

If its missing, you can add things and repack the initrd. Its a bit of a hack doing it that way.
Be sure the keymap is set before the initrd asks for your LUKS pass phrase.

[freifunk_connewitz]

Neddy,

Thanks for helping. But as I said, I have basically the same setup as the OP. No initrd, just plain normal booting with unencrypted /root. LUKS only unlocks /home. And a 'de-latin1' keymap.

I had a closer look at /var/log/rc.log and it seems that the reason for the problem could be the init-script order. Keymaps are loaded way after the dm-crypt mappings are initialized.

I tried to add to /etc/conf.d/dmcrypt:

Code: Select all

RC_AFTER="keymaps"

But that broke my boot process, with init complaining that root, bootmisc and mtab could not be started because fsck could not be started. It seems like keymaps are not able to be loaded before dmcrypt, right?

If that is the case, I could live with just typing my LUKS passwords as if I used a default QWERTY keyboard, not the one I really have. But then there should be a big warning in the elog of the cryptsetup package that people with other than default english keymaps should only use passwords where they know the keys are at the default keyboard.

And it does not explain why it worked until recently.

[Myu]

freifunk_connewitz summed up my experience as well, it worked for years before for sure.

Would it be useful to enter a bug for such behaviour ?

[freifunk_connewitz]

Myu,
I would think so, too. But against which package? cryptsetup? kbd? openrc? Maybe we should start with the Gentoo cryptsetup maintainers.
I also wonder why we two seem to be the only ones affected here. Is it that exotic nowadays to have an encrypted /home instead of whole system?

[Myu]

Hello,

I was about to (finally) take the time to open a bug but there's one here already

Let's see how it goes !

[mslt]

For me the easy "fix"/workaround was to add the "keymap=de" (de ofc only for a german keymap) parameter to the kernel cmdline in my grub cfg. It works just fine for me.

[Myu]

Hey mslt,

Thanks for the comment, I tried with be and be-latin1 but it doesn't work for me. No initramfs, /home encrypted but not /

[freifunk_connewitz]

Same for me. I added

Code: Select all

append = "keymap=de-latin1"

(or "de") to the boot section in my lilo.conf but nothing changed. (There is also a lilo function to create keymaps for boottime use - keytab-lilo - but this seems to be broken, too.)

[freifunk_connewitz]

After years of typing LUKS passwords on bootup as if I had a QWERTY keyboard, on a number of machines, also ones set up freshly, with lilo or grub, but all on openrc, yesterday's world update solved the issue. Now I have to type the passwords using the correct keymap (in my case QWERTZ-DE).

Here is the list of packages updated. I removed obvious non-relevant ones.

It seems it was NOT openrc. I suspect util-linux.

Code: Select all

grep '> emerge' /var/log/emerge.log
1593524893:  >>> emerge (1 of 35) sys-devel/llvm-common-10.0.0 to /
1593524916:  >>> emerge (2 of 35) sys-kernel/linux-firmware-20200619 to /
1593524944:  >>> emerge (3 of 35) sys-devel/binutils-config-5.3.1 to /
1593524950:  >>> emerge (4 of 35) sys-devel/gcc-config-2.3 to /
1593524956:  >>> emerge (5 of 35) dev-libs/vala-common-0.48.6 to /
1593524963:  >>> emerge (6 of 35) virtual/os-headers-0-r2 to /
1593524969:  >>> emerge (7 of 35) virtual/libc-1-r1 to /
1593524974:  >>> emerge (8 of 35) sys-devel/clang-common-10.0.0 to /
1593525032:  >>> emerge (10 of 35) net-misc/curl-7.71.0 to /
1593525086:  >>> emerge (11 of 35) net-misc/rsync-3.2.0-r1 to /
1593525217:  >>> emerge (15 of 35) sys-process/lsof-4.93.2-r1 to /
1593525225:  >>> emerge (16 of 35) sys-libs/libomp-10.0.0 to /
1593525243:  >>> emerge (17 of 35) dev-db/mariadb-connector-c-3.1.9 to /
1593525257:  >>> emerge (18 of 35) sys-apps/util-linux-2.35.2 to /
1593525303:  >>> emerge (19 of 35) dev-db/mariadb-10.4.13 to /
1593525618:  >>> emerge (20 of 35) sys-devel/llvm-10.0.0 to /
1593527460:  >>> emerge (23 of 35) app-admin/syslog-ng-3.26.1-r1 to /
1593527528:  >>> emerge (24 of 35) dev-lang/vala-0.48.6 to /
1593527618:  >>> emerge (26 of 35) sys-apps/accountsservice-0.6.55 to /
1593527648:  >>> emerge (28 of 35) net-libs/signond-8.60-r2 to /
1593527921:  >>> emerge (31 of 35) sys-devel/clang-10.0.0 to /
1593529991:  >>> emerge (32 of 35) sys-libs/compiler-rt-10.0.0 to /
1593530010:  >>> emerge (33 of 35) sys-libs/compiler-rt-sanitizers-10.0.0 to /
1593530073:  >>> emerge (34 of 35) sys-devel/clang-runtime-10.0.0 to /

[freifunk_connewitz]

I have to unearth this thread so that others with this problem find a solution. Reason: After 5 years, some update broke the Luks device decrypting process again. Typing password for encrypted /home as if using an EN keyboard works, typing according to my DE keyboard layout does not, as described above. I refrain from speculating which update did it because I've updated a 173 packages after returning from holidays.

Solved by changing the order of the rc services: service 'dmcrypt' needs service 'keymaps':

in /etc/rc.conf

Code: Select all

rc_dmcrypt_need="keymaps"