Hello,
I would like to report an issue related to encrypted systems using LUKS
and non-US keyboard layouts in GNU Guix with GRUB EFI.
On my laptop, the LUKS passphrase prompt during early boot always uses a
US/QWERTY keyboard layout, even though the system is configured with:
|(keyboard-layout (keyboard-layout "fr" "azerty")) |
both at the |operating-system| level and inside |bootloader-configuration|.
Interestingly, once the GRUB menu itself appears, the French AZERTY
layout works correctly. This strongly suggests that the keymap is loaded
too late in the GRUB initialization sequence.
After investigation, I found that the generated |/boot/grub/grub.cfg|
contains:
|insmod luks insmod luks2 cryptomount -u ... ... insmod keylayouts
keymap /gnu/store/...-grub-keymap.fr |
This means the |cryptomount| commands (and therefore the LUKS passphrase
prompt) occur before the French keymap is loaded.
As a result:
*
the LUKS prompt appears to interpret input as US/QWERTY;
*
the configured keyboard layout only becomes active afterward, once
the GRUB menu appears.
Therefore, it seems that Guix currently generates the GRUB configuration
in an order that may prevent non-US keyboard layouts from being applied
to early LUKS passphrase prompts.
For context:
*
|/boot| itself is not encrypted;
*
this occurs on a laptop using GRUB EFI;
*
on another machine accessed through IPMI Serial-over-LAN, the issue
is not visible because input handling differs through the serial
console.
For transparency: this report was written with the assistance of
ChatGPT, under my direction. ChatGPT helped identify the likely root
cause by analyzing the generated |grub.cfg| and noticing that the
|keymap| command is inserted after the |cryptomount| commands.
Thank you for your work on GNU Guix and GRUB integration.
Best regards,
Mathieu
