Hi,
On 29-09-2019 12:08, Lennart Poettering wrote:
On Fr, 27.09.19 16:00, Hans de Goede (hdegoede@xxxxxxxxxx) 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
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
