distro: move rpm based bootc anaconda-iso generation into the images library #2010
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mvo5
force-pushed
the
bootc-anaconda-iso-2
branch
3 times, most recently
from
1e85415 to
c02ed88
Compare
supakeen
reviewed
Nov 17, 2025
| # - its "indirect" in the sense that it pulls the RPMs from a | ||
| # "real" distro, i.e. if a bootc centos-10 is found it will | ||
| # load the imagetypes.yaml for that to load the | ||
| # bootc-rpm-installer |
Member
There was a problem hiding this comment.
This is a very important comment ❤️.
| if err := cnt.InitDNF(); err != nil { | ||
| // Not all bootc container have dnf, so check if it can | ||
| // be run here and if not just return nil which will | ||
| // ensure the depsolver of the host is used |
Member
There was a problem hiding this comment.
Not all hosts have DNF either, do we need to verify that as well?
Contributor
Author
There was a problem hiding this comment.
If dnf is missing on the host images should already DTRT, i.e. if its not needed (like for pure bootc types) it will just continue and for rpm based ones it will print an error.
| rng := rand.New(rand.NewSource(seed)) | ||
|
|
||
| switch { | ||
| // XXX: make this a yaml property |
Member
There was a problem hiding this comment.
Follow-up or will you update this PR?
Contributor
Author
There was a problem hiding this comment.
I have not fully made up my mind yet, followup might be nice but maybe its enough to update the comment, given that its extremely unlikely that we ever add another legacy rpm based rpm installer we might keep hardcoding it. But making it YAML is slightly nicer (but maybe extra work)
achilleas-k
reviewed
Nov 17, 2025
mvo5
added a commit
to mvo5/images
that referenced
this pull request
Nov 18, 2025
This commit tries to address the concern from Achilleas in osbuild#2010 (comment) When using a custom Depsolve function it is now mandatory to pass a valid `depsolvednf.Solver` instance. So the custom depsolve function will no longer create it on its own as this is no longer feasiable. With the bootc distro that requires a different depsolvednf.Solver it is no longer something that a user can override. The commit also renames the function from Depsolver to Depsolve as its doing the (dep) solving with an existing "solver". Getting the terminology more disentangled would be nice but I couldn't come up with better terms, maybe `DepsolveRun` ?
achilleas-k
previously approved these changes
Nov 18, 2025
The bootc based distros need a custom depsolver because they need to use the dnf from the container to ensure that all the plugins/custom config is used. So manifestgen now checks if the distro defines its own way to create a depsovler and if so passes it into the manifestgen.Depsolver. With that bootc ISOs (that require rpms) are compatible with custom depsolve helpers and we can use a custom depsolver to catpure the mTLS keys for the rpms that are required by bootc.
This commit moves the code to generate the rpm anaconda-iso installer type into the images library. This is possible because we use the distro specific depsolver. In bib we need to define a custom depsolver function that wraps the `manifestgen.DefaultDepsolver()` so that we can captures the repositories and extract the mTLS keys from there. The image type is ugly as it violates our layering, i.e. it will first inspect the bootc container to find the distro id and then look into our "regular" imagetypes.yaml for the found distro for the rpms to install. This is convenient as we maintain our rpms all in the same place but its also annyoing. Ideally we would get rid of this image type and use the container based bootc-installer type [0] but we will probably need this RPM one for a while still. [0] osbuild#1906
Ideally we would just use `name_aliases` but in the bib/ibcli code we use the low-level interface of the loader to get the image which does not look at name_alises. As this is quite a special case lets just be pragmatic and define "iso" via a YAML alias/anchor.
Not all bootc container have dnf, so check if it can be run here and if not just return nil which will ensure the depsolver of the host is used.
Now that the `anaconda-iso` image type for bootc is part of the image library we can (re)use the existing manifest testing system to generate fake manifests that validate that our images do not change accidentially. This commit adds: rhel-10.1, centos-9, fedora-43, fedora-42 which should be a good sample.
mvo5
added a commit
to mvo5/images
that referenced
this pull request
Nov 18, 2025
This commit tries to address the concern from Achilleas in osbuild#2010 (comment) When using a custom Depsolve function it is now mandatory to pass a valid `depsolvednf.Solver` instance. So the custom depsolve function will no longer create it on its own as this is no longer feasiable. With the bootc distro that requires a different depsolvednf.Solver it is no longer something that a user can override. The commit also renames the function from Depsolver to Depsolve as its doing the (dep) solving with an existing "solver". Getting the terminology more disentangled would be nice but I couldn't come up with better terms, maybe `DepsolveRun` ?
mvo5
force-pushed
the
bootc-anaconda-iso-2
branch
from
9a7af45 to
c1ce9a0
Compare
Contributor
Author
|
Had to force push because of conflicts, sorry. |
achilleas-k
previously approved these changes
Nov 18, 2025
Member
|
Linties |
This commit tries to address the concern from Achilleas in osbuild#2010 (comment) When using a custom Depsolve function it is now mandatory to pass a valid `depsolvednf.Solver` instance. So the custom depsolve function will no longer create it on its own as this is no longer feasiable. With the bootc distro that requires a different depsolvednf.Solver it is no longer something that a user can override. The commit also renames the function from Depsolver to Depsolve as its doing the (dep) solving with an existing "solver". Getting the terminology more disentangled would be nice but I couldn't come up with better terms, maybe `DepsolveRun` ?
mvo5
force-pushed
the
bootc-anaconda-iso-2
branch
from
c1ce9a0 to
6ba8221
Compare
achilleas-k
approved these changes
Nov 18, 2025
supakeen
approved these changes
Nov 18, 2025
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR moves all the logic for anaconda-iso bootc ISO generation into the images library and extends manifestgen.Depsolve() so that we can pass a custom depsolver (which is needed for the bootc anaconda isos as they use a custom solver that point to the mounted container)
This is working end-to-end in osbuild/bootc-image-builder#1131 - all existing tests pass (might be good to do a manual test with a rhel container on a rhel system, this part is not well tested).