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, i...@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
