Closed cgwalters closed 6 months ago
This is claimed to be a recent regression (rotating tags would help prove/disprove).
What's really weird is that so far I can't reproduce this with bootc switch
from a running host, or even directly doing an ostree container deploy
. It somehow only reproduces in bib so far which is really weird because it should literally be doing the same thing.
I’m struggling to understand something. If I reference by digest a centos bootc image from a week ago, that worked at that time, why shouldn’t it work today? is there something during the build process that gets downloaded on the go and pulling the latest?
Let's say my Containerfile is now:
FROM quay.io/centos-bootc/centos-bootc:stream9-1709003520
ADD etc etc
RUN dnf install -y flightctl-agent && \
systemctl enable flightctl-agent.service
That digest is from 3 days ago. Podman build works, but BIB disk creation doesn't with the same failure.
It's definitely possible that if you're using a new bib image that that is somehow involved in the failure.
Also
stream9-1709003520
Oh wow, I had no idea this existed, it must be something that the tekton release flow is doing automagically? Will comment over in https://github.com/CentOS/centos-bootc/issues/189
BIB latest image is from 7 days ago, and this was working 3 days ago...
After a bunch of debugging, https://github.com/ostreedev/ostree-rs-ext/pull/605 pointed out that the problem is that osbuild is not creating a /var/tmp
in its bwrap stages.
Closing in favor of https://github.com/osbuild/bootc-image-builder/issues/223
@oglok for my own sanity...did you end up rebuilding that image with podman? I no longer reproduce the failure.
@oglok for my own sanity...did you end up rebuilding that image with podman? I no longer reproduce the failure.
Yes, it works now @cgwalters Thanks a lot!
Deploying quay.io/flightctl/flightctl-agent-centos:bootstrap with bib fails like this:
At first, I thought this was another echo of https://github.com/coreos/rpm-ostree/issues/3827#issuecomment-1307942893 :arrow_right: https://github.com/ostreedev/ostree-rs-ext/pull/400/commits/883a79e4d32b1ca6673a1589a3337ee7ea7663ac
Digging into the relevant layer, it's the one corresponding to this run invocation:
Digging in a bit...the first thing I notice here is that building that with podman here works fine. And yes...it looks like that same issue, because in the remotely built image we have:
But I thought we'd fixed this one....ah yes, in https://github.com/ostreedev/ostree-rs-ext/commit/43e1648e97ef82f2cb86fd0813a5f338585eea97 and also in https://github.com/ostreedev/ostree-rs-ext/pull/558