[systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?

[Hans de Goede]

Hi,

On 29-09-2019 12:08, Lennart Poettering wrote:
> On Fr, 27.09.19 16:00, Hans de Goede (hdegoede at redhat.com) wrote:

<snip discussussion about if fulldisk encryption / non-EFI should
  be supported at all>

> Anyway, even if you insist that the Fedora desktop should care about
> non-EFI, which I can accept, isn't the lesson to learn to add some
> concept like EFI vars to those archs too? i.e. apparently OSes and
> boot loaders want to communicate, so why not make that happen on those
> archs too? I mean, the concept of EFI vars is simple and semantically
> it's not even essential to have NVRAM to store them in — a fact to
> which the EFI firmware typically used by qemu/kvm is document, as it
> actually stores those EFI vars in the ESP, so that they are included
> in the VM image.

So what you are arguing for is replacing the overlay initramfs
with a key-value config file which gets used by both the bootloader
and the OS.

That is an interesting concept, esp. since it limits (as you advocate)
what can be done in the overlay from "everything" to "set specific
config variables to a value".

So yes I can get behind this.

> i.e maybe write down a spec, that declares how to store settings
> shared between host OS, boot loader and early-boot kernel environment
> on systems that have no EFI NVRAM, and then we can make use of
> that. i.e. come up with semantics inspired by the boot loader spec for
> finding the boot partition to use, then define a couple of files in
> there for these params.
> 
> In fact, sd-boot nowadays stores the boot-time random seed it manages
> to initialize the kernel's entropy pool with in
> $BOOT/loader/random-seed. It would only be natural to build on that,
> and introduce $BOOT/loader/kbdmap and so on.
> 
> i.e. generating initrd images with cpio and so on is hacky, gluey,
> Linux-specific. If you just use plain simple, standardized config
> files at clearly defined locations, then reading and writing them is
> simple, they can be shared between all players, are not Linux specific
> and so on. I think systemd could certainly commit to updating those
> files then.

This sounds interesting, although I'm not sure I like the one file
per setting approach why not have a $BOOT/loader/config file which
has key=value pairs and kbdmap would be a key in that file?

> 
> Putting together such a spec isn't difficult even. Could be as short
> as:
> 
>          "This spec builds on the boot loader spec. The keyboard map is
>          stored in $BOOT/loader/kbdmap, using ISO-3166-1 alpha-2
>          country codes. We suggest boot loaders use this for their own
>          key maps, and pass it to the OS, for example via the kernel
>          command line."

I'm afraid that will not work, some countries have multiple variants,
we actually have a bunch of Fedora bugs open about the disk unlock
support in plymouth and the "de-neo" keymap and there also are the
somewhat popular dvorak variants.

So we could do this as say a base setting but then we would need to add
a kbdmap_variant setting which when sets makes the keymap loaded
$kbdmap-$variant.map (in Linux Console terms) I guess we could specify
that setting a variant this way is allowed, but that variant settings
are OS / bootloader specific and may be ignored?

Regards,

Hans