Bug 2203221 - mkosi-initrd
Summary: mkosi-initrd
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: Changes Tracking
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Zbigniew Jędrzejewski-Szmek
QA Contact:
URL:
Whiteboard:
Depends On: 2189633
Blocks: F41Changes
TreeView+ depends on / blocked
 
Reported: 2023-05-11 14:42 UTC by Aoife Moloney
Modified: 2024-03-12 22:49 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Aoife Moloney 2023-05-11 14:42:37 UTC
This is a tracking bug for Change: mkosi-initrd
For more details, see: https://fedoraproject.org/wiki/Changes/mkosi-initrd

mkosi-initrd is an alternative builder for initrds. It will be packaged in Fedora, so that users can use it to build initrds locally. A kernel-install plugin will be provided to build the initrd when a kernel package is installed. As a stretch goal, initrds will be build in koji and delivered via rpm packages. As a further stretch goal, pre-built initrds will be used in Unified Kernel Images that can be delivered via rpm packages.

Comment 1 Zbigniew Jędrzejewski-Szmek 2023-08-16 14:11:36 UTC
The work on this was blocked. There's still some chance it'll be done for F39, but a postponement to F40 is likely at this point.

Comment 2 Adam Williamson 2023-08-22 23:10:52 UTC
We are now past beta freeze, at which point this should have been 100% complete. Should we just go ahead and defer it to F40 now?

Comment 3 Zbigniew Jędrzejewski-Szmek 2023-08-23 06:22:50 UTC
Yep.

Comment 4 Aoife Moloney 2024-02-19 18:11:55 UTC
Hi Zybzsek,

How is this work progressing for F40? Is this still on track to land? Any status updates you have would be most welcome :)


Thanks!
Aoife

Comment 5 Zbigniew Jędrzejewski-Szmek 2024-02-19 22:30:57 UTC
We might just as well bump it to F41. Stuff is happening, but it's not ready for prime time yet.

Comment 6 nilskemail 2024-03-03 17:17:20 UTC
I see that the change lists the stretch goal of building initrds in koji. How would one determine the packages and more importantly kernel modules which should be included in such a universal initrd? For example Canonical's initrd snap seems to just have a bunch of modules listed without any insights why those are selected: https://github.com/snapcore/core-initrd/blob/main/modules/main/extra-modules.conf

Also see the discussion in the mkosi repo: https://github.com/systemd/mkosi/discussions/2403

Comment 7 Zbigniew Jędrzejewski-Szmek 2024-03-03 19:43:27 UTC
> How would one determine the packages and more importantly kernel modules which should be included in such a universal initrd?

Generally, we'd have a list of hardware that is supposed to work with the default initrd,
and a set of storage types, file systems, and other features that are supposed to work.
Together, this pretty much directly determines which top-level modules and packages
are needed. The rest is pulled in through dependencies.

Comment 8 nilskemail 2024-03-06 01:17:25 UTC
> Generally, we'd have a list of hardware that is supposed to work with the default initrd

Does such a list already exist (and if yes, where)?

We am currently looking to obtain such a list because we ship (Fedora-based, mkosi-generated) images to customers with pre-compiled UKIs but they are supposed to run on any machine. Therefore we have no fixed hardware which we can target and including any possible driver results in huge UKIs

Comment 9 Zbigniew Jędrzejewski-Szmek 2024-03-06 10:12:57 UTC
No, no such list exists, since we (Fedora) do not ship pre-built images, except for virt.
When we add actual pre-built initrds, then we'd have to make such decisions.

https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 added UKIs for virt,
and it has the description that it's for virtual machines only. I guess the description
could/should be more explicit. The %description for kernel-uki-virt.x86_64.rpm is currently
just '%{summary}.' one-liner.


Note You need to log in before you can comment on or make changes to this bug.