[ Solved! ] No Desktop Environment (" DE ") After Upgrade Today!

Greetings again. Just issued my routine

/usr/bin/pacman -Syyu

although successful, no “KDE” is loading. No complaints echoed on screen either. When the " DE " is supposed to load, it doesn’t.

I was able to launch “KDE” remotely through the X2Go service that is installed. No problems there.

Care for troubleshooting? Many thanks! :smiley:

Your the first to have this issue here, more information is needed.
Are you using auto login, or is this after you log in manually through sddm?
Have you changed any themes for sddm?
What GPU do you have?
Did you change the kernel series from 4.11 to 4.9 as previously suggested in this forum?

may be do not use “Air” theme , see other bug report for that: “…even any bugs?”

The affected system was indeed doing “KDE autologin”. I would start by disabling that.

However, I checked the current /etc/sddm.conf file and " [Autologin] User= " is blank.

The affected system is " AMD " based running the recommended v.4.9 kernel series.

Thank you.

This issue has been reported on the Manjaro forums as well.
Although the issue, and the solution, is different for each users.
Are you using the free or proprietary driver for the GPU?
Is the issue before or after SDDM loads?

please describe problem + solution so it can be put into the wiki.

stuff like this is giving Linux a bad name a lil bit … :-/

Indeed, I should have mentioned concerning " AMD " video driver being the free one.

No " SDDM " screen (or anything graphical for that matter) is currently loading. I have 03 lines of usually echoed " TTY "-type of text. And that’s it.

Like I said, since I have " X2Go " running here, I can access the final " KDE " desktop remotely. I then checked about < autologin > settings and other things which are now disabled.

That’s my office workstation running The NetRunner rolling; ( Am I crazy or what? :wink: ) I brought my notebook today to continue work remotely through the remote desktop. Software deemed “stable”, isn’t sometimes “stable” enough, I lnow the drill. Being a Linux desktop user is the same thing as being a computer enthusiast.

Thank you.

OK, so your getting the SDDM not loading issue that has been reported in both the Manjaro, and Arch forums the last few days.

There is more than one way to fix this.

1: First thing to try is just rebuilding your initramfs in case it didn’t get rebuilt against systemd 235 during the upgrade proccess. If that still fails, try adding your GPU Kernel driver [i915 +/- intel_agp (suppresses the ACPI error messages, must be before the i915 entry), radeon, amdgpu, nouveau] to the MODULES= line of your mkinitcpio.conf file for early loading, and then rebuild the initramfs.

2: Try the 4.4 LTS kernel (has far less issues) if your hardware support is there. Alternatively you could also try one of the newer kernels. There have been mixed results reported from just changing the kernel however.

3: Try downgrading SDDM to 0.15 and add it to your pacman.conf ignore list temporarily untill this is fixed upstream.

If any other solution to this particular issue are presented I’ll report those as well.

I believe it’s fair to confirm that everybody running NetRunner Rolling on " AMD " based graphics will lose the desktop environment.

At this point seems " timing " of components loading after " GRUB "; for example, for typical notebook setup, right after " GRUB " screen, if you insert a disc on a CD/DVD/whatever drive, you may see the graphical login manager back.

That’s why I keep multiple desktop systems operational. Linux is the only, only kind of software I’ll ever use and I don’t feel discouraged by things like these. Do however understand that’s not for everybody.

Regards,

Actually, this issue is NOT AMD specific, but effects all of the free opensource drivers to various degrees, depending on the actual GPU:

1: https://github.com/sddm/sddm/issues/905
2: https://github.com/sddm/sddm/issues/906
3: https://github.com/sddm/sddm/issues/915

PS, I’m so glad David decided to finally STOP creating (shipping) a default sddm.conf file, and changing the order in which SDDM looks for system / user configuration files (directories) to match all other systemd style applications behaviour.

For those desperate ( you will be :wink: ), one stupid workaround: on the second following your " GRUB " 5-second menu, please insert a valid disc on CD/DVD/whatever drive.

Thank you.

Most systems these days don’t even have cd/dvd drives.
The most reliable work around atm is to add your gpu driver to the mkinitcpio.conf file and rebuild the initramfs.

NOTE:
I’m not sure if this will effect hybrid graphics, I never purchase systems with them.
Might be why I can not reproduce these issues.

How did yoou do that trick. Over here, I get x2go to work with XFCE only, and even then, most apps such as OCTOPI are not being rendered by x2go.

x2go is pretty useless here but an ordeal to se up. :@

Concerning the " X2Go " bundle, I did nothing in particular except for that 1-off manual database kickoff on sever side. I can confirm between two recent NetRunner machines, that should work.

One thing, I don’t mingle different " DEs ". If I ever need more GTK apps, I prepare a separate drive with GTK-based desktop for that.

For now I will sit and wait for developments on the " SDDM " side. Thank you.

Best,

Following the latest upgrade released around this past weekend (December 16th), the main issue of this thread seems to be behind us.

Greetings of the season everybody!

Yes, sdmm was fixed upstream by the sddm developers.
If you don’t mind, could you please add (Solved) to the beginning of the original thread tittle.