First boot of the Deck UI hanged on "Update complete, launching Steam..."
Hello! A few weeks ago I installed Bazzite on a desktop PC. I went with the
bazzite-deck-stable image, version 41.20250106.2. After going through the installer (and a secure boot MOK enrollment), I got a bunch of progress bars. However, after waiting through them all, the animation just froze and it has been sitting like this ever since*
Well, almost. Turns out it's only Steam that hanged (or maybe some other thing inside gamescope). After a while systemd normally suspends the machine. But also switching VTs works so I can just log in on a second one and get a shell.
I am sure that simply rebooting will make the problem go away. But while it is in this state, is there anything I can check to figure out why it's frozen?
* Yes. I was busy with other things and totally not putting this off. I swear.
34 Replies
that image you showed is 100% steam, if rebooting doesnt get you into gamemode then go into TTY and run
steamos-session-select desktop and then open the terminal there and run ujust fix-reset-steam
you need the desktop for that command as it will reinstall steam and remove the broken files and try save as much userdata as possible (like game saves, game installs, etc)There's no user data as this is a fresh install
im just explaining the command
Ah alright
since we tell people to run it when steam is having weird issues and they go "but what about my games" and such 😛
but yeah run the ujust command i gave from the desktop and login to steam when it appears again
once logged in, try returning to gamemode and see if it behaves
sadly we cant auto fix steam crapping itself at random on first boot :clueless:
good thing it doesnt happen very often
Thanks for the tips! For now I am trying to figure out the root cause, but once I do (or when I give up) they will definitely be helpful.
I'm currently looking through the logs.
journalctl shows a lot of warnings and errors but so far nothing seems related.
It's nice that even the progress metrics from Steam are logged tho!my guess the root cause is steam just crapped itself during its own install/update process and need to be reinstalled
also any warnings/errors about extest can be ignored
those are normal, its just complaining that the process isnt 32bit/64bit native and you will always get one or the other error
It seems to be just the UI that broke and the rest of Steam is alive in the background. I've just found logs of it downloading a new update today.
do you have more than 1 screen?
what hardware
@HikariKnight Do you know which process specifically is responsible for that image I sent?
yes, its called
steamIt's just this one monitor (connected via DP to AMD RX 550). The CPU is Intel.
try add this to
~/.config/environment.d/10-gamescope-session.conf
and reboot
if that does not help idk, will have to dig up my rx 570 test card or ask @Valerie to nicely to test
I can test my 580 tomorrow
polaris cards has been rough in the past but the issue was fixed, so might be a regression
but then you got a black screen and the whole system froze when it was polaris that had issues
Thanks for all the help offered, but maybe I haven't expressed myself clearly enough. I don't want to needlessly waste your time on this, so let me say that a bit more bluntly:
I expect this is an ephemeral problem that will go away after a reboot. But I still want to investigate it a bit in case it can be fixed easily. If you have ideas, do share them. But do not waste your time trying to troubleshoot it remotely! It is not worth it.
thing is that there are only 3 things that it can be
* steam crapping itself
* gamescope regression (would affect more people with the same hardware)
* amdgpu driver issue (would affect more people with the same hardware)
and if its a regression you can just
brh rebase stable-41.20241104 to go back to an older image (i choose this one because its around the time i still used my polaris card so i know it will work for polaris cards) and then just stay there until we figure out where the regression is and report it to the right place and wait for upstream to fixI mainly expect the first, so my plan is to stare at the logs a little more, maybe take a crashdump of the sus processes, or simply go on "a killing spree" to hopefully see which part of that tree above was responsible. After that I'll try out your suggestions that involve reboots to rule out or confirm the other two options.
also that image i used as a rebase example, is the oldest one in the archive atm so it will be the next one to be pruned, you can use
brh list to see all image updates for the last 90 ish daysIs
graphical.target relevant for the Deck UI or gamescope?
Because it's only being reached once bazzite-flatpak-manager.service finishes, and that triggers bazzite-tdpfix.service which in turn seems to make one of the earlier warnings (about sudo refusing to let tee write into /sys/**/hwmon1/power{1,2}_cap) finally go away.bazzite-tdpfix.service fixes steam locking random gpus to 15W tdp
and it doesnt even use tee
steam however will be spamming 15W with tee to the power cap if it is allowed to
the tdpfix stops that on affected hardware
graphical.target means that whatever service requires the graphics to load first
Yes. When steam is not busy with downloading its updates, there are a lot of failed attempts to use sudo ("$USER : a password is required ; PWD=/var/home/$USER/.local/share/Steam ; USER=root ; COMMAND=/use/bin/tee /sys/class/hwmon1/power?_cap"). They stop once the
bazzite-flatpak-manager service is done and graphical.target is reached. So maybe that fixup should be applied earlier in the boot processcant do it earlier
it is as early as it can be without bricking your system
Or maybe not. It seems there are more of those messages from sudo later on…
Does it depend on Flatpaks being up to date? Because that is the only thing that holds up the
graphical target.
Yeah yeah. I know. I was asking whether gamescope or the deck UI care about itwhichever of those 2 run first does not matter
cant run without graphical target being reached. and graphical target is reached otherwise you wouldnt see the steam logo
but have you run what we recommended at least?
That's not the case at all. Gamescope (and all the progress bars from Steam) show up way before it is reached. If that's not how it's supposed to go, then the unit files need to be fixed
.
^
then i will come back when that has been done
Can you recommend someone who knows the Bazzite-specific intricacies of the boot process?
we will not go on a wild goose chase until you do what we recommended you that has solved similar issues 100% of the time in the past when it has not been an upstream regression
or rather, "can explain" them
I'm asking questions to learn how the boot process + launching steam is supposed to go. I've been quite explicit that I'm not trying to "make the problem go away" and that I do not expect you to troubleshoot anything here. It would indeed be a wild goose chase as you said.
But I am asking technical questions in the hope that someone who knows how this is all supposed to work can help me understand the parts that differ compared to a traditional Linux OS. While this particular case is most likely just a bug in Steam (I now found a crash dump from around the time it hanged), I want to fix other problems I'm encountering.
The difference is how we make and deliver the OS (you see this on GitHub)
oh and /usr is read only
That's the tldr
The boot process is still the same, systemd starts services and oneshot scripts and the display manager (login manager) handles starting the session and you're now booted
That last part is 100% the same as almost all other Linux systems
Also the crash dump from steam is useless to us, we don't make steam
Well, from what I can see in
systemctl status's output (at least for the -deck images) SDDM just autologins you into a shell script. The rest is a bespoke setup to make gamescope and Steam behave.
(Tho now that I know where it lives, I can just read the code and find out what it does directly so that's good.)
Yeah. But it is a good piece of evidence for who the culprit is. And maybe I'll report it to Valve since there appears to be a support link embedded in it.