Re: [PATCH 0/3] pre-generated initrd and unified kernels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux