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. > > 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. > 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
