On Thu, Dec 22, 2022 at 12:42:38PM -0600, Dennis Gilmore wrote: > On Thu, Dec 22, 2022 at 5:25 AM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > > On Wed, Dec 21, 2022 at 11:56:32AM -0600, Dennis Gilmore via devel wrote: > > > In my case, I have Network Manager config files included in my initrd > > > and bootargs to bring up the network so that I get automatic disk > > > decryption while on my home network, and prompted for a password when > > > I am not at home. I think this a reasonable enough use case it should > > > be considered in the long term plan. There was an effort many years > > > ago that built the initramfs with the kernel, it was abandoned due to > > > not being able to guarantee sources for the binaries in the initramfs, > > > > If a UKI is built in koji, the initrd it embeds must also be built in koji. And > > when the initrd is built in koji, it is just taking some binaries from rpms and > > repacking them. We ensure that we have an srpm for any official srpm. Thus, going > > back from the UKI, you look up the initrd, and the logs for the initrd build, > > and get a list of rpms, and then look the appropriate srpms from that, and from > > the srpms you get the sources. There's a few more steps, but the availability of > > sources is guaranteed using the mechanism existing for normal rpms. > > In the past that was deemed to not be good enough. by legal as it is > too hard for the average user to do. Sorry, but that doesn't make any sense. Quoting Daniel Berrange from the other part of the thread: > This is the same situation we already have in Fedora with > libguestfs, where we're building a disk image inside Koji bundling > various binaries. Or for that matter, not really different from > building cloud disk images, or any other deliverable that bundles > together some binaries from other RPMs and spits out some kind of > image or archive. My understanding is that if any of those other things (including any of our installation media that also contain an kernel and programs in the initrd) are fine, UKIs must be fine too. > > > trying to dig up the details I am having trouble finding it, but legal > > > blocked it there is a reference to it in an old FESCo meeting > > > https://lists.fedoraproject.org/pipermail/devel/2013-February/178220.html. > > > Additionally, we should also consider > > > https://fedoraproject.org/wiki/Features/DracutHostOnly and the size > > > implications and why we moved to have kernel-core, kernel-modules, and > > > kernel-modules-extra for cloud and different use cases. > > > > Yes. That's why this proposal explicitly targets a narrow use case which doesn't > > need many drivers and will support many different machines with the same > > (relatively small) initrd. > > I think the proposal needs to be explicit in how other use cases and > all architectures will be handled. I think if we do not have a path > for all architectures to be supported we should spend more time > working out how to cover them all. Different architectures have different boot loaders. In particular, s390x and ppc64el are very different. The proposal is to add support for UKIs in grub2, so that we will cover UEFI and non-UEFI machines that use grub2. For other architectures, we can in principle do the same thing… After all, the UKI is just a binary with a few sections appended. But it seems to early to think such details far ahead. As extensively discussed, the support for separate initrds is not going anyway and the proposal only targets a small subset of the amd64 space. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
