Bazzite Blank Screen with cursor
Hello, few days ago i installed Bazzite on my Lenovo Legion Go S and it's doing fine and all that.
But suddenly yesterday i got an issue where it just showed me a Blank Screen after powering on the system.
I try go to TTS and restared and it's all working fine, and i thought that was it.
Then this morning i boot into Windows (since its a dual boot) for playing some games on gamepass and then reboot into Bazzite, but then it showed the same problem as yesterday.
Can someone help me what to do? i was thinking of deleting my windows partition and only using Bazzite but at this point i'm rethinking about it with this issue if it's keep showing up
134 Replies
Steam gets stuck updating sometimes
Just wait a bit
ah i see, thank you
For me when steam updates in game mode there's no more progress screen. I'm 99.99% sure there's a regression on Steam's end.
There's been more bugs with steam, including the first time setup screen in game mode being glitchy AF
so not unusual to happen
ah i see, so it was normal?
yes, its just steam things
How long did you have to wait on this black screen before the update finished?
If its longer than 5 minutes try rebooting
Ctrl+Alt+F3
Then login and reboot
If you're on a handheld there's a force reboot button
Look in the docs
Got disabled by default in some
Due to conflicting bindjngs
Oh my bad. I know on LGO it works
If it doesnt work youll either have to risk hard reset or plug in a keyboard
It's unfortunate
I had to do it once after SDDM enabled itself randomly on my lgo after an update and I was away from home
So its useful
I have an rog ally, so if I plug in a keyboard and hit CTRL+ALT+F3 then it should reboot? Sorry I’m a noob
No, it will take you to terminal mode
At which you can login and then type
systemctl reboot
If that doesn’t work you can do the same and then type startplasma-wayland (on KDE)
Will take you to desktop mode
See if steam starts at all
For GNOME you just type gnome-sessionThanks for the tips, I’ll try this!
Oh i forgot after you start KDE or GNOME you'll have to go back to one of the TTY sessions until you find the desktop mode session.
Just try Ctrl+Alt+F1 through F3
I’m not quite sure what you mean 🧐
TTY3 (Ctrl+Alt+F3) is a terminal session. When you start up desktop mode using a command (e.g. startplasma-wayland or gnome-session) youll have to back to a graphical mode.
f2 should be desktop
Ok gotcha, thanks 🙏
So when I tried to run startplasma-wayland I got the error “Could not start D-Bus. Can you call qdbus?” Then running systemctl reboot gave me the error “Call to Reboot failed: Interactive authentication required.”
sudo systemctl reboot
also sudo startplasma-wayland i guess?
weird how i don't need to do sudo for either
🤔
if that doesn't work. something else is wrong with your install
journalctl -b | fpasteDo you want to look at the link created?
‘Sudo systemctl reboot’ succefully rebooted my device, still doesn’t load Bazzite. ‘Sudo startplasma-wayland still gives me the same error
https://paste.centos.org/view/2f4c522d
your issue with steam is easy
your decky loader ain't working properly
you need to reinstall it
in terminal type
ujust setup-decky and uninstall it
then rebootIs there anything I need to do to uninstall it from the terminal, or just reboot after running ‘ujust setup-decky’?
it will show a menu
there u can remove it iirc
then reboot
This is all I see when I run the command
So I tried sudo ujust setup-decky, and I don’t see a drop drown menu but I see this
oh right
cuz no graphical mode
Try
startplasma-wayland againStill getting that “could not start d-bus” error :/
Facing the same issue
@antheas he has selinux issue
i think his install is f'd
look in his journald
https://paste.centos.org/view/2f4c522d
what does
rpm-ostree status saySending my logs right now
Where
explains why plasma won't start right
Looks like css loader died to me
he can't even start his DE
I tried to go back to ostree 1, and I can open my Steam library but I have no sound and none of my games load. It’s version 41.20250203
d-bus error
i've never seen the selinux error before though
with bootc systemd generator?
oh maybe it is css_loader
also css_loader
but he can't run the ujust because he can't start plasma and the ujust relies on qt
😐
wait a moment maybe there's another way to uninstall
curl -L https://github.com/SteamDeckHomebrew/decky-installer/releases/latest/download/uninstall.sh | sh
try thisLooks like Decky may have been removed…I’ll try startplasma…
reboot first
game mode should work again now
Fat finger sorry
What does that have to do with plasma
nah it was unrelated sorry
however it is somewhat annoying that setup-decky ujust requires a graphical mode
especially if that is the exact tool that could break game mode entirely
Sadly does not seem to work for me 😢 gamemode still broken and plasma doesn't start
Same here :/
journalctl -b | fpasteGamemode as gone from black to blinking -
ujust fix-reset-steam
try this toohttps://paste.centos.org/view/b4b6cc8b
Still black screen with - after the command and a reboot
"SELinux is preventing ostree from write access on the directory /sysroot/ostree/repo/objects" 🤔
did you touch your SELinux in any way?
Nope doing that enough at work to not wanna bother with it on my personal 😂 just applied the latest update like 2h ago
I'm not super used to atomic distro tbh just using it as a set it and forget it
can you type
rpm-ostree status ?
and post output here?As a Picture sure
because i feel like if ostree is getting SELinux errors something is going to be said there
what device?
both of you?
Rog Ally X
and you @Aessem ?
Z1e
have you both tried
ujust fix-reset-steam already?
and then rebooting?Yup on my side
Yes
can you both do
rpm-ostree rollback
and then rebootSudo?
not needed
normally
Wasn't allowed without it
I see hope
latest update just cursed on rog ally for some reason
Yeahhh happens
i wonder what
journalctl -b | fpaste
shows after rollback
if it still gives all the SELinux errorsIt's alive
Sending you the log
Hallelujah
it still has all the ostree selinux thing but oh well it works
Would it be fine to install decky again?
probably
just use the ujust
Yup worked no issue on my side
@CheckYourFax thanks for the help
Sweet, thanks for all the help! The community is great!
No problem 🙂
I would wait for another stable update before updating again
if it again doesn't work, you can do a rollback again
Yeah gonna wait for a few days
Wanna play expédition 33 without having my os break 😂
mine works
dammit
beside all the new selinux things (probably composefs bs right?) i don't see anything else strange
but it seems like gpu driver just dips it in latest stable on ally
?
can't even start the DE
Thanks the „sudo rpm-ostree rollback“ has worked on my Ally
Does it work for you?
No idea im on testing I'll revert to stable see if it bugs out on my lgo
What if its the gamescope patch?
We also bumped gamescope
If I had to bet I'd say it's gamescope
Wait no because then KDE would boot up fine
This looks like the cached config issue
The other user couldn't even run startplasma-wayland
Steam or gamescope remembers like an edid and dies
So something else is fd
That's not just game mode That's f'd right
But maybe gamescope causes something else to crash
It seems to be exclusively ally so my guess would be hhd
:clueless:
Why are you using that command
bazzite-session-select plasmaNot me
It always worked fine for me, but I didn't know that command existed 🥲
At least on my lgo
It must be some issue on the ally. Maybe there's been a kernel patch for ally?
The only thing in gamescope that I can find is this
Looks harmless
Maybe it clashes with the vporch patch you did?
My ally uses that
But indeed that could break allies with that panel
Maybe
Break as in the transition needs gamescope to reset
im having the same just now, ally x
Logs This Boot: https://paste.centos.org/view/cb1c070c
Logs Last Boot: https://paste.centos.org/view/374aa208
did rpm-ostree rollback, then diffed logs from this boot and last boot, last boot being the borked black screen one:
after running ujust update from ssh after the rollback, I now have display again:
bazzite@bazzite:~$ ujust get-logs
Logs This Boot: https://paste.centos.org/view/ad236dae
Logs Last Boot: https://paste.centos.org/view/30330f98
bazzite@bazzite:~$ rpm-ostree status
State: idle
Deployments:
● ostree-unverified-registry:ghcr.io/ublue-os/bazzite-deck:stable
Digest: sha256:bd13f05f33bd1003b37ff5f3d34e031f99f28f31be1324c44e415f4556b6b45b
Version: 42.20250425 (2025-04-25T16:42:58Z)
ostree-unverified-registry:ghcr.io/ublue-os/bazzite-deck:stable
Digest: sha256:453e03103d7a36bbc673eec203ef131b9fdaf50a29d3f90e908f94865d248606
Version: 42.20250417 (2025-04-17T07:41:02Z)
bazzite@bazzite:~$
heres filtered down to diffs between up to date image above's logs and logs from two boots ago, which would be I believe same version 425 but with the borked black screen:
also, again apologies if this is a lot of noise, but when in game mode and clicking check for update (which would hook ujust update or in previous builds ublue update) I see something interesting with SElinux?
Ignore that
You need to remove the times first
I just got home and am looking through them now see if there's anything interesting.
The se linux stuff is nothing its just a thing that happened after 42
Here's where it fails
So the problem is for you also specifically on latest stable, and not on earlier builds right @Cilantro Limewire ?
Nothing makes sense because on the other people's logs there isn't even an attempt at starting gamescope-session
On all the logs where there's just a blank screen, user-runtime-dir gets an exit code 1
that's all i can find
Looks like big fat SELinux failure to me? Gotta get some dinner now. Cheers.
yeah trying to upgrade via steam button to latest stable from 42.20250417
why, just noisy?
They're fixing it
your diff will still be the whole log if you have timestamps
😅
well when i got the issue few days ago, i just go ctrl alt f3, login and then ctrl alt f1
few second later it booted the steam logo
don't know how or why
hey not sure if this is the right place but does anyone know if there are issues with the lastest bazite 42 update on rog ally x my ally x just gets stuck on a black blank screen on boot after updating.
Oh duh
In that case was updating from stable deck 417 to 425 via steam update button shortcut in game mode, but after rollback and ‘ujust update’ in ssh it got to 425 without issue
running into this as well. Looks like a few people are booting into black screen on handhelds on version 42.20250425. My Desktop boots fine on that version though but ally does not. This thread (https://discord.com/channels/1072614816579063828/1367155818910453932/1367155818910453932) looks related. Wondering if the issue is with gamescope as my desktop image which lacks gamescope runs just fine.
Yeah had to switch to ostree 1 to boot back into the OS holding out on updating until it’s fixed. Although I’m noticing it boots significantly slower now as well after the 41 rollback.
Strange. Since the image is exactly the same
Maybe something is screwed up in /boot during the transaction in uupd
Uupd is the one responsible now for updates in gaming mode
Wait, bootc is the preferred method in uupd
In ujust update its always rpm-ostree
But that should still do the exact same thing.
Yeah idk what's going on :dispair:
Im going to try something
By reverting to 0417 and then using hhd (bootc) to update to 0425 my LGO breaks entirely.
And then using hhd to update
My entire os is broken now lmao
Not even tty works
LGO has same issue with regards to updating through bootc instead of rpm-ostree:
When I rollback to 0417 and then use rpm-ostree to rebase back to stable (0425) the issue is gone.
Same behavior as @Cilantro Limewire
Seems to be bootc vs rpm-ostree update
Is the cause of this issue fixed @antheas ? Maybe its from migration of ublue update to uupd? I would make sure before doing a new stable build that updating with bootc works correctly.
Its not hard to reproduce
Hhd and uupd have the same issue
Yeah
We can't fix the past
Also, rechunk was bumped
But I think only in testjng
We can use the previous version if it broke
Well 0417 is still on ublue update
It gets removed on 0425
Maybe that's related
But hhd has the same issue which makes me believe its just bootc causing the issue, but that's strange as the update logic shouldn't be different from rpm-ostree
I notice that user-runtime-dir throws errors at boot when you trigger the bug
And then everything after that fails too due to dependencies failing
Maybe its ublue-update getting removed for uupd that's doing something sus
Rpm ostree uses an IPC protocol
And gets launched with the correct selinux policy
That's the difference
Well the main one
That would maybe explain the SElinux execute error on the runtime dir
Maybe it would be best to change uupd to use rpm-ostree even if no progress bar, for now at least
I feel like this issue is 99% upstream stuff
And uupd/hhd is just a side effect
Its also untestable because setenforce=0 is ignored since F42
Yes bootc does a check
Then a workaround that fails
maybe this needs to be forwarded to the bootc project
yes
but we cant even repro
because they havent fixed the f41 rollback bug
the blank screen can be repro'd by rolling back to 0417 and then updating to 0425 with hhd
even on lgo
both are 42
it reproduces the execute error on user-runtime-dir
you would expect "its an image, how can it be different" but SELinux is not
It seems like incredibly vague issues are 99% of the time caused by SELinux :true:
I'm going to try to rollback, and then do
(bootc:7186): GLib-CRITICAL : 20:13:03.121: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.130: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.143: g_atomic_ref_count_dec: assertion 'old_value > 0' failed ⠒ Deploying
(bootc:7186): GLib-CRITICAL : 20:13:03.410: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.411: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.411: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.414: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.425: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.426: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.429: g_atomic_ref_count_dec: assertion 'old_value > 0' failed Deploying: done (23 seconds) Queued for next boot: ghcr.io/ublue-os/bazzite-deck:stable Version: 42.20250425 Digest: sha256:bd13f05f33bd1003b37ff5f3d34e031f99f28f31be1324c44e415f4556b6b45b is this normal?
bootc update from desktop. if that also fucks up my system its 100% that
Are these errors normal when doing bootc switch ghcr.io/ublue-os/bazzite-deck:stable
bazzite@fedora:~$ sudo bootc switch ghcr.io/ublue-os/bazzite-deck:stable
No changes in ghcr.io/ublue-os/bazzite-deck:stable => sha256:bd13f05f33bd1003b37ff5f3d34e031f99f28f31be1324c44e415f4556b6b45b
⠂ Deploying(bootc:7186): GLib-CRITICAL : 20:13:03.121: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.130: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.143: g_atomic_ref_count_dec: assertion 'old_value > 0' failed ⠒ Deploying
(bootc:7186): GLib-CRITICAL : 20:13:03.410: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.411: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.411: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.414: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.425: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.426: g_atomic_ref_count_dec: assertion 'old_value > 0' failed (bootc:7186): GLib-CRITICAL : 20:13:03.429: g_atomic_ref_count_dec: assertion 'old_value > 0' failed Deploying: done (23 seconds) Queued for next boot: ghcr.io/ublue-os/bazzite-deck:stable Version: 42.20250425 Digest: sha256:bd13f05f33bd1003b37ff5f3d34e031f99f28f31be1324c44e415f4556b6b45b is this normal?
They're normal it's an issue since last summer
I opened an issue for that
lets see if it boots normally
yeah just doing
bootc switch works fine
from 0417 to 0425
Reproduced it again updating through hhd
I'm at a loss
I can reproduce it with hhd but not with bootc switch
¯\_(ツ)_/¯when you use bootc directly selinux is correct
Testing is building with a fix to hhd
If that fixes it for hhd after a test, uupd should get a similar fix
as that is also affected
I copied the uupd fix
Both of them are fixed
Okay, nice