Bug 1283348 - Black screen on KDE live session (with qemu-kvm)
Black screen on KDE live session (with qemu-kvm)
Product: Fedora
Classification: Fedora
Component: plasma-workspace (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: KDE SIG
Fedora Extras Quality Assurance
: 1288692 1296912 (view as bug list)
Depends On:
Blocks: F24AlphaBlocker
  Show dependency treegraph
Reported: 2015-11-18 14:00 EST by Giulio 'juliuxpigface'
Modified: 2016-03-03 05:13 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-02-29 13:14:14 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
void Plasma session (6.36 KB, image/png)
2015-11-18 14:00 EST, Giulio 'juliuxpigface'
no flags Details
windowed plasmashell (63.43 KB, image/png)
2016-01-04 08:53 EST, nucleo
no flags Details
Backtrace of kdeinit5 crash (13.14 KB, text/plain)
2016-01-06 07:14 EST, Jan Grulich
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 358017 None None None 2016-01-19 10:23 EST

  None (edit)
Description Giulio 'juliuxpigface' 2015-11-18 14:00:59 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):

How reproducible:

Steps to Reproduce:
1. Create a qemu-kvm guest.
2. Boot a live of KDE.
3. Wait until KSplash completes its work

Actual results:
I'm facing a screen which is entirely void, black (the only one exception is the mouse's cursor).

Expected results:
Plasma should start normally

Additional info:
1. startx from another TTY doesn't work either.
2. I'm testing the 20151117 Rawhide compose
Comment 1 Fedora Blocker Bugs Application 2015-11-18 14:08:55 EST
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.)

- https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria#Release-blocking_images_must_boot

- https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria#Expected_image_boot_behavior
Comment 2 satellitgo 2015-11-18 14:09:50 EST
I also saw this

"could not start ksmserver" on boot
stops at plasma dropdown screen

Comment 3 Petr Schindler 2015-11-23 12:40:06 EST
Discussed at 2015-11-23 blocker review meeting: [1]. 

This bug was accepted as F24 Alpha blocker: this looks like a violation of "All release-blocking images must boot in their supported configurations."

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-11-23/f24-blocker-review.2015-11-23-17.00.html
Comment 4 dominique 2015-12-17 00:19:15 EST
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.
Comment 5 Giulio 'juliuxpigface' 2015-12-18 16:28:12 EST
*** Bug 1288692 has been marked as a duplicate of this bug. ***
Comment 6 Felix Miata 2016-01-01 03:10:30 EST
I have multiple F24 installations on real hardware doing this since at least a month ago, e.g. 64 bit host big41.
Comment 7 nucleo 2016-01-03 12:43:43 EST
I also can see black screen in Rawhide. 
However krunner (alt-f2) works, it can start applications and alt+tab can switch between them.
Comment 8 nucleo 2016-01-04 08:53 EST
Created attachment 1111486 [details]
windowed plasmashell

How looks windowed plasmashell started from konsole.
Comment 9 Martin Kho 2016-01-04 09:35:21 EST

I'm running openSUSE Tubleweed now and have no screen/display issues.
* plasma5-workspace-
* xorg-x11-server-7.6_1.18.0-2.1.x86_64
* kernel-default-4.3.3-3.1.x86_64

So is this really a kde plasma5 issue?

Martin Kho
Comment 10 Rex Dieter 2016-01-04 10:12:40 EST
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.
Comment 11 Rex Dieter 2016-01-04 12:46:08 EST
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.
Comment 12 Jan Grulich 2016-01-06 07:14 EST
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.
Comment 13 eddy02 2016-01-07 03:53:13 EST
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 
rawhide installation.

If not, got a black screen, but i can run plasma apps (dolphin ...) with krunner.
Seem to be a plasma-workspace config problem.
Comment 14 dominique 2016-01-07 05:01:21 EST
(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 
> /usr/share/kde-settings/kde-profile/default/share/plasma/shells/org.kde.
> plasma.desktop  directory  after every 
> rawhide installation.
> If not, got a black screen, but i can run plasma apps (dolphin ...) with
> krunner.
> 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.
Comment 15 Martin Kho 2016-01-07 08:16:33 EST

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)
"Error: org.freedesktop.DBus.Error.NoReply
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...


Martin Kho
Comment 16 Martin Kho 2016-01-07 12:50:45 EST

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.


Martin Kho
Comment 17 nucleo 2016-01-07 12:57:06 EST
Still black screen after removing ktp* in my Rawhide vm.
Comment 18 Martin Kho 2016-01-07 13:01:55 EST
Hi Nucleo,

Did you reboot your vm? Logout isn't enough, because some processes keep running. Is the ktp Aprover still loaded (qdbus-qt5)


Martin Kho
Comment 19 nucleo 2016-01-07 13:14:48 EST
Yes, black screen after vm reboot.
Comment 20 Martin Kho 2016-01-07 13:24:41 EST
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?

Martin Kho
Comment 21 nucleo 2016-01-07 13:41:34 EST
After removing org.kde.plasma.desktop directory plasmashell starts fine.
Comment 22 Rex Dieter 2016-01-07 15:50:17 EST
OK, I can confirm that the mere presence of 
makes things go horribly bad.

* Thu Jan 07 2016 Rex Dieter <rdieter@fedoraproject.org> 23-10
- revert prior commit, use prefix/plasma/shells/<package>/contents/updates instead
Comment 23 Jan Grulich 2016-01-08 03:17:54 EST
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.
Comment 24 Rex Dieter 2016-01-08 09:42:13 EST
*** Bug 1296912 has been marked as a duplicate of this bug. ***
Comment 25 Rex Dieter 2016-01-08 09:45:43 EST
<nod>, there's definitely multiple problems here, the kde-settings snafu was one of them.
Comment 26 Martin Kho 2016-01-08 10:36:50 EST

...but my impeacement of ktp-* was wrong. I've re-installed it and everything is still fine. Sorry for the noise :-(

Martin Kho
Comment 27 Rex Dieter 2016-01-08 13:22:18 EST
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).
Comment 28 Rex Dieter 2016-01-08 14:14:28 EST
* Fri Jan 08 2016 Rex Dieter <rdieter@fedoraproject.org> - 5.5.3-2
- avoid kde4breeze.upd, causes problems for new users (#1283348)
Comment 29 Adam Williamson 2016-01-13 17:08:40 EST
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
Comment 30 Rex Dieter 2016-01-19 10:23:21 EST
OK, another possible issue,
Comment 31 Adam Williamson 2016-02-22 13:57:45 EST
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?
Comment 32 Giulio 'juliuxpigface' 2016-02-22 14:27:07 EST
It seems fixed here too.

I installed the 20160220 compose - on qemu-kvm - and I haven't hit this.
Comment 33 Felix Miata 2016-02-24 02:57:24 EST
(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.
Comment 34 Adam Williamson 2016-02-24 03:00:39 EST
That doesn't really sound like the same bug...
Comment 35 Felix Miata 2016-02-24 03:16:43 EST
(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.
Comment 36 Jan Kurik 2016-02-24 10:31:58 EST
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:
Comment 37 Adam Williamson 2016-02-29 13:14:14 EST
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!
Comment 38 Felix Miata 2016-03-03 05:13:07 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.