Possibly this is worthwhile a ujust script to disable the behaivour
Possibly this is worthwhile a ujust script to disable the behaivour
Ktotally open to that
AI still think it's broken tho - i've encountered far too many failure modes from it since it was introduced into steam (and nobara) earlier this year
Kthat feature should have been a part of SteamOS since launch
Kand Nobara since the handheld image was created
KBazzite-deck since day-0 as well
AAutomounts appeared sometime in the last 6 months
Anobara 38 and 39 through the first half of it's life were unaffected.
JYo, please move to #bazzite, this channel is for ublue development.
Mhttps://github.com/ublue-os/akmods/pull/234
This looks ready. The only failure is on coreos-testing which is attempting to build zfs on an unsupported kernel.
This looks ready. The only failure is on coreos-testing which is attempting to build zfs on an unsupported kernel.
BHmmm. 6.10.6 should be fine for zfs
BUgh no! At the last minute they didn’t validate zfs for 2.2.5! Bleh
KFYI it looks like we're going to need to ship a fork of OSTree for a minute
Awhy
KLatest one breaks rollbacks, just need to add a patch that'll be in the next version now
KAnd then remove the replacement once it's fixed upstream
Aadd another one
AGitHub
Operating system and container binary deployment and upgrades - GitHub - antheas/ostree at custom-bootloader-name
Athis one
BGitHub
As support for Linux 6.10 has not formally been added in zfs 2.2.5 (I understand it for stability reasons): Is it possible to release a new zfs version in a promptly manner? BTW: Is there any OpenZ...
BCould you clarify “we”? We talking bazzite or all ublue main based images?
KI would recommend this happen in main
KRollbacks are an important feature
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
