System updates are not installed in game mode
System update does not work with Steam. When I click "install" button, the computer thinks for a couple of seconds and then offers to reboot the system. After rebooting nothing happens and Steam again offers to install the update. The system update shortcut in desktop mode works fine.
specs:
7900xtx
7800x3d
asrock b650 pro rs
DDR5 6400MHz, 32Gb
Dual Boot
nvme ssd (windows on sata ssd)
fast boot (both): disable
78 Replies
try log into desktop mode, open the terminal and run
brh list to list all the available images of bazzite then run rpm-ostree status and check what image you are on. If you on an older release type ujust update and hopefully you'll be able to see why your system isn't updating
Latest version is stable-41.20250301 and can see in your screenshot that you are on that version. You are fully up to date
Thank you for the obvious information. Updating via Steam how do I fix it? It is not very convenient to go to the desktop every time
Difficult to tell, the steam update and the desktop update run the same mechanism undernearth. Is it still showing an update in steam even though you are up to date? If not see if the issue occurs again
the updater in steam will also show up when there is a steam update
and all the updater in steam does is run a script and expects specific return values
if valve changes that they dont inform anyone and we will have to just adapt to that.
thats why we say use the updater in desktop if you want actual information about what is being done if the one in steam is misbehaving
I encountered this a day or so ago as well. Going into desktop and running
ujust update resolved the phantom update issue in game modeHow then do you like the idea of writing a simple extension for the loader deck, the whole point of which is to be exactly the same system update shortcut that is present in desktop mode and which displays a terminal area with exactly the same output of all the information that is output to the terminal when updating from desktop mode?
personally, i ideally want to avoid decky loader being a requirement since its prone to breaking not just itself but also steam as a whole from experience, in such a way you get stuck in gamemode and gamescope freezes and you dont get to go to a tty, very fun to help people with that one when it happens 🙃
I've put all sorts of shit from it, but I've never had it hang so badly.
i have had to help a handful of people with this in the past. i like decky and all and i use it, i just dont want it to be a requirement for bazzite
So don't make it mandatory. I'm not suggesting to remove the shortcut from the desktop mode, but to add one additional shortcut directly to the game mode, so that the user has a choice not to switch to the desktop every time to update the system. There's another update out today. Because of a measly 1 GB, I had to go to the desktop.
if you can trigger the issue consistently, try debug
steamos-update thats the script run by steam
i cant trigger it consistently so i cant debug
you would run this while gamemode is running so best would be to test over tty
and i think it runs in sudo context but dont quote me on that as there are a bunch of polkit rules involved for gamemodeI ran that, and I got the following error:
Error: [Errno 2] No such file or directory
did you run it with gamemode running in a different tty?
because i think that error is from it looking for hhd.steamos or something
I ssh'd into my deck while it's in gamemode
even better
so it's an expected error?
unsure
think its either @Kyle Gospo or @antheas that might have added that portion, most likely kyle
trying to track down the repo for that file
my steam updater works
So what could the issue be ? any way to get a clearer log?
bash -x /usr/bin/steamos-update see where in the bash script the error is generatedalright, one sec
you have layered lack so hhd will not work
lact
okay, after looking into the
.steamos-update.logfile, this was inside:
hmm if i didnt have to be pinned to 6.12 atm
my main system might be affected
ran,
systemctl status ublue-update-force.service
wait
is it trying to run dnf upgrade
why would it be doing that ?
shouldn't it use rpm-ostree upgrade
or update*
yep, dnf goes to a "no bad, we removed this footgun for your safety" script :clueless:
dnf used to just be an alias for rpm-ostree, so if that exact script used to work before, it wouldn't today
exactly
So who do I point my pitchfork towards?
ok so you blew up the updater
not me lmao
you know we got a guy today that installed using a march 2024 iso
like man dont mess with the updater
I installed it like a month ago using the latest available image on the website
not your fault
now we will have a second generation of stuck people
fix it now
the updater shouldnt point to dnf to begin with so this is a bug on that end
@Kyle Gospo
push on prod moment
and that has been there 2 weeks now and affects all htpcs
I didn't touch the updater wym
Literally updated my HTPC last night
no issues
why is it calling dnf and dying
it's the same hhd or ublue-update
updater seems to try run
/usr/bin/dnf upgrade for some people though 🤔no clue why, that's not a change we made
let's find out
so if you have layered packages its dying now?
I have layered packages
at least if users have layered packages they can figure it out
ima shitpost the docker post anyway
have you updated it since then?
I haven't layered any packages
of course
can you run
rpm-ostree status?yes, one sec
does bazzite still use a modified ublue-update? i vaguely remember you mentioning that somewhere to me
yes, and it hasn't been touched in months
however if you have no layers
it uses HHD
which calls bootc
htpc
no hhd
does HHD the service need to be enabled for the update part to work?
where is the repo for it, i have some time before bed so i can look at least
HHD is still present
yes
regardless
it's my namespace atm
again, untouched
i made it so it fallbacks without hhd
would it make sense to uncouple the updater from the service
or enable the service everywhere?
service still needs a bit of work to be enabled anywhere
lets do that work soon
the updater cant work without it
because its bound to the GUI
you dont need me to do
bootc update anyway
you can even port the 10 lines of code that receive the progress, its not that hard
perhaps you should wait until we fix it to work with the latest bootcYeah let's do that
Anyway whatever is going on here I'm quite curious, I have been testing the living shit out of the framework desktop and I have had no failed updates
And that is across every update we pushed in the last couple months
same, my htpc is fine and my legion go ran into this once yesterday
both on the same image
Well, I am glad to help out and this is quite a fresh image that I installed, and haven't done any fuckery with my system, or layered anything, so how can I help any further?
i dont count my main pc since thats a custom image anyway
we'll dig into the behavior of ublue-update a bit and get back to you
something sus here
alright, is there anything else I can do on my end or should do or is this enough?
I only use bazzite for my deck, for my other devices I run bluefin, so this is a new issue for me
kyle will most likely ping if he needs more info, at least we have tracked it down to some weirdness in ublue-update
alright, thank you for being so kindly helpful 🙂 I'll be in touch then.
The command was run in game mode in tty2
we found a possible culprit earlier thanks to IAMTHELAW
Mar 03 21:27:23 fedora sudo[5015]: root : PWD=/ ; USER=root ; COMMAND=/usr/bin/dnf upgrade
ublue-update for some reason tries to run dnf upgrade on some systems
and since dnf was replaced with a "no bad, read documentation" script, this obviously will failShould I just wait for one of the next system updates or is there any way to fix this myself?
ublue-update is in /usr so you will have to wait.
i think the current priority for kyle atm is prepping for SCALE
we are considering replacing ublue-update with uupd as thats finished i believe now, means kyle doesnt have to maintain a custom version anymore.
Solution
Okay, then we wait.
essentially when dnf5 landed in upstream, the rpm-ostree cliwrap got deprecated meaning that
dnf no longer linked to rpm-ostree it instead linked to dnf5 which cannot do layering yet
so we replaced dnf with a script that tells people "dont do this, read our documentation" and for some reason ublue-update decided that dnf is the right thing to run for updates instead of rpm-ostree which worked before because of rpm-ostree cliwrap
essentially its a chain of events that exposed a potential issue in ublue-update that has not been spotted before