Abrand new exfat sd card
Kit's a SteamOS package but not handled by steam
Ka udev rule handles the mount
AI mainly dd stuff to sd cards so having it mounted is a problem
APlasma has an automount diaglog/action set in settings - but it's not honored with the current setup
KThis is the rule, could try tossing a blank one into /etc
Kwhich would kill the whole feature
Jcan ya'll move over to #bazzite?
AGot lost in some discussion on gta3
A
AYup that's the same culprit as on nobara39
AMy opinion is that it's a bug and should be implemented as a temporary rule ONLY when gamescope session is active
KWe also ship GNOME, and will ship others. So unless this feature is shared by all DEs it's not something we can apply selectively
KHave to maintain compatiibility w/ how SteamOS does things too for applications meant for that "platform"
AIt's only useful if you are in Steam gamemode
Aas mentioned it breaks DE automounting services
KOnly for SD cards, I can't break everything else to fix this single feature of KDE specifically
KIt's extremely useful on the desktop
ANot if you work with images it's not
AOr you don't want your filesystem mounted because you're trying to recover something
ADE's all handle this without actually mounting a partition and letting the user click on the partition first
AAs mentioned this only makes sense in steam gamemode where there isn't a UX element available to achieve the same thing
APossibly 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
