Bug 1283348

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.)


Links:
- 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

I also saw this

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

https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151117_Installation#Default_boot_and_install

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

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]
windowed plasmashell

How looks windowed plasmashell started from konsole.

FWIW,

I'm running openSUSE Tubleweed now and have no screen/display issues.
* plasma5-workspace-5.5.1.1-1.1.x86_64
* 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

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 
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.

(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.

Hi,

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...

HTH

Martin Kho

Hi,

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.

HTH

Martin Kho

Still black screen after removing ktp* in my Rawhide vm.

Hi Nucleo,

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

HTH

Martin Kho

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?

Martin Kho

After removing org.kde.plasma.desktop directory plasmashell starts fine.

OK, I can confirm that the mere presence of 
/usr/share/kde-settings/kde-profile/default/share/plasma/shells/org.kde.plasma.desktop
makes things go horribly bad.

kde-settings:
%changelog
* Thu Jan 07 2016 Rex Dieter <rdieter> 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.

Rex,

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

Martin Kho

Bisecting kconf_update scripts, I found this one to be problematic for me:
/usr/share/kconf_update/kde4breeze.upd
(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).

plasma-breeze:
%changelog
* Fri Jan 08 2016 Rex Dieter <rdieter> - 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,
https://bugs.kde.org/show_bug.cgi?id=358017

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:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

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.