KDE login: black screen, only mouse cursor

Hello Forum !

(I hope this is the correct forum, as I think it is related to KDE and not to system boot !)

If I login to KDE (sddm looks fine), the KDE login splash screen / animation appears for an unusual long time, ending in a black screen.

  • Mouse visible and working
  • Correct setup of the two monitors (alignment, resolution)
  • KRrunner (alt-F2) works, I can start (KDE) applications from there
  • no unusual high CPU load

I think the problem first appeared after an upgrade, whereas I also have the KDE repositories (Application, Extra, Frameworks, Qt5) from “download.opensuse.org/repositories/KDE:/…” active. So far, this had never been a problem.
Apart from this, it a Leap-15.1 system with recent upgrades, kernel 4.12.14-lp151.28.91-default, but I think this is not a kernel issue.

I tried deleting the user’s “.cache/”, but that did not change anything.
I created a plain new user, but same issue. So I think it is not related to some odd configuration files.
The standard logs (journalctrl, X) do not provide any useful hints.
Updating to the lastest packages did not change anything.

Any hint what this may be, or where I can look for more information ?
If not, I may try a rollback, but I want to avoid this.

Regards, Sven / the_wumpus

That used to happen here, back when I had a computer with Nvidia graphics.

There were two ways to avoid it:

(1) Install the nvidia drivers.
(2) Boot with “nomodeset” on the kernel command line, and then KDE should work. Disable desktop effects. Reboot without “nomodeset” and see if it now works.

I don’t know if you have Nvidia graphics, but you are probably seeing a graphics card issue. You could try something similar to the above.

I do have an Radeon GFX card, with OS drivers. And I do not think that this is an GFX crd issue, as resolution and dual monitor setup seem to be ok: mouse cursor is ok, and application are correctly shown if started via KRunner.

Nevertheless, thank you for the tips, I’ll give them a try.

Regards, Sven

Are you using Xorg, or Wayland? To be sure of that and more, please from Konsole, do:

inxi -GSIa > somefile.txt

and paste here somefile.txt using code tags around it. You might not be using the optimal choice of X graphics driver for your GPU. Problems have been creeping up lately for some users of older Radeon GPUs.

Here it is:

System:
  Host: HAL Kernel: 4.12.14-lp151.28.91-default x86_64 bits: 64 compiler: gcc 
  v: 7.5.0 
  parameters: BOOT_IMAGE=/boot/vmlinuz-4.12.14-lp151.28.91-default 
  root=/dev/mapper/VG_root-root 
  resume=/dev/disk/by-uuid/ae7bdd69-f80f-4387-8397-7b0e6409b538 splash=silent quiet 
  showopts 
  Console: N/A dm: SDDM Distro: openSUSE Leap 15.1 
Graphics:
  Device-1: AMD Baffin [Radeon RX 550 640SP / RX 560/560X] vendor: Micro-Star MSI 
  driver: amdgpu v: kernel bus ID: 0a:00.0 chip ID: 1002:67ff 
  Display: server: X.org 1.20.3 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa 
  tty: 87x29 
  Message: Advanced graphics data unavailable in console for root. 
Info:
  Processes: 367 Uptime: 4h 43m Memory: 15.59 GiB used: 979.2 MiB (6.1%) 
  Init: systemd v: 234 runlevel: 5 target: graphical.target Compilers: gcc: 7.5.0 
  alt: 7 clang: 7.0.1 Shell: bash (sudo) v: 4.4.23 inxi: 3.1.00 

No, same issue also with “nomodeset”.

Some thoughts…

  1. When this happens, try changing to a VT (eg VT2), login as root, and do
systemctl status display-manager

Any errors apparent?

Try

systemctl restart display-manager

Does that result in a working desktop?

  1. Try changing to an alternative display manager (eg lightdm)…
    SDB:Change Display Manager - openSUSE Wiki
    Once done, then reboot. Does the problem still persist?

Result, seems ok to me:

● display-manager.service - X Display Manager   Loaded: loaded (/usr/lib/systemd/system/display-manager.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2021-01-31 13:07:25 CET; 5min ago
  Process: 2356 ExecStop=/usr/lib/X11/display-manager stop (code=exited, status=0/SUCCESS)
  Process: 2369 ExecStart=/usr/lib/X11/display-manager start (code=exited, status=0/SUCCESS)
 Main PID: 2390 (sddm)
    Tasks: 24
   CGroup: /system.slice/display-manager.service
           ├─2390 /usr/bin/sddm
           └─2764 /usr/bin/X -nolisten tcp -auth /run/sddm/{01d2d6a1-e4b7-45f2-9e87-824b3d2b7ccb} -background none -noreset -displayfd 18 -seat seat0 vt7


Jan 31 13:08:15 HAL sddm[2390]: Display server started.
Jan 31 13:08:15 HAL sddm[2390]: Socket server starting...
Jan 31 13:08:15 HAL sddm[2390]: Socket server started.
Jan 31 13:08:15 HAL sddm[2390]: Loading theme configuration from "/usr/share/sddm/themes/breeze-openSUSE/theme.conf"
Jan 31 13:08:15 HAL sddm[2390]: Greeter starting...
Jan 31 13:08:15 HAL sddm-helper[2796]: [PAM] Starting...
Jan 31 13:08:15 HAL sddm-helper[2796]: [PAM] Authenticating...
Jan 31 13:08:15 HAL sddm-helper[2796]: [PAM] returning.
Jan 31 13:08:16 HAL sddm[2390]: Greeter session started successfully
Jan 31 13:08:16 HAL sddm[2390]: Message received from greeter: Connect

Unfortunately not.

Tried “LightDM”, but problem persists. There only difference is that I do not have a black screen, but the background from LightDM.

Perhaps you just lost your working panel.
You said your mouse is still working functionally.
Then try: right click -> Add Panel -> Default Panel

I have pretty much the same problem, under pretty much the same circumstances.

Problem:
After a reboot due to updates, I can’t get to a working desktop: The login screen looks normal, then I get the normal lizard-lightbulb image with the spinning busy-indicator, but that indicator freezes as soon as the mouse-pointer appears.
As with Sven/the_wumpus, the mouse works, KRunner (ALT-F2) works (as does System Activity (ALT-ESC)), and some programs (eg. konsole, dolphin) launch successfully - but without any window decorations: titlebar, borders.
I can manually launch /usr/bin/plasmashell, which shows me my regular desktop with functional panels. Except that the Pager is missing, and if I try to launch it manually, it errors out saying that it can’t talk to the compositor. And the items in my ~/.config/autostart/ folder have also not been started (or else tried but failed).

Circumstances:
Leap 15.1 with the current KDE repos enabled.
zypper update pulled in new systemd and udev packages.
I rebooted, and got the results above.
There may also have been a new kernel from a previous update that I had not rebooted yet.

I do have an nvidia graphics card, with the proprietary drivers from nvidia’s repo. They have never given me trouble before.
Just to be sure, I force-reinstalled them, which recompiles them for the current kernel.

I also tried doing a snapper rollback to the system state before that update, but the problem remained.
I also tried booting into the previous kernel from grub2 - no difference.
I ran rpmconfigcheck to see if there was a conflict between any old vs new config files for updated packages, but found no plausible suspects.

System Activity shows reasonable things, to my non-expert eyes, such as:

  • systemd > sddm > sddm-helper > startplasma-x11 > plasma_session
  • systemd > systemd > krunner|kglobalaccel5|…
  • systemd > kdeinit5: > klauncher

(Honestly, I was hoping that there was an error in the updated packages yesterday, and that there would be another update today that fixed the issue, but there aren’t any updates today.)

Any other suggestions?

Cheers,

  • Edward

I would normally recommend a submitting bug report in such circumstances, but as openSUSE Leap 15.1 is now EOL, perhaps it’s time to consider upgrading to Leap 15.2?

Just tested, but right-click does not work, that is I do not have a menu.

Hi Edward,
good to hear that I am not the only one …

But: I performed a rollback back to January, 17th - and voila, KDE is running again, also my complete setup with dual monitors and the plasma app is as-islol!.
This snapshot/rollback-thingy is one of the best things ever… isn’t the fit time that this saved me a re-install.

Of course, system update now says that there are 318 updates to be installed. Well, not today - maybe next weekend, should have time to investigate due to the current world health situation.

Thank you all who tried to help me wit this, let’s hope I find the true root cause.
Regards, Sven / the_wumpus

Well, I wanted to do some bug hunting this weekend, just to find out that Leap 15.1 really came to E.o.L. this week, and immediately the 15.1. KDE repositories disappeared. Well, time for an distribution upgrade (DUP) to 15.2, which I did as follows:
[LIST=|INDENT=1]
[li]Disabled all 15.1 KDE repositories, as they already became dysfunctional;[/li][li]Performed a final update to latest 15.1. packages - the main 15.1 repositories were still active, and this is the suggested way before a DUP;[/li][li]Performed a DUP to 15.2 following the SDB guide, including the 15.2 KDE repositories (otherwise I got too many issues).[/li][/LIST]
The DUP itself went w/o problems, and the system booted cleanly to the login screen.

However, KDE is not really working, now I have the following effects:
[ul]
[li]Dual-Monitor setup ok, window manager running;[/li][li]Plasma 5 widgets appear as before, however are only rendered once initially, then stopping any activities;[/li][li]No panels;[/li][li]Two apps - Kontact and Firefox - open and running, these had been open before the DUP;[/li][LIST]
[li]Actually, the full Akonadi stuff seems to run, as Kontact was able to correctly download new mails ![/li][/ul]

[li]100% CPU time by process “plasmashell”;[/li][li]After some long waiting, the panels appear, but are not useable.[/li][/LIST]
KDE on a fresh “Test” user, which I created before the DUP for some debugging, however works well.

I guess there is some configuration problem which causes plasmashell to go mad. I do not have a problem to setup my widgets again, however I would like to keep the other settings e.g. for Kontact.

The means, is there a way to reset just the KDE plasma settings ?

Kind Regards, the_wumpus / Sven

The means, is there a way to reset just the KDE plasma settings ?

The relevant configuration files are in ~/.config/, but it can take a bit of trawling to know which files to target.

Here’s a couple of pages that might be of interest to you
https://wiki.debian.org/KDE#Reset_your_KDE_Plasma_configuration_to_defaults

If it were me, I would target ~/.config/plasma* and ~/.config/kde*, but rename the config files to *.old, rather than removing them. You can then easily reverse any changes as required, and make them active again while you decide which config file was causing problems for you. Hope this helps.

If you do

kquitapp5 plasmashell

then run

plasmashell 

again

That did it, thank you very much :shake::cool:.

So, as a result, it stated with an KDE update issue, and finally ended in an up-to-date 15.2 installation. Not that bad…

Regards, and thanks to everyone for the assistance,
the_wumpus / Sven

Well done! :slight_smile:

Unfortunately,

kquitapp5 plasmashell

resulted in a failure that the application did not provide an answer, and after killing plasmahell and restarting it the command just returned.
But never mind, the tips from deano_ferrari did it.
Best Regards, the_wumpus / Sven

@the_wumpus:

I suspect that, one point has been missed in this post –

  • What happens with, a new, fresh, untainted, user?

[HR][/HR]Yes, the existing user has to be debugged but, the first thing to establish is –

  • Does the GUI as such work correctly?
  • Is there an installation issue – error – mistake?