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 :| _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
