On Wed, Sep 21, 2022 at 4:48 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > Hi, > > > > 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. > > Yes. Just the kernel package updates are not enough. The bare minimum > which I think makes sense as feature is: > > (1) adding the unified kernel sub-rpm discussed here, and > (2) bootloader support (be that sd-boot or grub or both), and > (3) kernel install script support (so 'dnf update' kernel updates work). > > With that in place it should be possible to install VMs using the > unified kernel sub-rpm and everything works as it did before, even when > it requires some hacks here and there, such as tagging partitions > manually or in kickstart %post for > https://systemd.io/DISCOVERABLE_PARTITIONS/ > > The above will already plug the initrd hole. >From a kernel standpoint, I am interested in this. We do need to ensure that we are doing it in a way that is easily extensible to not just cloud images in the future. > > 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. > > Yep, that all makes sense, but I'd tend to not add that as 'required' > to the feature page. My list of nice-to-have optional stuff: > > (4) attestable boot (i.e. no grub b/c PCR mess). > (5) provide pre-calculated PCRs (could be published as kernel-pcrs > sub-rpm). > (6) add discoverable partitions to anaconda (so we don't need %post > hacks). > (7) add discoverable partitions to image builder (and whatever else > generates cloud images). > (8) switch cloud images to unified kernels. > > I think I've seen fedora feature pages with optional sub-goals before, > even though I can't find one right now, so I think it should be possible > to handle things that way. > > > 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. > > Hack grub so it can pull out kernel + initrd out of a unified kernel > image and boot unified kernel images in bios mode that way should be > possible. Would allow to migrate cloud images to unified kernels without > requiring UEFI. > > > It would likely > > touch kernel, anaconda, systemd and cloud images, so there's some > > coordination & discussion needed to agree on the big picture. > > Sure. Having a feature page drawing that big picture would be helpful > for these discussions I think ... Definitely a system wide change. While there are some logistics to work out on the kernel side, most of the work is packaging. I would guess timelines will need to be defined by the teams where code is needed. Justin > 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 _______________________________________________ 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
