Plasma X11 - Desktop - Fails to Start after a fresh reinstall
About the issue:
So I just did a fresh reinstall on my desktop
Plasma X11 worked fine after first install but broke after first reboot.
This is also the issue why I reinstalled and it was not like this before, so my suppression is that is related to a recent update.
Start information:
- Latest standard stable Bazzite image (as of today, and yes I used the Fedora Image Writer).
- Secure boot is not enabled.
- AMD machine Graphics + CPU.
Installation information:
- SE Keyboard
- Enabled Root User
- Created a local user
- Automatic Install, removed all partitions and used a full drive
Things I did in the first session:
- Autologin via SDDM to Plasma X11 <---
- A system/app update via discover. <---
- Configuring Steam / Lutris
- Installing various flatpaks.
More things I tried:
Even after reverting the SDDM autologin from Wayland it still has the same problem.
Even stranger is that the not even the root account can start a plasma x11 session.
Logs:
Is there any place where the login attempt or session logs are stored that can give any clues to what is causing it?
36 Replies
weird, we had a similar report of this earlier but it was w/ GNOME and fixed by switching to KDE
@EyeCantCU might need some advice on grabbing useful logs here
As I got everything backed up and have only done some basic configuration I'm game for deep error hunting or even reinstalling again and retrace the steps.
There could be various things going on here. Generally, dumping
journalctl after an autologin login attempt would be best. .xsession-errors may have something as well
You could try resetting and backing up your KDE configuration. While logged out, jump into a TTY and run:
I'll look into it
@EyeCantCU
Here are the logs:
- Latest boot session journalctl, where I did an attemt to login to the X11
- xession-errors
- xorg.0.log
Are you stalled at a black screen? Are you able to use tty to do anything when stalled there?
No I just can not log in to the X11 session in Plasma.
But wayland works fine.
What happens is that it flashes and kicks me back to the login screen.
Contra to Wayland where it logs me in.
Oh strange. I had the opposite problem because I set fish as my default shell. I can’t think of anything causing this for you now. Sorry
Hey @Lazorne | RetroDECK 🇸🇪🇨🇳. I'm not seeing anything that stands out there other than X being unable to set the DISPLAY variable. As for why that's happening, I don't have a clue
I also looked in the files.
Is there anything I can do to enabled some enhanced logging?
All I know is that i just started after an update, but I don't really know when exactly.
But I thought it was my tinkering that have made it broken somehow, so I reinstalled to fix the problem.
But it came back after the first reboot.
I'll poke around more my self as well and post if I find anything interesting.
Not aware of anything for retrieving logs that are more thorough than what we've got. My desktop has a more recent AMD GPU in it so I'll try X11 on the latest image here in a bit and see if I can't replicate this
I found some topics of related issues
2 people over at the arch forum had issues SDDM and Plasma X11 back in 2016 and 2019
https://bbs.archlinux.org/viewtopic.php?id=234792
https://bbs.archlinux.org/viewtopic.php?id=213460
(This could have been fixed already)
Now I have already tried what they said and disabled
and re-enabled the systemctl enable sddm.service
I have also double confirmed that my display is indeed :0
with echo $DISPLAY as I tought it code be some ID number mismatch, where the display had another ID number.
I don't know if this is relevant:
https://github.com/sddm/sddm/issues/1835
What was the last update SDDM was upgraded?
Well just for the heck of it I tried a full rebase to Gnome Bazzite and x works
Sadly I'm having a hard time navigating gnome xD
It's all very peculiar. X is working on my 7800 XT under the latest image. Unsure exactly what's going on/causing problems
Changing the display server for SDDM might help
How do I do that?
Edit /etc/sddm.conf and add an entry:
DisplayServer=wayland or x11 depending on what's in use by default (believe it's wayland now)I'll try it out
There is no /etc/sddm.conf <:beagle_failing_builds:1113619440739827732>
/etc/sddm.conf.d/kde_settings.conf
/etc/sddm/ Xsetup, wayland-session, Xtop.
But the sddm.conf is missing in action.
BUT Anyhow I created the sddm.conf file
Added the DisplayServer=x11 syntax
and it works @EyeCantCU !
The problem is solved.
But the mystery is not really solved.
Why was the sddm.conf file missing on a freshly installed system or should it be generated and the generation did not work?
Is this the desktop or Deck variant?
The desktop variant has it but Deck matches Steam OS and uses steamos.conf
Should be the desktop variant as this is on the desktop and I just rebased back from gnome again to KDE
bazzite:stable
And not bazzite-deck:stable
Hmm.... We don't touch it in the desktop variant: https://github.com/search?q=repo%3Aublue-os%2Fbazzite%20sddm.conf&type=code
Do you have /usr/etc/sddm.conf?
I'll check soon I just need to put the kids to sleep
Sounds good 🙂
nope
Now that is weird. I'll have a look here in a little bit and see what's going on
Desktop Edition
and the sddm.conf.d is empty
need to go back to children again
@EyeCantCU same here in my KDE VM
however SDDM & KDE work fine
defaulting to wayland
On my laptop doing bazzite nvidia kde the
etc/sddm.conf and usr/etc/sddm.conf are both there
Not seeing it either. Wonder what our Kinoite images look like
Now that makes zero sense
@eyecantcu I take back what I said, was looking in the wrong place
/etc/sddm.conf exists and every single line of it is commented out by default
Since nvidia has it's own folder I added this:
https://github.com/ublue-os/bazzite/commit/bd4d24a574cf8ed878310284d4bb0f5b0877c439
Phew. Good. Had me worried we had some inconsistency where sddm.conf was getting removed. Looked for quite a while. I'm relieved it's there. That fix should work great for Nvidia