As far as a workflow for custom bootc images I really like what is being done in HeliumOS as my background is kickstart/ansible.
The desire is to learn the build infrastructure and to navigate it. The Konflux factory seems the one to learn now.
1 Like
I’m not entirely sure, but it might be here:
I haven’t tried any Base Container Image profiles, but recently built the Cloud-Base-Generic with some modifications needed for thesting a package.
I noticed that Rawhide :: Fedora Docs describes the automated compose process, which produces all deliverables including container images.
Maybe there are more pointers / clues there too.
(post deleted by author)
I havent looked yet, but is this something the upstream bootc project may have documented?
(post deleted by author)
no i mean the upstream bootc CNCF project. bootc is intended to be distro agnostic… its just starting with rpm based distros on its journey. The project became a CNCF project in like January.. so if there are builder bootstrap docs. i would expect it to be there.
The link is to an upstream issue.
So far everything in that upstream cncf bootc project show how to build using pre-existing ‘builder’ image.
Section 8.4 of the Red Hat documentation has an example Containerfile for building from scratch. Hopefully this helps:
The rhel from scratch documentation is the best I’ve found. But there they use a pre-existing ‘builder’ image as well.
Oops sorry, I missed that.
That’s definitely something within scope for the upstream project to provide. They’ll definitely have to document that once they have the bits in place to break the hard dep on rpm and new, different users of the tech trying to onboard.
in the meantime, if I were gonna do it for myself.. I’d start with buildah from an entirely empty container and bootstrap my first builder container that way.
Yes, I will continue learning buildah.
So Fedora doc Build a Container with Buildah also starts with a pre-existing container
buildah from fedora
Can you point me to the code used to generate that existing fedora container? Maybe it is somewhere in that kiwi reference @hricky supplied but I have not been able to unravel it yet. It would be great if buildah was used and I could learn more quickly how to do the same.
I can’t point to the existing code yet either.
But this maybe sort of a bootstrapping thing like with GCC. We build new gcc with old gcc right? So it’s conceivable we’ve that sort of phase now where the bootstrapping was a one time thing that isn’t in the infra as a process any longer.
Thank you for the quick reference. I guess anything can be wrapped up in the oci.
The LFS bootstrapping of gcc is a great example. That is the logic I am trying to unravel except for bootc images.
With mkosi-initrd and mkosi in general I see there is a rather direct way to go from a pile of packages to a bootable container. Though if I could understand how Fedora does it that would be helpful. As you say it may just be water under the bridge though.
The from scratch process is well within scope for what the upstream bootc project wants to accomplish if they want to on board other linux distributions that use different packaging models. So that’s were I would nudge for some documentation on bootstrapping that builder image.
The work is definitely in scope for this:
Upstream Issue: Demonstrate a debian or arch base image
As far as I know, we still need RPM packages to build an initial container image.
I could try manually building one of the Base Container images using fedora-kiwi-descriptions, uploading it to a container registry, and then trying to build a bootc image from scratch using that container image. If that would be useful, I could try it and if it works, provide the steps for the process.
Thanks for the offer.
Looking at container.xml for instance, I can see profiles and preferences that show what would be included in the fedora-init, fedora-minimal, fedora-toolbox etc. images. But I do not see the steps taken to produce the image from the chosen set of packages.
If you could manually build one and capture all the log messages, maybe even debug messages, that may illuminate what is happening.
There also is no mention of iot, coreos or bootc so I guess those are built differently.
You can probably learn a lot from looking at the logs from one of the container builds in fedora’s koji.
koji has a KiwiBuild task with several output logs.
The mock_output.log has what I expect is the expected kiwi-ng build call.
Since the builds are done in mock you should be able to do an equivalent local build if you get mock setup on your system.