Yeah, but from the time my friend enter the credentials to the time login hang as per the image, they are passed just few seconds. I doubt the screenlocker kick in meantime.
I tried killing it (take the pid from pgrep kscreen*, then kill -9 pid), but the login stay broken.
Tried to check the disk forcing fsck from the kernel command line with fsck.mode=force, the disk seems in good shape. Also no ugly messages about disk from dmesg (http://i.imgur.com/v1SyU4L.jpg
), neither from journalctl -b /dev/sda5 (it says no entries)
Tried to look into abrt, but the only recent directory (28 august) was about kscreenlocker only (http://i.imgur.com/96pnKbX.jpg
I think that what I need is a way to look on what call or step sddm hangs. Calling who? startkde? kdeinit5? I don't know.
I though to kill the graphical session and then, from a terminal, call directly startkde or startx, hoping to see some errors in the terminal but:
startx -> the screen became black and only the mouse remains visible. The user can move the mouse but nothing other than that.
Then I switch on another terminal just to look into the xorg log with "tail -n 30 /var/log/Xorg.0.log" (http://i.imgur.com/KYyq6HN.jpg
), but I don't see nothing special
xinit /bin/startkde -> a lot of lines, then black screen with everything frozen, mouse included.
to discover some error messages from startkde or startx, should I use commands like:
journalctl -b | grep startkde
journalctl -b | grep startx
and maybe the status of sddm with
systemctl status sddm
Unfortunately, my troubleshooting skills about the lower layer stack (kernel+init) are too poor. :-(