Earlier today, I ran dnf update
on my laptop, as I do regularly. After rebooting, I couldn’t log in. When I typed in my user name and password, it almost immediately returned to the login screen. Running startx
from the command line failed, too. I spent an hour or two trying to diagnose the problem. There were a lot of distracting messages in the xorg log.
The problem turned out to be that the startkde
command was no longer on my machine. It seems upgrading from version 5.16 to 5.17 of the plasma-workspace package removes startkde
in favor of startplasma-x11
. Creating a symlink fixed it as a workaround.
This is reported as bug #1785826, and I’m sure Rex and the rest of the Fedora KDE team will have a suitable fix out soon. In the meantime, creating a symlink appears to be the best way to fix it.
Why the symlink works
When an X session starts, it looks in a few different places to see what should be run. One of those places is /etc/X11/xinit/Xclients
. This file checks for a preferred desktop environment. If one isn’t specified, it works through a list trying to find one that works. It does this by looking for the specific desktop environment’s executable.
Since startkde
no longer exists, it had no way of checking for KDE Plasma. I don’t have any other desktop environments installed on this machine, so there was no other desktop environment to fallback to. I suspect if GNOME were installed, it would have logged me into GNOME instead, at least when running startx
.
So another fix would be to replace instances of startkde
with startplasma-x11
in the Xclients
file (similarly if you have that file in your home directory). However, this leaves anything else that might check for the existence of startkde
in the lurch. (I don’t know if anything does).
There’s probably more options for fixing it out there; this is very much not my area of expertise. I’d have to say that this was the most frustrating issue I’ve had to debug in a long time, in part because it took me a while to even know where the problem was. The fact that moving my ~/.kde
directory didn’t result in a new one being created told me that it was pretty early in the process.
What distractions did I see?
In trying to diagnose the issue, I got distracted by a variety of error messages:
xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
/dev/fb0: permission denied
gkr-pam: unable to locate daemon control file
pam_kwallet5: couldn't open file
Pingback: Links 22/12/2019: Linux Random Number Generation, KTimeTracker 5.0.1 | Techrights
Thank you!
Perfect and simple solution.
Thanks for share.
thanks a lot – this solved the problem for me.
Note that this is a known bug, and a package with the fix already exists in testing: https://bugzilla.redhat.com/show_bug.cgi?id=1785826
Pingback: Fedora 31 Login - LoginCrunch