Hi,
On 30-09-2019 13:23, Hans de Goede wrote:
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.
While discussing this with Alberto an interesting problem came up.
If we put this file in /boot/loader as you suggest, then the boot-loader
can get to it and use it to set its keymap (and in the future probably also
other stuff) but how does the localed in the initrd get to this file?
I agree with you that having a generic mechanism to share config
between the OS and early-boot (so bootloader + initrd) is useful,
but are we then going to make the initrd mount /boot (or the ESP) ?
One wild idea I had is to have the bootloader generate an initrd
on the fly with just the file in there named as say /bootloader-config
and then have the bootloader pass that dynamic initrd as extra initrd
to the kernel. This assumes that for TPM stuff the bootloader is the one
doing the initrd measurement and that it then will NOT measure this
extra initrd.
This to me seems the best way to keep this flexible and avoids the
pitfalls of having to mount /boot in the initrd, which I'm sure is
going to break for some crazy setups (like encrypted /boot which is
unlocked from within grub).
This will require modifying the bootloaders we care about to do this,
but that is doable.
Regards,
Hans
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
