BYeah I’ve been reading the links. Kind of a nasty bugger
KYup
BMore than an important feature, it seems, if one does a rollback with the new version, they get stuck and can’t roll forward
KThey have to switch to their other deployment
KTo get unstuck
KAnd could end up in a position of not having one
KSo yes, very important we fix this now
KI'd just grab fedora's OSTree spec and build it in copr with this patch added and a .ublue added to the version string
BI don’t see how they can even switch back. “Rpm-ostree subcommands” all fail
KFrom grub works
KOnly thing that does
BBut they can’t delete the good deployment
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.
