KSo long as their newer image is still there
KYep
Bbootc work for a switch?
KIf they have no layers
KCan't remove them if they do
AGitHub
In certain hardware surveys (e.g., Steam), in order for a distribution to be accounted for the PRETTY_NAME os-release variable is used.
Currently, this name plays a dual role in ostree, where it is...
Currently, this name plays a dual role in ostree, where it is...
Aguess youre forking rpm-ostree though
Await
Ado i need to fix this?
Aim using ostree without adding any metadata
Aseems like its a server side issue, how would forking ostree fix that?
KIn your action, are you using the build of ostree in the image or are you using your own?
KIf you're using your own you just need to add this patch to it or use the one we eventually build in copr
KIf it's the one in the image you're good as soon as we fix it in main
AI'm not using rpm ostree
AAt all
KBelieve you're good then
AYou sent a PR for rpm ostrew
AWell if the commit needs metadata I need to add them to the action
KThat metadata existed prior and you passed it through without issue
KOtherwise this would have been broken sooner
KThe fix OSTree side is to make that data even if it has no contents
KSo nothing explodes
AI remove all rpm ostree metadaya
Byou are talking about rechunked images ?
AYeah
AIf it needs to be added we can add it asap
Bi don't believe the container native image metadata is an issue... the concern is when rpm-ostree fails to write specific metadata to on-disk ostree deployment.
KRight, that's what I was saying. If rechunker was involved it would have been broken like this immediately
KBelieve you're good
Awhy did it break now
Brpm-ostree change
KUpstream
KNew version stopped making this metadata
KPatch starts again, but empty
KProblem solved
Bi've made this exact mistake... write tool that expects certain data, later remove the need for data so don't write it, realize in a panic after deploying that some users must use the older version which expects the data... chaos ensues
B@antheas since you are around... I wondered if you had any thoughts on this
https://github.com/ublue-os/ucore/issues/189
I want to get some more detail from @M2 ... eg a build log, but maybe you'll look at the issue and have some helpful thoughts without more logs.
https://github.com/ublue-os/ucore/issues/189
I want to get some more detail from @M2 ... eg a build log, but maybe you'll look at the issue and have some helpful thoughts without more logs.
Ai dont remember but i want to say unrelated
Bso it's "official" thank you for further discussion ... after that and reading the related links, i think it's clear any user rolling back will probably send a complaint/request for help... i'm not so sure they will be able to brick, unless they dive deep with
I'd prefer to let upstream fix it, Colin definitely seems to be moving quick, but it may be worth an interim patched rpm-ostree (as you propose), to avoid users hassle.
ostreerpm-ostreeI'd prefer to let upstream fix it, Colin definitely seems to be moving quick, but it may be worth an interim patched rpm-ostree (as you propose), to avoid users hassle.
Aso this issue is caused
Aby updating with a new version of rpm-ostree to an old one?
KYep
KIf you're current and roll back for some reason, rpm-ostree will fail to run on the rolled back build
Agreat, yeah that isnt a rechunk error
Bso @Kyle Gospo I probably would be lazy and upstream fix, but if you have the energy and time to fix, I support the interim patch. Just want the chance to review of course.
KGitHub
Upstream issue: coreos/rpm-ostree#5048
Upstream MR: coreos/rpm-ostree#5069
Package source: https://github.com/ublue-os/packages/tree/main/staging/rpm-ostree
Also sneaks in a quick fix for some whit...
Upstream MR: coreos/rpm-ostree#5069
Package source: https://github.com/ublue-os/packages/tree/main/staging/rpm-ostree
Also sneaks in a quick fix for some whit...
Badded a comment, ... the rpm-ostree.spec file doesn't quite match upstream
Kreplied
Bapproved
