Hi,
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initr...
we tried to make rh image builder people inetreested in that, but they weren't interested in that at all.
For initrd building or for cloud image building?
I don't think mkosi is a hard requirement for unified kernel images though.
No, it's not. mkosi is just a python script gluing all the dnf, gpt, fdisk, verity, signing stuff together. You can reimplement that.
Once the local configuration issues are solved it should be possible to run "dracut --no-hostonly" in koji + ship results instead of doing it on the installed host, no?
We want to build initrds from RPM, to make the reasonably reproducible and follow proper deps. It's a major facet of the project. magic build scripts trying to magically determine deps from ELF and config and whatnot is kind what we want to get away from.
Sure, that totally makes sense longer-term.
But I'm also trying to figure how far we can get without putting the initrd build process upside-down. Something along the lines of an (for starters optional) kernel-initrd subpackage with a "dracut --no-hostonly" generated initrd in it. When that is present on the installed system just use it instead of running dracut to build one.
But why not just fix the cloud images to just use descriptive type uuids? that has no drawbacks, just benefits.
Yea, need to figure how to do that. I guess step #1 is getting anaconda or blivet or whatever other tool anaconda uses for partitioning fixed. And I also guess it'll take a while given we have a 7 year old bug asking for that ...
take care, Gerd