Fixes a bug in the prefill algorithm that caused some packages to not be allocated and a subsequent crash. In addition, makes it so if this happens again due to a different bug an error is emitted ...
Hi @Kyle Gospo, I don't understand this commit: https://github.com/ublue-os/bluefin/pull/1580. What is "undefined behavior"? Sorry to bother you, but that PR broke my custom build and I want to understand why it happend
Having /usr/etc merge into /etc wasn't documented, and wasn't designed to be used as we did. From what I understand, it was an internal functionality of rpm-ostree, meant to be used for non-OCI workflows and/or when layering locally.
It also started causing issues when we were rechunking our OCI images using the hhd-dev/rechunk action
writing to /usr/etc/ at build time is apparently undocumented and undefined behavior with rpm-ostree, and writing to /etc/ does the same thing, we at bluebuild wrote an announcement of this, but it's still unreleased, there's a couple things to do first: https://github.com/blue-build/website/pull/65/files
yes and no. Essentially the code was written assuming only /etc exists, which caused them to merge during deployment. This merge was a byproduct. If you look at the podman PR for bootc, it will try to move /etc to /usr/etc and fail because it exists. Therefore we slowly need to start migrating
however the keyword here is SLOWLY. I want to have full backward compatibility with original ublue images prior to this. This includes merging /usr/etc to /etc the exact same way rpm-ostree would
if ublue starts breaking downstream images because of this, imo you should consider reverting the PR and letting rechunk handle it until we can define a behavior for /usr/etc existing
I didn't mean to point blame towards the rechunk action. I just meant rechunk didn't expect this because it's not the way rpm-ostree expects, and therefore it didn't work immediately. This sparked the conversation about how we should be handling config files in the future.
Of course no offense. It is a bit of undefined behavior that you came to expect with your images. So lets keep it that way and move slowly instead. In my opinion
Lets use this issue to track quirks inherent to booting an OCI image. Hopefully, when this issue closes it will be possible for someone to boot an image made with FROM fedora:40 First lets begin wi...
we are not anywhere close to migrating to bootc under podman. Until then, both bootc and rpm-ostree will have the same behavior so you can still rely on it
And in that effort, I had ostree panic and not boot because both dirs existed, then had to merge them, then saw how rpm-ostree and ostree-rs-ext handled it etc.