RAnd a fork is preferred over pinning to an old version?
KRight, instead of downgrading which may cause other problems, we rebuild what we have today plus one patch
BCould you file an issue or PR and ask us to look at it?
KAnd then end that as soon as it's fixed
KYep
KIssue that started this here:
KGitHub
Describe the bug Rebased to an older image to try to troubleshoot a black screen issue by using older NVIDIA drivers. Then could no longer run any rpm-ostree commands due to daemon refusing to star...
KGitHub
Describe the bug I rebase f40 silverblue-testing and went back to stable or f41 rpm-ostree is giving errors in rpm-ostreed Reproduction steps Rebase to f40-stable or f41 reboot run a command like r...
BIn the past we have definitely pinned an older version for stuff like this.
So its my first go to unless it really can’t work
So its my first go to unless it really can’t work
KGitHub
Older versions of rpm-ostree bail if this isn't found. In practice we may as well keep this until the end of time...
Closes: #5048
Closes: #5048
K8 lines
K4 of which are comment lol
KDowngrading rpm-ostree could break things worse @bsherman
KThe whole problem is older OSTree dies if this field is missing
KAnd for anyone up to date the field is missing
KWould be a one way trip to bricksville
KOtherwise I'd suggest the same
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
