Incidentally if anyone reading is a moderator for this mailing list, the message Gerd is replying to appears still pending in the moderation queue as the list didn't allow non-members to post... On Fri, Sep 02, 2022 at 10:40:41AM +0100, Daniel P. Berrangé wrote: > 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 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
