[pkg-cryptsetup-devel] Bug#874364: Keyboard layout set in GNOME or with localectl does not apply to initramfs LUKS prompt immediately

[Guilhem Moulin]

Control: reassign -1 gnome-control-center,systemd,initramfs-tools

Hi,

On Fri, 17 Aug 2018 at 10:44:55 +0100, Simon McVittie wrote:
> Control: reassign -1 gnome-control-center,systemd,cryptsetup-initramfs

cryptsetup-initramfs doesn't mess around with the keyboard layout.
Installing custom layouts is done (at init-top stage) by the ‘keymap’
initramfs-tools boot script:

    https://sources.debian.org/src/initramfs-tools/0.132/scripts/init-top/keymap/

> On Sun, 04 Mar 2018 at 20:26:51 +0100, iiro at laiho.me wrote:
>> 2) What is written in above propagates to the LUKS passphrase prompt
>> only when the initrd regeneration is triggered, e. g. after kernel
>> upgrade.
> 
> This is certainly unfortunate, and I think it's what's causing the worst
> of the unpredictability for you. I'm not sure which component would
> need to change to fix that, though; having systemd-localed regenerate
> the initramfs whenever the system-wide default keyboard layout is set
> seems disproportionate?

Right now the keyboard layout is taken from the initramfs' /etc/boottime.kmap.gz,
so it's not possible to change it without regenerating the initramfs
image.

I don't know where else the keymap can be stored, because at early boot
stage the main system's partitions aren't mounted (or even unlocked)
yet.

Boot loaders have the same problem, FWIW.  Changes to the keyboard
layout of the main system won't be applied to GRUB unless the admin
manually runs grub-mklayout(1) or similar.  Moreover if /boot is
encrypted, then one needs to build a new image after each change to the
keyboard layout, because in that case the keymap is not loaded from the
(unavailable) /boot, but from the image itself.

A possible solution to remove the “unpredicatable” character (it depends
on whether a package remove/install/upgrade triggers a rebuild of the
initramfs image) of which keymap is loaded at initramfs stage, would be
to have the initramfs-tools' ‘keymap’ hook try to copy a preexisting
keymap file, such as ‘/etc/initramfs-tools/keymap’, instead of
auto-generating (using `setupcon --save-keyboard $FILE`) it upon
mkinitramfs(8).

That way one would always get the same keymap at initramfs stage,
regardless of the keymap of the main system.  If keymap changes to the
main system need to be applied at initramfs stage too, then one would
need to *manually* run `setupcon --save-keyboard $FILE` and rebuild the
initramfs image.  (If that's acceptable then maybe this bug should be
reassigned to initramfs-tools and its severity lowered to wishlist.)

Cheers,
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180817/9eac4e22/attachment-0001.sig>