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

[Simon McVittie]

Control: severity -1 important
Control: retitle -1 Keyboard layout set in GNOME or with localectl does not apply to initramfs LUKS prompt immediately
Control: reassign -1 gnome-control-center,systemd,cryptsetup-initramfs

On Sun, 04 Mar 2018 at 20:26:51 +0100, iiro at laiho.me wrote:
> 1) The per-user layout influences the console layout when there is only
> one user. This in itself is somewhat reasonable, if little confusing to
> someone who has used to the old UNIX model that normal user cannot edit
> system-wide settings.

Yes, this is intentional design in gnome-control-center. As you said,
gnome-control-center sets the system-wide locale and keyboard layout by
asking systemd-localed to do it.

I don't think the delay in propagating this change into boot-time LUKS
prompts is a GNOME bug, because I think you'd still see the same issue if
you used localectl(1) to change the system-wide keyboard layout directly,
for example with "localectl set-x11-keymap gb pc105" (possibly with sudo).

It is true that normal users cannot (in general) edit system-wide
settings, but your user account is in the sudo group, so it is
root-equivalent, not a normal user. gnome-control-center installs
/var/lib/polkit-1/localauthority/10-vendor.d/gnome-control-center.pkla
to set this up; you can override it to deny that permission by copying
that file into /etc/polkit-1/localauthority/50-local.d/ and changing
ResultActive=yes to some other value like ResultActive=auth_admin_keep
or ResultActive=no if desired. (See pklocalauthority(8).)

> 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?

Can any of the involved maintainers (cc'd) think of a less "expensive"
way to propagate changes to the system-wide default keyboard layout into
the initramfs environment?

>From <https://bugzilla.redhat.com/show_bug.cgi?id=880271> it looks as
though Fedora uses a kernel command-line parameter for this, which
can be reconfigured by altering the bootloader (grub) configuration.

> The prompt does not echo the passphrase, nor does not show the
> keyboard layout that is being used.

Not echoing the passphrase is deliberate: in general, passphrases should
not appear on the screen. If you install the plymouth package, the number
of characters typed will become visible as ****, but that doesn't help
you to identify a keyboard layout, unless your keyboard layout happens
to include "dead keys".

Decrypting the root filesystem happens in a sufficiently minimal
environment that providing a more elaborate UI, such as a "show password"
button, is far from straightforward.

> 3) If user selects an "extra" keyboard layout after enabling them
> in GNOME by running "gsettings set org.gnome.desktop.input-sources
> show-all-sources true", it will will propagate to the console properly,
> but NOT to the GDM. This makes it even more confusing.

I'm not sure how this is meant to interact with gdm, but I think this
should probably be handled as a separate bug. Please could you report
this as a separate bug against gdm3, with steps to reproduce it (ideally,
a set of steps that work for a non-"extra" layout but fail for an "extra"
layout)? It's possible that the gdm greeter also needs to be told to show
"extra" keyboard layouts.

    smcv