Red Hat Bugzilla – Bug 1283348
Black screen on KDE live session (with qemu-kvm)
Last modified: 2016-03-03 05:13:07 EST
Created attachment 1096202 [details]
void Plasma session
Description of problem:
I can't load a live session of F24 KDE on qemu-kvm. See the attached screenshot for reference. The selected component is just a guess.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a qemu-kvm guest.
2. Boot a live of KDE.
3. Wait until KSplash completes its work
I'm facing a screen which is entirely void, black (the only one exception is the mouse's cursor).
Plasma should start normally
1. startx from another TTY doesn't work either.
2. I'm testing the 20151117 Rawhide compose
Proposed as a Blocker for 24-alpha by Fedora user juliuxpigface using the blocker tracking app because:
This bug seems a violation of the following Release Criteria:
- 2.2.1 Release-blocking images must boot (All release-blocking images must boot in their supported configurations.)
- 2.2.2 Expected image boot behavior (Release-blocking live images must boot to the expected boot menu, and then to a desktop or to a login prompt where it is clear how to log in to a desktop.)
I also saw this
"could not start ksmserver" on boot
stops at plasma dropdown screen
Discussed at 2015-11-23 blocker review meeting: .
This bug was accepted as F24 Alpha blocker: this looks like a violation of "All release-blocking images must boot in their supported configurations."
I have same problem with my F24 rawhide installed on my laptop, not in a vm : black screen with only mouse cursor.
I use also xfce without problem.
*** Bug 1288692 has been marked as a duplicate of this bug. ***
I have multiple F24 installations on real hardware doing this since at least a month ago, e.g. 64 bit host big41.
I also can see black screen in Rawhide.
However krunner (alt-f2) works, it can start applications and alt+tab can switch between them.
Created attachment 1111486 [details]
How looks windowed plasmashell started from konsole.
I'm running openSUSE Tubleweed now and have no screen/display issues.
So is this really a kde plasma5 issue?
f23 with essentially the same stack of plasma5/kf5 on top is fine too. It could very well be something specific to rawhide, but we currently have no evidence either way yet.
I take that back, I can reproduce this on f23 with a fresh user (empty ~/.config, ~/.local and ~/.kde), using Qt 5.6.0 copr.
Created attachment 1112127 [details]
Backtrace of kdeinit5 crash
I always manage to reproduce it just by removing $HOME/.config/kconf_updaterc file, when this config file is removed then plasmashell will not start for the first time and sometimes I even get a crash of kdeinit5, see attached backtrace.
I have this issue with plasma5 and rawhide (since a month or more).
To make plasma5 boot i have to delete the /usr/share/kde-settings/kde-profile/default/share/plasma/shells/org.kde.plasma.desktop directory after every
If not, got a black screen, but i can run plasma apps (dolphin ...) with krunner.
Seem to be a plasma-workspace config problem.
(In reply to eddy02 from comment #13)
> I have this issue with plasma5 and rawhide (since a month or more).
> To make plasma5 boot i have to delete the
> plasma.desktop directory after every
> rawhide installation.
> If not, got a black screen, but i can run plasma apps (dolphin ...) with
> Seem to be a plasma-workspace config problem.
I confirm that, I also delete /usr/share/kde-settings/kde-profile/default/share/plasma/shells/org.kde.plasma.desktop and now plasma boot.
I look in my F23 and I have not this directory.
It's back yes, sort of ;-) But there seems to be more. In line with what Jan Grulich found, is that on my install kded5 does not respond to qdbus requests.
$ qdbus-qt5 org.kde.kded5 gives (wait 5 to 10 seconds)
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."
The same happens when asking to show background services in systemsettings (Startup and Shutdown -> Background Services).
Further, lots of actions take very long to happen, e.g. after login the network applet took 20 to 25 seconds to get activated (red icon -> black icon), removing files in Dolpin...
Found the crulprit, at least on my F24 :-) I've removed ktp-* and now everything works fine again. ktp's aprover module 'blocked' all kded dbus communications.
I've had always a bad relation with ktp ;-) That's why I suspected one of it's modules.
Still black screen after removing ktp* in my Rawhide vm.
Did you reboot your vm? Logout isn't enough, because some processes keep running. Is the ktp Aprover still loaded (qdbus-qt5)
Yes, black screen after vm reboot.
Yes, there is still more that misbehaves. When I put back /usr/share/kde-settings/kde-profile/default/share/plasma/shells/org.kde.plasma.desktop/* (see eddy02, comment 13) I get a black screen too. So it looks like there are more bugs.
@nucleo: did you do what eddy02 suggested?
After removing org.kde.plasma.desktop directory plasmashell starts fine.
OK, I can confirm that the mere presence of
makes things go horribly bad.
* Thu Jan 07 2016 Rex Dieter <email@example.com> 23-10
- revert prior commit, use prefix/plasma/shells/<package>/contents/updates instead
I can still reproduce this problem even with kde-settings-23-8.fc23, but I guess I was talking about a different issue caused by using Qt 5.6 from COPR. We should open a separate bug report for that probably.
*** Bug 1296912 has been marked as a duplicate of this bug. ***
<nod>, there's definitely multiple problems here, the kde-settings snafu was one of them.
...but my impeacement of ktp-* was wrong. I've re-installed it and everything is still fine. Sorry for the noise :-(
Bisecting kconf_update scripts, I found this one to be problematic for me:
(owned by plasma-breeze pkg)
I tested 6 fresh logins (simulating live session with no ~/.local, ~/.config, ~/.kde present):
3 with /usr/share/kconf_update/kde4breeze.upd present: plasmashell blackness
3 without /usr/share/kconf_update/kde4breeze.upd: plasmashell starts ok
Now, I'm going to take a closer look at what kde4breeze.upd does (or is *supposed* to do).
* Fri Jan 08 2016 Rex Dieter <firstname.lastname@example.org> - 5.5.3-2
- avoid kde4breeze.upd, causes problems for new users (#1283348)
This doesn't seem to have solved the problem for openQA tests at least, they're still booting to a black screen (after the splash screen) as of today, e.g. https://openqa.fedoraproject.org/tests/3054
OK, another possible issue,
Is anyone actually still seeing this?
I just realized that in openQA currently the KDE live tests are failing on https://bugzilla.redhat.com/show_bug.cgi?id=1308771 (which is a systemd SELinux labelling issue), but they *are* at least painting something, and if I boot one locally in a KVM with enforcing=0 it seems to work pretty much fine.
So, for me at least, I think this is actually fixed?
It seems fixed here too.
I installed the 20160220 compose - on qemu-kvm - and I haven't hit this.
(In reply to Adam Williamson from comment #31)
> Is anyone actually still seeing this?
Not sure. On real i686 host gx28b just dnf updated after last having updated >2 months ago, plasmashell announces segfault after the login splash has finished doing its thing. ps -a shows a lot of KDE stuff still active until I Ctrl-Alt-BS. Removing kconf_updaterc didn't help retry. Also no difference with or without kde4breeze.upd. /usr/share/kde-settings/kde-profile/default/share/plasma/ doesn't exist. On same machine Plasma is working just fine in F23.
That doesn't really sound like the same bug...
(In reply to Adam Williamson from comment #34)
> That doesn't really sound like the same bug...
You may well be right, but BRC search produces this bug only on searching comments of last 7 months for strings "plasmashell" and "segfault", even though the same crash announcement has been a familiar sight here across multiple 32 and 64 bit installations ever since Plasma 5 replaced KDE4.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.
More information and reason for this action is here:
I think I'm gonna go ahead and close this, for now. We can re-open if it turns out it's definitely not fixed. Felix, could you open a new report for your issue for now? Thanks!
(In reply to Adam Williamson from comment #37)
> Felix, could you open a new report for your issue for now? Thanks!
I've not seen this lately, so will do only if I find it reproducibly happening again. To much not getting done lately to actively go looking for it.