I made a post for it here #Gamescope frequently crashes on boot
I made a post for it here #Gamescope frequently crashes on boot
BYeah there's also this. https://github.com/ublue-os/bazzite/issues/771
Unfortunately until a dev can reproduce this issue themselves we may be a bit stuck.
Unfortunately until a dev can reproduce this issue themselves we may be a bit stuck.
GitHub
Describe the bug The system will boot into one of two states: Black screen with a single white "_" (underscore) character in the top left. Other TTYs cannot be accessed in this state -- a...
DI have logs in there
B@PipPaine @Alex&Indie did you find a workaround to your broken gamescope issue? Rollbacks, upgrades, rebasing to earlier versions that worked before I did
rpm-ostree upgrade all still have black screen gamescope on boot so I'm thinking it must be either something in the kernel, bios or home folder that has changed to cause it to persist throughout
Amy deck is on pause, i dont have time to deal with it, gonna make a fresh bazzite install in these days
BOkay thanks, I'm trying to avoid that myself. It's my main computer.
It does seem the "return to game mode" .desktop file does launch game mode successfully at least
It does seem the "return to game mode" .desktop file does launch game mode successfully at least
GFWIW, I had the exact same problem Geechan described after the most recent update, except unlike them, in my case running
cp /etc/skel/.bashrc ~/.bashrc fully fixed the issue, with MOTD showing up correctly. At least in my case, the issue was that ~/.bashrc just didn't exist at all - which is weird because prior to the update everything was working fine, which implies the file originally existed, so I'm not sure what could have caused it to disappear. Anyway, hope this info is of some use for debugging!
Dwhy would there need to be a fresh reinstall for an immutable os? I can see why you want ~/ to be refreshed but the core system is immutable
T@dnkmmr @Alex&Indie @BearFOX did you use the
ujust command that autostarts desktop mode as opposed to game mode in -deck images
Dwhat is the default?
Tboot into game mode on startup
Knot seeing any gamescope crashes in any of the logs I've been sent
Kand I'm unable to reproduce this on my LCD or OLED decks
KMay be a steam crash rather than gamescope
Dare you on gnome or kde. I am on kde
Kboth
Dyou checked the ones in #Gamescope frequently crashes on boot ?
Kyup
Kbasically nothing in those
Kthere's separate logs for steam and for the params it's launched with, 4 in total
Kwould help to have all 4
BOkay so I found that if I delete the gamescope folder in home/deck/.config then on next boot gamescope WILL load normally
BBut on next boot when that folder has been regenerated, it boots gamescope to black screen
BThat's consistent as I've checked three times over for each scenario where the folder is there / isn't
BI also see the steam runtime environment gets setup again if I had deleted the gamescope folder
Kwhen did this start? Last gamescope build was 15 days ago and it's the same version we built over 2 months ago
K3.13.19
BFor me it started when I updated to 23rd Feb build. But I'd been on a December or January build before that as I don't update if I have a active game I'm playing through
BIt doesn't seem to matter which build I'm on since then, as I'm currently rebased to Feb 5th
DCould it be possible to have a systemd service that will attempt to reload gamescope if it crashes?
KWould that not just be an infinite loop? It's a session
Kreally don't want to implement hacks like that, rather we found out what's affecting both of you
Dor display some sort of error or even give the user an option to boot to desktop?
KIt should boot to desktop assuming the session crashes, that's the behavior I get
Kso I'm doubly curious what's going on w/ your installs
DIDK. I don't have any layered packages installed
Bhere are all my logs from HOME. it includes the log.old files too as my last two boots were a successful gamescope boot and an unsuccessful black screen boot https://we.tl/t-LjH9ZEqvaV
9 files sent via WeTransfer, the simplest way to send your files around the world
Blet me know if you prefer me to send them another way
BOf those files, .log is the successful gamescope session, .log.old is the black screen gamescope
The
The
drm: messages are where the boots differ in the two .gamescope-stdout files I provided
Mweird, looks like its not seeing your internal display connector for some reason in the failed log
DI reccomend using
cat logfile | fpaste instead
Koo, good catch
Kwasn't looking that early
Kfirst one says it's DVI??
BYeah but only when there are files in /home/deck/.config/gamescope
So I deleted the contents and set the folder perms to unwritable and now gamescope boots properly every time
So I deleted the contents and set the folder perms to unwritable and now gamescope boots properly every time
BThis is undocked LCD Deck btw
BI have sunshine rpm layered but dnkmmr doesn't, so it shouldn't be that
Dwill that break my system?
BI have been regularly clearing the contents of this folder to get a successful boot but this is the first time I removed the write permission for owner/owning group. It's booted twice fine since. Logs show that it failed to open edid.bin.tmp but then it moved on and boots anyway
BBut i'd say be prepared to have a way to revert that change (via a liveCD or something) should it cause you trouble
MI believe that folder is usually how Gamescope corrects your display orientation and presents it as a native landscape display to programs running in Gamescope
