On Fri, Sep 02, 2022 at 11:21:03AM +0200, Gerd Hoffmann wrote:
Hi,
> > (3) Support /boot being vfat (depending on #2, sd-boot needs this).
>
> Technically in the cloud image scenario we don't need to especially
> care about /boot being a dedicated partition. We could do everything
> exclusively in the /boot/efi partition which is already vfat, and not
> bother creating any /boot partition, since we can ensure /boot/efi is
> large enough.
>
> If we forsee the unified EFI kenrels being useful for bare metal,
> however, then use of /boot as vfat becomes more important, as we
> can't assume the hardware vendor's pre-created /boot/efi is
> sufficiently large.
Didn't want to open that discussion right now. My impression is that
Gedora & RHEL settled on the approach to have both /boot and /boot/efi
everywhere because some cases require this and having only a single
scheme simplifies development + testing.
Changing this looks not that easy to me, we have RPMs dropping files
into /boot/efi/EFI and I suspect this is hard-wired in various places
in anaconda and elsewhere.
Hmm, yes, it is not worth trying to track down all those places.
So, yes, for cloud images we don't really need this as we can
make the
ESP as large as we want, but I have my doubts that deriving from the
standard way fedora handles things gives us enough benefits to be worth
the trouble.
Agreed, removing the restrictions preventing vfat on /boot are
likely the least effort change.
> Thus my patch proposed two images, to be distributed in the
same
> 'kernel-virt-unified' sub-RPM.
>
> * vmlinuz-virt.efi created using dracut arg
>
> --kernel-cmdline 'console=ttyS0 console=tty0 quiet rhgb'
>
> * vmlinuz-virt-verbose.efi created using dracut arg
>
> --kernel-cmdline 'console=ttyS0 console=tty0'
Hmm, I think we should look for a more elegant solution to this problem
than having two large, 99% identical images.
One option could be to have systemd-stub support multiple .cmdline
sections and allowing the user to pick one of them.
Hmm, interesting idea. That would be attractive because all the
different .cmdline variants would be trivially covered by the
SecureBoot signature still. Would need enhancement in the
bootloader(s) supporting unified image.
Another option could be to have a whitelist of options the user is
allowed to add/remove which then could include stuff like 'console='
and 'quiet'.
The most flexible as it avoids need to predict what users might
like to use, and also avoids the combinatorial expansion problem
from embedding multiple .cmdline, which becomes more important
as the set of safe-to-use options becomes larger. Would need the
bootloader to enforce this, if we're to avoid having to attest
the cmdline specifically after boot.
Still I like the multiple .cmdline sections as it lets the bootload
give a simple menu choice without needing more interactive editting.
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|