Dear Maintainer,

When I set the system keymap using the "localectl" command, the
application of the new layout to the virtual consoles is delayed. The
delay seems to be unpredictable. I have currently no idea what does
finally trigger the change or when it happens. Sometimes reboot seems to
do it, sometimes not.

I consider this "important" because it can confuse user to think that
the command and/or e. g. gnome-control-center keyboard layout
configuration does not affect the virtual consoles.

The following lines are written in the journalctl:
Virtualbox machine with Buster. On a virtual machine with Fedora 29,
however, the configuration is instant.

Related: #874364 - Keyboard layout set in GNOME or with localectl does
not apply to initramfs LUKS prompt immediately

Am 30.03.19 um 18:11 schrieb Iiro Laiho:

Can you post the exact commands you used and what you did next.
I'm not quite sure what you mean with "application of the new layout to
the virtual consoles is delayed".
Did you logout/login again in the mean time and still got the same layout?

TTBOMK, localectl just writes to /etc/default/keyboard and /etc/default
/console-setup and leaves it up to console-setup to apply those changes,
which is usually done during bootup.
There is also a /lib/udev/rules.d/90-console-setup.rules, i.e is
triggered via udev. So it might be possible, that console-setup applies
the changes when the hardware configuration changes.



Michael

Let's say we want to use the "fi" keyboard layout with variant "das". It
is one of those "exotic" variants that are in the xkb's
"base.extras.xml". I am not quite sure whether or not it matters. Then
we run:

$ localectl set-x11-keymap fi das

The layout is not applied immediately. I am not sure when it is applied,
but apparently it eventually will be. Sometimes running
"dpkg-reconfigure keyboard-configuration" and telling it to keep the
current /etc/default/keyboard settings helps, but for some reason my
system does not show that option anymore. Anyway, no further steps
should be necessary after running that localectl command. This issue is
not limited to the CLI configuration: gnome-control-center also uses
localed to choose the system-wide keyboard mapping.

Btw, "fi das" is a non-QWERTY layout so it is recommendable to do these
tests on a machine that has a SSH server or something other that can be
used to switch the layout back.

Yeah, just noticed that myself. On Debian localed apparently just edits
the while when console-setup applies it.

Cheers,
Iiro

Hi,


This issue is still present in recent Debian/Ubuntu versions.


 > Am 30.03.19 um 18:11 schrieb Iiro Laiho:
 > > When I set the system keymap using the "localectl" command, the

 > > application of the new layout to the virtual consoles is delayed.


On Sun, 31 Mar 2019 20:23:09 +0200 Michael Biebl <biebl@debian.org> wrote:

 > TTBOMK, localectl just writes to /etc/default/keyboard and /etc/default

 > /console-setup and leaves it up to console-setup to apply those changes,
 > which is usually done during bootup.



Yes, your Debian specific stuff in
debian/patches/debian/Use-Debian-specific-config-files.patch only seems
to set /etc/default/keyboard

However with other Linux distributions the setting is also instantly
applied to console, so that is what me and other users are expecting.


With other Linux distributions this seems to be done by restarting the
systemd-vconsole-setup unit in src/local/localed.c vconsole_reload() :

https://github.com/systemd/systemd/blob/main/src/locale/localed.c#L97

Think that function needs to be patched by whatever is necessary to have
the change do take effect on Debian (run "dpkg-reconfigure
keyboard-configuration" and "setupcon -k --force" ?)



Yours sincerely,


Floris Bos

Currently we disable vconsole via debian/rules, so there is no
systemd-vconsole-setup.service.

Maybe a fix could be as simple as shipping a symlink
systemd-vconsole-setup.service → keyboard-setup.service ?
Or do we need to restart console-setup.service as well?

I recall in some cases it is also necessary to regenerate initramfs
after a keyboard settings change.

E.g. when LUKS encryption is used and the user needs to be able to enter
the password to unlock the disks in the console prior to the rest of the
system being booted.

So just restarting one of the services actually may not be enough.



Yours sincerely,


Floris Bos

Well, I'm not yet convinced that doing this in localed is the correct place.
After all, if you run dpkg-reconfigure console-setup, it doesn't update
the initramfs either, or does it?

It does on my Ubuntu box.

Not certain about upstream Debian.

it doesn't