-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automotive Stream Distribution builds failing #4879
Comments
It would be nice if we could add:
to either ostree/rpm-ostree upstream CI. Or as just part of the CentOS Stream 9 release process. We get breakages from time to time because we do some things differently to other CentOS Stream 9 based OSes. The cs9-ridesx4-minimal-ostree.aarch64.aboot.simg image is of greatest value, that has the most differences, but the x86 one is useful because it's easier to find x86 machines. |
The sample-images just needs /dev/kvm right? Sounds automatable via Prow/Jenkins easily enough. Onto the problem. One thing I do notice is:
And yeah...definitely want to flip on I'm a bit confused as I don't think there were relevant changes in rpm-ostree here - there definitely were changes on the build side but I don't see anything obvious. I'm not totally remembering here what the logic in |
Sample images unfortunately by default needs full root. But, if you feed it with a small vm it can do eveything using qemu, and /dev/kvm should be enough then. |
Getting a different problem if I change to Gonna bite that bullet and switch to |
Another osbuild failure we are seeing: cs9-qemu-minimal-ostree.aarch64.qcow21710863931.txt
|
Also, this seems to be a new path:
|
@Yarboa would you have cycles to do some CI work here?
we basically want to start Building AutoSD images in here with the rpm-ostree rpm from the given build. |
It seems like the movement of the:
code triggered this.
in a healthy flow org.osbuild.ostree.commit looks like above. But in an unhealthy flow, the recompiling selinux, dracut flow, etc. is re-executed, even though that was already run by the preptree stage. @jlebon what do you think is the best fix here? Moving the:
code back I'm pretty sure just fixes this, but I guess it was moved for a reason. |
@ericcurtin let me see if i understand, |
@Yarboa yes it would involve:
It's to achieve greater stability in our builds and catch these things earlier. |
@ericcurtin Packit can build the rpm and test will install it into AutoSD build, later build it. |
@Yarboa the rpm-ostree rpm needs to be part of the osbuild of AutoSD before you even boot AutoSD: sudo sample-images/auto-image-builder.sh aka installing in a booted system won't be enough. |
I got that, for sure, it is part of building
So in containerized build, rpm local install or packit repo enable for rpm-ostree Note: for packit: |
So, I took a look at this, and indeed, the problematic commit is 3fc7c23, and it has two main issues: First of all, it moves the generation of the tmpfiles.d dropin from the post-process phase to the install phase. However, the way osbuild uses rpm-ostree, the install phase is not used. What ostree does is use its support for image creation, which installs the rpms and whatnot. And then it runs So, when the tmpfile was moved to install, that never gets created when building ostree images using osbuild. Secondly, when running This eventually ends with the failure:
Which I guess is a general problem stemming from trying to post-process twice. |
@cgwalters Yes, sorry. Also this seems to affect regular osbuild users too: https://issues.redhat.com/browse/RHEL-29559 |
This reverts commit e1e78cf. It breaks idempotency with osbuild. Closes: coreos#4879
OK I put up a revert at #4881 |
BTW if I was in charge, one could just "git revert" the landing of the rpm-ostree build into c9s entirely and that would just work. Or really of course, any change into any package. Being able to do that is definitely part of an image-based centric mindset. But we can't do that because rpm... |
I do think one cs9 based build and osbuild run prevents this from happening in future. Maybe that's AutoSD or something else. It means another re-build of the code to make a cs9 rpm and a quick osbuild run... It's probably another 15 minutes added to the build, but I think it's worth it. I think it's really neat for development that rpm-ostree and libostree stay close to upstream on CentOS Stream and I want that to continue (image-based things should be closer to upstream IMO). But one CI build might be nice. |
ostree/rpm-ostree stability hasn't been great for AutoSD in 2024, it's not anyone's fault, it's due to the success of this area, new changes are coming in frequently. |
This reverts commit e1e78cf. It breaks idempotency with osbuild. Closes: coreos#4879
To get the fix for coreos/rpm-ostree#4879
Describe the bug
Automotive Stream Distribution fails to build since recent changes to ostree/rpm-ostree:
From @juanje:
works: rpm-ostree-2024.3-1
doesn't work: rpm-ostree-2024.4-2
well, the one that works is: ostree-2024.4-3
And the one in the image that doesn't work is: ostree-2024.5-2
Reproduction steps
Expected behavior
cs9-qemu-minimal-ostree.x86_64.qcow2 artefact should build without issue
Actual behavior
We see this, linked issue ostreedev/ostree#3217:
System details
rpm-ostree-2024.4-2
Additional information
No response
The text was updated successfully, but these errors were encountered: