KDE User Freezes after SDDM login; root KDE user is fine and so is same user under Xfce

I have a repetitive problem I would appreciate help troubleshooting. I have a Garuda installation where everything seems to be fine. I then do pacman -Syuu and the update seems to go fine. But occasionally when I reboot, something happens after I log into that user at the SDDM screen. The indicator spins, but rather than going away and launching the desktop, the spinning indicator freezes and goes no further. I have to alt-ctrl-F6 (or is it f7) and then log in as root and reboot.

If I reboot and then change the session to xfce, the user logs in just fine, so the problem seems to be KDE related. I note that if I try to run dolphin or even kate from terminal while in XFCE, they never start and the terminal never shows any output at all.

I am stumped on how to begin troubleshooting. I have used Timeshift to roll back a few times, and that can seem to work, but then when I do Pacman -Syuu I am back in thevery same lockup at the sddm screen.

Some googling has indicated that maybe I should check for *.lock files that might need to be deleted, but using catfish on my home directory shows none.

Any ideas about what could be happening? Running this user in XFCE works fine so I can continue to do that, but I would like to get Plasma running for that user again.

thank you!

Well if you reboot
The issue goes away

I also experienced it few times

So far i have turned off autologin

As its quite a problem

Kde does not start polkit when autologin is on

1 Like

Sorry to have been unclear. Rebooting does not fix the problem for me, and I am not autologging in. Nothing fixes the problem for me so far with this user other than starting the session in XFCE. Every time I try to log the user in under plasma it just freezes. Root does not seem to have that issue, nor do other users that I create fresh.

I have tried clearing out the major kde configuration files in the user directory but so far no luck.

Well from what you’ve said a recent update could have caused this bug on your machine. The best way to identify the issue is to roll back your machine and hold back any update that you think could be causing this. The other option is to do all the updates and selectively downgrade packages one by one.

A lot of work, or you could simply wait a week to see if the bug has been fixed. Of course waiting will make things even more difficult to diagnose, because more and more updates will be accumulating in the meantime.

Have you not considered the possibility that it is your multiple desktop installation that is causing this buggy behavior. Generally, this is exactly the reason why I always try to dissuade people from doing this. At first glance it appears to be an update issue. However, we do not know if the problem is caused because you have files from different desktops that conflict after the update is done.

This is exactly why I try to strongly discourage people from installing multiple desktops. It makes diagnosing quirky behavior like this extremely difficult. The only way to rule that out as a possibility is to wipe your system, then only install one version of KDE Garuda on your machine (no other desktops or OS’s).

If you do this and your login issue is resolved then you will know your multi-desktop installation caused the issue. If it persists, then you will at least be able to rule that out as a possibility. My gut feeling is that more people would be reporting this issue if this is a bug with ssdm, KDE, (or whatever) on a standard installation.

I could be totally wrong, but I highly suspect that multiple desktops are a factor in this case. Either way, it will take a fair bit of effort to identify the cause. Best to stick to a standard Garuda installation method. The main reason being no one on the forum wants to waste time troubleshooting an issue that could be a result of using a non-standard installation method.

Good luck with your issue.

(Edit:)

Also, logging in as root has the potential to create serious problems for a user. This is also not recommended either.

2 Likes

Thanks for the comments and I know you are doing your best. In this case I added XFCE only after repeated efforts to fix the problem in my KDE only system failed, and I wanted to get the user running again because I needed access to the files and capabilities of that user.

I suspect something else is going on and maybe you are correct that in the end it will resolve itself, and I can in the meantime use the XFCE desktop. I will also probably create one or more new KDE users and see if I can detect any kind of pattern.

I am just used to seeing more in the way of errors pop up in terminal on launching things, but nothing I can figure out so far. I am not so sophisticated as to be good at diagnosing things by looking at journals and logs, but I know that's my own problem to deal with.

If I ever figure it out and think the resolution would be helpful, I will post back anything that might conceivably be helpful to others.

This particular machine is one of my oldest and slowest, so it's probably more suited to XFCE anyway.

I'll make a couple of notes:

Similar problem: https://www.reddit.com/r/archlinux/comments/ayqxh0/sddm_freezes_after_logging_in_with_one_specific/

Another similar problem: https://askubuntu.com/questions/765364/kubuntu-16-04-sddm-login-screen-hangs

1 Like

I don't think processor speed is that great a factor for running KDE. The amount of ram and using an SSD for your OS is probably the biggest factors. Those trying to run with the bare minimum of the recommended 3 GB ram will not likely have a great user experience with Garuda. Garuda is not optimized for old hardware, (quite the opposite).

IMO 4GB is a more realistic minimum for old hardware. Even then, if it is an old laptop I'd want even more ram, as it may have ram allocated to the graphics.

Did you install this back when the Guest account was the default. Perhaps there is a problem with your UUID on login are you using UID 1000 for your primary user account.

You can find the UUID of an account with this command:

id <name_of_user>

This a copy of my /etc/sddm.conf

[Autologin]
Relogin=false
Session=plasma

[General]
HaltCommand=/usr/bin/systemctl poweroff
InputMethod=qtvirtualkeyboard
Numlock=true
RebootCommand=/usr/bin/systemctl reboot

[Theme]
Current=breeze
CursorTheme=breeze_cursors
DisableAvatarsThreshold=7
EnableAvatars=true
FacesDir=/usr/share/sddm/faces
ThemeDir=/usr/share/sddm/themes

[Users]
DefaultPath=/usr/local/sbin:/usr/local/bin:/usr/bin
HideShells=
HideUsers=
MaximumUid=60000
MinimumUid=1000
RememberLastSession=true
RememberLastUser=true
ReuseSession=false

[Wayland]
EnableHiDPI=true
SessionCommand=/usr/share/sddm/scripts/wayland-session
SessionDir=/usr/share/wayland-sessions
SessionLogFile=.local/share/sddm/wayland-session.log

[X11]
EnableHiDPI=true
MinimumVT=1
ServerArguments=-nolisten tcp
ServerPath=/usr/bin/X
SessionCommand=/usr/share/sddm/scripts/Xsession
SessionDir=/usr/share/xsessions
SessionLogFile=.local/share/sddm/xorg-session.log
UserAuthFile=.Xauthority
XauthPath=/usr/bin/xauth
XephyrPath=/usr/bin/Xephyr

Your conf file should be similar except for the current theme which may be different. Check to make sure your configuration file has no major differences.

While a lot of work I guess there is the possibility creating a new acoount, deleting the old account and then renaming the new account to the old name is a possibility. You would also need to change the UUID's. That would definitely be a learning experience, and learning how to manage account's is always a good thing to know.

Good luck.

2 Likes

Your issue is probably because of changes or deletion/addition of dot files with environment variables, or security related (Xauthority, logind, pam, keyring, etc.).
Compare your home folder to /etc/skel/.

The easiest solution is to use a clean new user, as already suggested.

KDE and XFCE devs suggest against using several DEs at the same user account.
Linux lets you free to brake your session or system, unlike other OSes. That doesn't mean you should do it and then seek for help. It is assumed you want to learn by mistake, so I will let you learn the best way :wink:.

3 Likes

Thank you for all the replies. I ended up biting the bullet and doing a full reinstall of system and home too. If I happen to come up with anything else that might be helpful for someone else, I will post it. In the meantime I will mark "solved"

2 Likes

Also, please consider timeshift as a helpful adjunct to a proper backup regime, not a replacement (as configured out of the box). Timeshift also can not be guaranteed to revive your system from a state where you can not boot or login.

If you are caught unprepared you might be left unable to recover your data especially if you use any encryption.

Please implement a proper backup strategy so that you're not left with a completely unaccessible system. Imaging your boot drive is an almost foolproof method of ensuring you always have a working system. Imaging, and an incremental backup system utilizing rsync is the best way to guarantee you don't suffer a devastating data loss.

Setting up a proper backup system may seem like an unnecessary ordeal, but without that safety net you're living on borrowed time until the unthinkable happens.

Best of luck on your journey.

2 Likes

Why the pacman -Syuu?
All is needed would be pacman -Syu

5 Likes

Because I am relatively new to Arch and picked that up somwhere inadvertently - I have no idea what the extra U does! :wink:

As for imaging the drive, yes I would like to do that but I have never had success with answering the setup questions to save and restore in Clonezilla. Are there any easier linux-based tools for that?

Translate your self :wink: or use man pacman

https://wiki.archlinux.de/title/Pacman

1 Like

I have not used this version, but I have used the old version of redo backup many times in the past. Redo backup was one of the best looking and easiest Linux imaging alternatives out there (in its day}. I’d go so far as to say it gave many paid Windoze based imaging programs a run for their money when it was in its prime.Unfortunately, it lay abandoned for years. The old redo backup would still work on very old hardware but nothing close to modern hardware.

Good news though, I’d heard someone had picked up the torch and revived redo backup. I have no first hand knowledge as to how well this forked version works, (as I have not tested it out). All I can say is if it’s anything like its predecessor it should be dead simple to use. The old version was so simple that an 8 year old could easily use it, (no exaggeration).

In its day redo backup had the best appearance and ease of use of almost anything out there. Of course being dead simple to use means you won’t have the choice of advanced options like clonezilla, but it was more than adequate for the average user back in the day.

If it’s half as good as the old version it should still be pretty good.

Redo Rescue: Backup and Recovery

I have no idea how well the new version works, but it does have a 4.7 out of 5 rating on Sourceforge.

As for me, my tool of choice is the age old dd command. I simply clone one similarly sized SSD to another and swap them around via a 6 bay SSD hotswap rack.

Good luck and let us know how you like redo rescue. You should have no problem figuring out how it’s used without reading any manpage.

1 Like

I'm having the exact same issue, I installed KDE on my desktop and when I put in my password to login, it just freezes on the screen with the eagle and spinning icon. I don't know if it has anything to do with the hardware I'm running.

I have a Ryzen 7 1700x, with a 1080TI GPU

Edit: I wanted to try the gnome version originally, but there was a warning about there being a bug for nividia users. I wonder if this is the same problem?

Just on the off chance it might help try booting into the fallback kernel at the grub boot menu.

That didn't seem to help unfortunately. I was thinking maybe it was my dual screens causing an issue, but turning one off did not work either. I have no idea what the problem could be.

Also, now it just freezes on the

Loading kernel linux-zen
loading initial ramdisk

Is it possible that you used the KDE Wayland session?
If so, use the Xorg session (no Wayland in description).

4 Likes

Only GNOME was affected by that. Some users which originally had issues reported to have it working now, best you could do is testing the live usb install, nothing lost doing that :grin:
Also as suggested, Wayland is still rather unsupported (especially by nvidia)

2 Likes

It is always best to open a separate help thread than to tack on an “I’m having the exact same issue” on another users thread because rarely are two systems ever exactly the same.

Did you, (like the OP of this thread) install multiple desktops on the same system?

If you did… don’t do that and then expect to get assistance on the forum.

Best to start your own help request with your system specs to help us diagnose your issue.

On a new thread, please post the output of this command:

inxi -Fxxxza

You can post the output from the live boot environment if you can’t login. Also, please do not post pictures of command outputs.

Separate thread please.

Thank you.

1 Like

Yes! this worked! thank you!!!

2 Likes