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. 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. > 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. 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'. take care, Gerd _______________________________________________ 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
