(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.
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.
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.
● 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.
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:
(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.)
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?
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 ?
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.
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