[systemd-devel] vconsole.conf, systemd-localed and the console keymap in the initrd

[Lennart Poettering]

On Di, 30.07.19 10:49, Hans de Goede (hdegoede at redhat.com) wrote:

> I believe that the best way to fix is this is probably to specify the
> keymap on the kernel commandline using vconsole.keymap= on the kernel
> commandline.

As you found out, our current logic is to let kernel cmdline settings
override everything else.

To implement what you are looking for we probably should add a new
setting vconsole.default_keymap= or so which can set the default which
is used when there's no vconsole.conf or so defined.

That said, I wonder if it wouldn't be easier to just define some basic
EFI variables for this kind of super basic settings, and then read
those. It appears to me that everything doing early boot stuff might
want to do this, and it shouldn't require kernel cmdline patching.

Of course, that would solve it for EFI only, but I fiugre that's like
99% of the machines you want to cover?

Note that on secureboot envs you cannot really change the kernel
cmdline options though, can you? i mean if you could, then you could
add any rubbish you'd like too, no?

> 1) What is your (systemd devs) take on this, does using vconsole.keymap=
> on the kernel commandline sound like the right solution, or do you have
> other suggestions?

My preference would be to go the EFI variable way, but the
"vconsole.default_keymap=" thing works too I guess for the
non-SecureBoot cases, if that's al you care about?

> 2) I wonder what will happen when runtime changing the keymap when
> vconsole.keymap=foo is specified on the kernel commandline?

Nothing, they are ignored.

> is not a problem. But I wonder how systemd-localed applies changes
> to the current vtconsole(s) does it do this itself, or does it use
> systemd-vconsole-setup for this ?

The latter, but that's an implementation detail I guess.

> I ask because if it uses systemd-vconsole-setup and that prefers the
> kernel commandline value then the change will not happen until reboot.
> Which I believe would be a regression compared to how things work
> now...

Yupp, that would be.

Lennart

--
Lennart Poettering, Berlin