In your action, are you using the build of ostree in the image or are you using your own?
In 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
B@Kyle Gospo i see you built main:40
I'm building hwe:40 now
I'm building hwe:40 now
B@j0rge i can rebuild bluefin's latests if you want after hwe is ready
Kwas running tests
Kchanges look good to me in a vm
Kso, all clear to rebuild the world
Bawesome news
Bhwe is green
Bi'm rebuilding bluefin/aurora latest
Bwe should probably consider rebuilding stable also, as I think it is also has the bad version of
rpm-ostreei've confirmed that bluefin/arurora stable do need the rebuild, so kicking that off
Ris this a downgrade or a commit on top of 2024.7?
Kon top
