Skip to content

Conversation

@dustymabe
Copy link
Contributor

@dustymabe dustymabe commented Dec 4, 2025

We currently set the imgref to something we cannot use later with bootc
or rpm-ostree. This should fix the reference and allow bootc upgrade
to automatically work.

In service of the above goal, backport a few patches from osbuild upstream.

None

@dustymabe
Copy link
Contributor Author

Opening this PR to see if I can get some feedback on if it works or not.

Rather than write into container-storage and then export to an
oci-archive let's just go straight there.

Signed-off-by: Dusty Mabe <[email protected]>
@dustymabe dustymabe mentioned this pull request Dec 4, 2025
@dustymabe dustymabe force-pushed the dusty-set-imgref branch 2 times, most recently from 6a2b2f1 to 18ee4ee Compare December 4, 2025 17:15
We need to patch OSBuild with patches from upstream PR [1] to allow
us to set the imgref to the value we need and not have the image
building fail with an error.

[1] osbuild/osbuild#2270

Signed-off-by: Dusty Mabe <[email protected]>
We currently set the imgref to something we cannot use later with bootc
or rpm-ostree.  This should fix the reference and allow `bootc upgrade`
to automatically work.

Signed-off-by: Brent Baude <[email protected]>
@dustymabe
Copy link
Contributor Author

I'll mark this as ready for review once osbuild/osbuild#2270 merges

@baude
Copy link
Member

baude commented Dec 6, 2025

This dupes and extends #200 so i will close the previous PR as such.

@dustymabe
Copy link
Contributor Author

I'll mark this as ready for review once osbuild/osbuild#2270 merges

merged upstream!

Copy link
Member

@baude baude left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM ... at what point do you think we can stop patching? any chance there is backports going on or is it the next version.

@openshift-ci
Copy link

openshift-ci bot commented Dec 9, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: baude, dustymabe

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved label Dec 9, 2025
Comment on lines +9 to +11
echo "Patching OSBuild"
dnf install -y --quiet patch
patch_osbuild
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how urgent is this here?

I rather not see this merged until the fixes land properly in the main repos. Any runtime install like this is prone to introduce plenty of flakes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how urgent is this here?

That's a question for your team to answer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Luap99 this is holding up my work on updates

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you need this now sure, as long as we agree that we don't make the final 6.0 release with this I am good merging.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I absolutely agree with you. But I will leave the merge up to you.

@dustymabe
Copy link
Contributor Author

@baude
LGTM ... at what point do you think we can stop patching? any chance there is backports going on or is it the next version.

Probably mid-january. If you wanted to open a PR to backport the patch to current OSBuild RPM then maybe faster.

When the new version of OSBuild makes it to the repos this patch would start failing. That's your cue to drop the patching (can probably just revert the commit that introduced it).

@Luap99
Copy link
Member

Luap99 commented Dec 9, 2025

/lgtm

@openshift-merge-bot openshift-merge-bot bot merged commit 02518ff into containers:main Dec 9, 2025
12 checks passed
@Luap99
Copy link
Member

Luap99 commented Dec 9, 2025

This broke CI I believe, the publish task can no longer push the images to quay

https://cirrus-ci.com/task/4738727450247168

I guess the removal of podman save removes the actual image name from the archive so the load was unable to restart the name, does rpm-ostree compose build-chunked-oci add the name to the archive, maybe the name is a bit different now?

@dustymabe
Copy link
Contributor Author

This broke CI I believe, the publish task can no longer push the images to quay

https://cirrus-ci.com/task/4738727450247168

I guess the removal of podman save removes the actual image name from the archive so the load was unable to restart the name, does rpm-ostree compose build-chunked-oci add the name to the archive, maybe the name is a bit different now?

It has nothing to do with the archive I don't guess. The log you linked is trying to build a manifest from containers-storage. I didn't realize there was a later step that ran that leveraged the images from containers-storage. We can just revert 16ff701 then. Sorry about that.

@Luap99
Copy link
Member

Luap99 commented Dec 9, 2025

This broke CI I believe, the publish task can no longer push the images to quay
https://cirrus-ci.com/task/4738727450247168
I guess the removal of podman save removes the actual image name from the archive so the load was unable to restart the name, does rpm-ostree compose build-chunked-oci add the name to the archive, maybe the name is a bit different now?

It has nothing to do with the archive I don't guess. The log you linked is trying to build a manifest from containers-storage. I didn't realize there was a later step that ran that leveraged the images from containers-storage. We can just revert 16ff701 then. Sorry about that.

No it is not about the local storage, the build tasks uploads the oci archive and the the publish task downloads the archive and all the other artifacts of the build and loads the archive as image so we can add it to the manifest list and then push that to quay.io. My guess (untested) is that the archive creation does not add the image name metadata adn as such the load doesn't restore the name.

If the direct creation via rpm-ostree is faster I think we should keep that. Restoring the name is cheap and simple enough I assume, just an extra step after load.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants