Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

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

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux