main: use the images library for the disk manifest generation #1014
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
distro-bootc
branch
2 times, most recently
from
e7434ff to
4b728ee
Compare
mvo5
changed the title
Collaborator
Author
|
#1033 <- this needs to be ported before this can go in. |
This was referenced Aug 28, 2025
This comment was marked as outdated.
This comment was marked as outdated.
alexlarsson
added a commit
to alexlarsson/osbuild-images
that referenced
this pull request
Sep 2, 2025
This fixes two things: 1) If SetBuildContainer() is not called, buildImgRef is nil 2) If it is called, buildImgRef is properly set to the value passed. Without this, when using a build container, I got errors about a missing "target" pipeline when using osbuild/bootc-image-builder#1014
github-merge-queue bot
pushed a commit
to osbuild/images
that referenced
this pull request
Sep 3, 2025
This fixes two things: 1) If SetBuildContainer() is not called, buildImgRef is nil 2) If it is called, buildImgRef is properly set to the value passed. Without this, when using a build container, I got errors about a missing "target" pipeline when using osbuild/bootc-image-builder#1014
mvo5
force-pushed
the
distro-bootc
branch
2 times, most recently
from
f919e08 to
973f673
Compare
achilleas-k
previously approved these changes
Sep 10, 2025
Member
achilleas-k
left a comment
achilleas-k
left a comment
There was a problem hiding this comment.
Very nice. LGTM.
Let's get this rebased and merge it.
This commit removes most of the code that deals with generating the osbuild manifest and imports the new support for this from the images library instead. Only disk images are supported for now.
We decided to move away from the blueprint way to specify the partition tables for a bootc container and use the more descriptive `disk.yaml`. Adjust the test to check the same functionality (aboot.img writing) using the new mechanism. Thanks to Alex for the example disk.yaml.
The root user cannot be customized much with anaconda and with osbuild/images#1806 we got stricter about it. Unfortunately our own test manifest sets the root home for ISOs (because we need it for disks and use the same blueprint) and it panic()s now. Fix this by removing the problematic option for ISOs from the blueprint.
achilleas-k
approved these changes
Sep 10, 2025
mvo5
added a commit
to mvo5/images
that referenced
this pull request
Sep 22, 2025
We used `./tools/gen-bootc-diff` to ensure the manifest generation for disk based bootc images between the `images` library and the custom code in `bootc-image-builder` is identical. Now that bootc-image-builder is using the images library directly (c.f. osbuild/bootc-image-builder#1014) this test is a tautology and not useful anymore. If we move the rpm based bootc installer ISO generation into images we will need to revert this removal again. But its just a git revert away and there is no need to clutter the repo with this no-longer-needed script.
mvo5
added a commit
to mvo5/images
that referenced
this pull request
Sep 22, 2025
We used `./tools/gen-bootc-diff` to ensure the manifest generation for disk based bootc images between the `images` library and the custom code in `bootc-image-builder` is identical. Now that bootc-image-builder is using the images library directly (c.f. osbuild/bootc-image-builder#1014) this test is a tautology and not useful anymore. We test the bootc based manifests generation now in images via `./tests/bootc-fake-containers.yaml` and the manifests and diff show up with our regular `./tools/gen-manifest{,s}-{diff,checksums}` tooling. If we move the rpm based bootc installer ISO generation into images we will need to revert this removal again. But its just a git revert away and there is no need to clutter the repo with this no-longer-needed script.
github-merge-queue bot
pushed a commit
to osbuild/images
that referenced
this pull request
Sep 22, 2025
We used `./tools/gen-bootc-diff` to ensure the manifest generation for disk based bootc images between the `images` library and the custom code in `bootc-image-builder` is identical. Now that bootc-image-builder is using the images library directly (c.f. osbuild/bootc-image-builder#1014) this test is a tautology and not useful anymore. We test the bootc based manifests generation now in images via `./tests/bootc-fake-containers.yaml` and the manifests and diff show up with our regular `./tools/gen-manifest{,s}-{diff,checksums}` tooling. If we move the rpm based bootc installer ISO generation into images we will need to revert this removal again. But its just a git revert away and there is no need to clutter the repo with this no-longer-needed script.
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 uses osbuild/images#1736 to get all disk manifests build using the "images" library.
This is a simpler version of #1009 that does not rely on manifest diffs. We may go back to the manifest tests but for now functional tests are probably enough.