On Tue, Sep 20, 2022 at 03:05:17PM +0200, Gerd Hoffmann wrote: > On Fri, Sep 02, 2022 at 12:07:38PM +0100, Daniel P. Berrangé wrote: > > On Fri, Sep 02, 2022 at 11:21:03AM +0200, Gerd Hoffmann wrote: > > > Hi, > > > > > > > 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'. > > > > FYI, I filed an RFE with systemd to get their opinion on the idea > > of alternative cmdline entries, and/or validated option lists: > > > > https://github.com/systemd/systemd/issues/24539 > > So, how move forward with this best? Drop the verbose variant for now, > add support for that once systemd-stub support for multiple command > lines is sorted upstream? > > Should we have a Fedora feature page for unified kernel support? I'm not sure we especially want to publicise unified kernel images as a standalone thing to users, as it is more of just a building block. If we're going to show any "feature", I think it probably ought to be oriented around a higher level user solution, of which unified kernel images are just one piece of the puzzle. eg I would see "Trusted boot for cloud images" as a feature, by which I mean publishing cloud images capable of using SecureBoot and vTPM, to do attestable boot on UEFI, without the unsigned initrd hole present as today. So, this would mean uing unified kernel images, either directly launched from shim, or with sd-boot in there to provide a UI selection. Either way not grub, since it is impractical to do attestation with grub's use of PCRs. Also likely mean use of discoverable partitions. I know there's been some desire to move Fedora cloud images to be UEFI only, so it might dovetail with that to some degree. It would likely touch kernel, anaconda, systemd and cloud images, so there's some coordination & discussion needed to agree on the big picture. 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
