Closed cgwalters closed 7 months ago
OK, now this blocks on https://gitlab.com/redhat/centos-stream/rpms/ostree/-/merge_requests/34
And now it blocks on a development compose being spun, which I think is hopefully tomorrow
This will work on top of https://github.com/CentOS/centos-bootc/pull/381
So I belatedly noticed (realized) that this breaks upgrades from existing images deployed that weren't using composefs. Not for any deep technical reasons...it wouldn't be a hard fix, but it's also a fix that we'd have to ship first.
Not totally sure about blocking on it; hopefully we can get by with just a one time pain.
You can work around this by running
ostree config set ex-integrity.composefs true
(per this doc)
on your running system, or doing it from a container build via a one-off systemd unit or equivalent.
This can be done reliably by ensuring your derived container pulls an older tag (e.g. quay.io/centos-bootc/centos-bootc:stream9-1709308978
), adding the systemd unit, then upgrading to it, then later switching your container build back to the main floating stream9 tag.
I was wrong above, I apparently had some local pilot error, upgrades work just fine.
c9s: Pull in latest bootc/ostree
On general principle, but specifically to enable transient root.
Enable transient (composefs) root (again)
This reverts commit 7977ead6e48c89706021aa1c867b5d3757ebeac6 and effectively migrates the change from https://github.com/CentOS/centos-bootc-dev/pull/27/commits/8f5be0937144b602d8c1fdcaff4c51777b8cb254 to here.
See the linked PR for much more debate, but in a nutshell this flips around a lot of tradeoffs around the filesystem layout and will result in a much more easily explained state that is intended to somewhat more closely match what happens with a default
podman run --rm
invocation of the container.Signed-off-by: Colin Walters walters@verbum.org