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@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.
Attachment:
signature.asc
Description: PGP signature