I’m wondering if anyone else is still affected by the above issue? I can’t seem to find a solution and I’m out of ideas. I’d really appreciate any assistance!
I was affected by the systemd bug last month. I’ve done
sudo pam-config --add --systemd
which did get my system back into working state; however, I still cannot get past the KDE login screen unless I do the following after entering my password:
wait until I get an arrow cursor; then
ctrl-alt-f1; and finally
ctrl-alt-f7.
Interestingly, I don’t have to log into the tty session. Just dropping into tty1 and immediately back out to a graphical session is all that is required. This process takes me to the KDE plasma5 desktop.
Does anyone else remain similarly affected? Any suggestions?
Yep, have the same problem. But only when using sddm as the display manager. If I change /etc/sysconfig/displaymanager to use ‘kdm’ instead, it works fine.
This is on a Dell D630 with Intel graphics, TW 20160626.
I’ve noticed recently on a few of my machines (both TW and LEAP, and definitely the machines running KDE) that there can be a very long pause before the graphical Desktop can load. I might have to wait as long as a couple minutes, sometimes I just have to type something (even a single key) before the boot process proceeds to the graphical login screen.
I haven’t yet had to drop to a tty to proceed although that might <seem> to be necessary.
I haven’t yet found it’s related to a particular Display Manager although it’s possible.
I’ve always suspected something might be amiss on LEAP/TW just prior to launching the graphical Desktop since LEAP first launched, there has <always> been a delay where the text login displays for at least a few seconds which never was seen before in 13.2. Almost as though the boot has to <completely> reach multiuser.target before starting graphical.target which if true creates a critical node bottleneck where parallelism isn’t happening.
@GeoBaltz: That worked for me, too. I changed to kdm and was able to login normally. I wonder if this means there is a bug in sddm? Perhaps it was reported and I missed it… My system is an HP Elitebook 2540p, TW20160701. (If anyone has a work-around for sddm, can you kindly point us to it?)
@Tsu2: Prior to changing the display manager as @GeoBaltz suggested above, I tried what you suggested. I waited an extended period (about 10 minutes). Even typing, escaping, etc. didn’t seem to get me past the login screen. Dropping to tty and back, as in my original post, permitted me into the graphical desktop.
Again, thanks to you both for your comments/ assistance!
I am using “lightdm” to login (you have to install that first). I am not having problems.
Today, I switched back to “sddm”, and login was fine. But I’ll switch to “lightdm” again in the future.
I have occasionally seen what might be the same problem. It did not occur to me to use CTRL-ALT-F1 followed by CTRL-ALT-F7. Instead, I used CTRL-ALT-BACKSPACE (twice) to crash the X-session, and login usually worked the next time.
As to why I use “lightdm” – I install both Gnome and KDE. The Gnome login keyring only opens automatically if using “gdm” or “lightdm”. And I don’t like “gdm”.
In case this helps anyone else, it appears that the sddm breeze theme may be contributing to (causing?) this issue. Others are reporting issues (in bugzilla and elsewhere) with sddm’s breeze theme, although not necessarily manifesting exactly as described above.
In any event, on my system, using another display manager (e.g., xdm, kdm) as was suggested above resolves the problem. As well, changing the sddm login theme from breeze to any other sddm theme re-enables the correct (expected) login behavior when using sddm.