Rd.vconsole.keymap not honored when entering LUKS passphrase

I have to type passphrase for cryptsetup in plymouth prompt with US keyboard layout alhough I specified different keyboard layout via kernel commandline option rd.vconsole.keymap.

Anybody knows a workaround?

It is possible, but setting it up does not seem trivial by any means. See here: https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

5 Using a custom keyboard layout

GRUB uses the US keyboard layout by default. Alternative layouts for the LUKS passphrase prompts can’t be loaded from /boot or the root file system, as the underlying devices haven’t been mapped yet at that stage. If you require another layout to type in your passphrase, then you’ll need to manually generate the core image using grub-mkimage(1). A possible solution is to embed a memdisk containing the keymap inside the core image.

  1. Create a memdisk (in GNU tar format) with the desired keymap, for instance dvorak’s. (The XKB keyboard layout and variant passed to grub-kbdcomp(1) are described in the setxkbmap(1) manual.)
root@debian:~# memdisk="$(mktemp --tmpdir --directory)"
root@debian:~# grub-kbdcomp -o "$memdisk/keymap.gkb" us dvorak
root@debian:~# tar -C "$memdisk" -cf /boot/grub/memdisk.tar .
  1. Generate an early configuration file to embed inside the image.
root@debian:~# uuid="$(blkid -o value -s UUID /dev/sda1)"
root@debian:~# cat >/etc/early-grub.cfg <<-EOF
	terminal_input --append at_keyboard
	keymap (memdisk)/keymap.gkb
	cryptomount -u ${uuid//-/}

	set root=(cryptouuid/${uuid//-/})
	set prefix=/grub
	configfile grub.cfg
EOF

3.Note*: This is for the case of a separate /boot partition. If /boot resides on the root file system, then replace /dev/sda1 with /dev/sda5 (the LUKS device holding the root file system) and set prefix=/boot/grub; if it’s in a logical volume you’ll also need to set root=(lvm/DMNAME).Note: You might need to remove the first line if you use a USB keyboard, or tweak it if GRUB doesn’t see any PC/AT keyboard among its available terminal input devices. Start by specifing terminal_input in an interactive GRUB shell in order to determine the suitable input device. (Choosing an incorrect device might prevent unlocking if no input can be be entered.)
4. Finally, manually create and install the GRUB image. Don’t use grub-install(1) here, as we need to pass an early configuration and a ramdisk. Instead, use grub-mkimage(1) with suitable image file name, format, and module list.

root@debian:~# grub-mkimage \
    -c /etc/early-grub.cfg -m /boot/grub/memdisk.tar \
    -o "$IMAGE" -O "$FORMAT" \
    diskfilter cryptodisk luks gcry_rijndael gcry_sha256 \
    memdisk tar keylayouts configfile \
    at_keyboard usb_keyboard uhci ehci \
    ahci part_msdos part_gpt lvm ext2

(Replace with ahci with a suitable module if the drive holding /boot isn’t a SATA drive supporting AHCI. Also, replace ext2 with a file system driver suitable for /boot if the file system isn’t ext2, ext3 or ext4.)The value of IMAGE and FORMAT depend on whether GRUB is in EFI or BIOS mode.

  1. For EFI mode: IMAGE="/boot/efi/EFI/debian/grubx64.efi" and FORMAT="x86_64-efi".
  2. For BIOS mode: IMAGE="/boot/grub/i386-pc/core.img", FORMAT="i386-pc" and set up the image as follows:
root@debian:~# grub-bios-setup -d /boot/grub/i386-pc /dev/sda

You can now delete the memdisk and the early GRUB configuration file, but note that subquent runs of grub-install(1) will override these changes.

What are you using to unlock in this case? Since you are referring to plymouth, I assume it isn’t grub.

Is it luks or zfs encryption?

@dalto LUKS. And I am using systemd-boot, not GRUB, @BluishHumility . Sorry that I haven’t mentioned it in the first post.

Yes, I understand that all files must be in initramfs, but I suppose that’s the job of dracut when I specified the layout with rd.vconsole.keymap in /etc/kernel/cmdline and KEYMAP in /etc/vconsole.conf.

Ah, in that case most likely you just need to regenerate the images.

sudo dracut-rebuild

Did you run sudo reinstall-kernels after making that change?

@BluishHumility @dalto I did run dracut --force to rebuild initramfs, of course, but it doesn’t have any effect, that’s why I am asking about a workaround.

dracut --force isn’t what you need to run. You need to run sudo reinstall-kernels so the changes from /etc/kernel/cmdline are propagated to your entries.

Also, dracut --force will often write the initramfs to the wrong location so you should always use dracut-rebuild instead. However, in this case, you don’t need to do that since reinstall-kernels will also rebuild the initramfs.

1 Like

No difference.