Short version

How can I know which keymap is used when I am prompted for my password by LUKS?

Long version

I am using three keyboards and their mappings (US-Qwerty, FR-Azerty, and FR-Bepo), and frequently alternates between them. I used this workaround to be able to type the same password (that I added following those advices) regardless of which mapping is currently active and which keyboard I am using, but don't find it very clean.

Various solutions (example 1, example 2) recommend to edit /etc/vconsole.conf, but this file is not present on my installation and I'd rather do without if that's possible. There seems to be a way by editing initramfs.conf but I'm not sure I understand it correctly, and I would prefer to first understand which keymap is active now.


uname -a 
Linux XXX 6.1.0-12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.52-1 (2023-09-07) x86_64 GNU/Linux
  • What Linux distribution are you using? What initramfs builder is it using? (Assuming the prompt is for unlocking your root filesystem, that is?) Commented Sep 19, 2023 at 4:49
  • Debian stable / I don't know, how can I figure this out / Yes, the prompt is to unlock my root filesystem.
    – Clément
    Commented Sep 19, 2023 at 4:53
  • Debian almost always uses its own "update-initramfs" tool. (Other distros may use dracut, or mkinitcpio, or genkernel, or a few others – they all differ in which config files they'll use; e.g. vconsole.conf usage usually depends on whether the initramfs includes systemd in it.) Commented Sep 19, 2023 at 5:04
  • Yes, that's most likely what was run, update-initramfs. I was not aware that other distros had other tools for this task, thanks.
    – Clément
    Commented Sep 19, 2023 at 5:07

1 Answer 1


LUKS doesn't have keymaps. It doesn't read keyboard input on its own – it's just a generic console program that reads console text input, leaving it to the console to map the keys.

Various solutions (example 1, example 2) recommend to edit /etc/vconsole.conf, but this file is not present on my installation

That's usually normal. Not all configuration files are present on every installation. Indeed a big part of systemd's overall design is that no "default" or "template" configs should be present in /etc, with everything static being in /usr/lib instead. (Many other projects have since followed that convention.) So the absence of a config file is not an indicator that the system won't use the file, and should not stop you from creating it if you know that the system does use it.

(On the other hand, as in many thing systemd, it does have an alternative: the vconsole.keymap= kernel command-line option mentioned in the vconsole.conf manual page, which – if your system was using systemd-vconsole for this – you could add to your GRUB configuration.)

That being said, I don't think Debian actually uses systemd-vconsole at all; not even for the main (rootfs) boot. (And the initramfs is a whole separate world of its own, having its own config files and everything. As mentioned in the comments, initramfs building varies greatly between distributions – Debian uses its own "initramfs-tools" to do so, while other distributions may use Dracut, mkinitcpio, Booster, genkernel, and so on.)

So in your case, the Ubuntu instructions for /etc/initramfs-tools/initramfs.conf are the most suitable for Debian's initramfs as well.

I would prefer to first understand which keymap is active now.

Unpacking the initramfs (it is a mini-rootfs in a cpio archive) with lsinitramfs or cpio or bsdtar might reveal what keymap files, if any, are embedded in it. Enabling verbose mode when the initramfs is being built, with update-initramfs -u -v, may also reveal it.

But in Debian's case, unfortunately a generic file name seems to be used – it just takes whatever "cached" keymap was present in the main system when the initramfs was built. All it reveals is whether there is a keymap in the initramfs, or not.

So if you just built a fresh initramfs, it should be safe to assume that it will either use whatever console keymap has been configured via /etc/default/keyboard (if the KEYMAP=y option has been enabled in initramfs.conf), or the generic built-in 'us' keymap (if it hasn't been enabled). For example, this shows that the system keymap has been copied into the initramfs:

# update-initramfs -u -v
Calling hook keymap
Adding binary /usr/bin/kbd_mode
Adding binary /usr/bin/loadkeys

# lsinitramfs /boot/initrd.img-6.1.0-12-amd64 | grep kmap

# bsdtar -tf /boot/initrd.img-6.1.0-12-amd64 | grep kmap

Finally, interrupting your initramfs with a kernel option such as break=premount should give you a shell at the correct point in time (after loading the keymap but before the LUKS prompt) where you could press keys and see what gets typed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .