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

[Hans de Goede]

Hi Lennart,

On 31-07-19 14:07, Lennart Poettering wrote:
> 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.

Hmm, that would fix the silverblue case, but not the regular Fedora
case unless we patch dracut to omit vconsole.conf. I was thinking
myself about maybe making systemd-vconsole-setup recognize
rd.vconsole.keymap but only when it is running from the initrd (*).

This is what dracut initrds use when not using systemd in the
initrd, so it would add some backward compatibility to kernel
commandlines which use those old options and it should nice solve
the keymap in initrd issue.

*) This requires systemd-vconsole-setup being able to reliable tell
it is running from the initrd, I'm not 100% sure if that is possible.

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

Sorry, and EFI only solution is not going to cut it, there are still
a lot of users out there using classic BIOS boot and we still support
systems which only support BIOS boot (not to mention non x86 archs).

Also AFAIK the Fedora bootloader people do not want to muck with EFI
vars too much, because some implementations are buggy they "fragment"
their internal storage when changing vars to a different size value
and then do nasty stuff (crash) when they run out of storage instead
of just returning an error.

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

Actually the grubenv and grub.cfg are not protected in anyway ATM,
which is an area where out secureboot story needs to improve. But since
the kernel cmdline typically includes a root= argument which may well
be a UUID or something else system specific, if we start signing these
files we need a way to locally sign them and which point we can also
update the keymap settings on the kernel cmdline.

TL;DR: I believe that passing the keymap for the initrd on the kernel
cmdline is the best option.


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

See above for the secureboot part of your question. Yes
vconsole.default_keymap= would work, but I would prefer
rd.vconsole.keymap also for it being backward compat with older
(pre systemd in initrd) initrds.

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

Ok, so we need to find a way around that :)

Regards,

Hans