Bug 1091401 - empty KDE Desktop after ppc64 (BE) TW install
empty KDE Desktop after ppc64 (BE) TW install
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: KDE Workspace (Plasma)
Current
PowerPC-64 openSUSE Factory
: P5 - None : Normal (vote)
: ---
Assigned To: E-Mail List
E-mail List
https://openqa.opensuse.org/tests/665...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-30 13:50 UTC by Michel Normand
Modified: 2019-09-23 07:47 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
serial0.txt (182.63 KB, text/plain)
2018-06-20 09:41 UTC, Michel Normand
Details
bug1091401_20180719_id1006_serial0.log (213.84 KB, text/x-log)
2018-07-19 13:49 UTC, Michel Normand
Details
bug1091401_20180721_id1018_serial0.log (370.52 KB, text/x-log)
2018-07-23 14:44 UTC, Michel Normand
Details
restart_plasmashell_failure.png (127.04 KB, image/png)
2018-07-24 17:32 UTC, Michel Normand
Details
restart_plasmashell_failure_xauthority.png (101.87 KB, image/png)
2018-07-25 07:35 UTC, Michel Normand
Details
restart_plasmashell_failure_xdisplay_xauthority.png (100.89 KB, image/png)
2018-07-25 09:40 UTC, Michel Normand
Details
restart_plasmashell_failure_xauthority_dynamic.png (324.35 KB, image/png)
2018-07-25 14:56 UTC, Michel Normand
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michel Normand 2018-04-30 13:50:52 UTC
empty KDE Desktop after ppc64 (BE) TW install 20180427

There is no more "Home" or "Trash" icons on Desktop.

This is a follon-on of still open bug#1051056 
"KDE splash screen and Desktop have wrong color for ppc64 (BE)"

[Build 20180427] openQA test fails in first_boot
## Observation

openQA test in scenario opensuse-Tumbleweed-DVD-ppc64-RAID10@ppc64 fails in
[first_boot](https://openqa.opensuse.org/tests/665974/modules/first_boot/steps/2)


## Reproducible

Fails since (at least) Build [20180427](https://openqa.opensuse.org/tests/665974) (current job)


## Expected result

Last good: [20180425](https://openqa.opensuse.org/tests/663621) (or more recent)
(only with bypass needle)

## Further details

Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?test=RAID10&distri=opensuse&version=Tumbleweed&machine=ppc64&arch=ppc64&flavor=DVD)
Comment 1 Fabian Vogt 2018-05-02 09:10:37 UTC
I can't find any logs, we need at least the system journal.
Comment 4 Michel Normand 2018-06-19 09:53:03 UTC
I agree I still do not have any log yet (so keep needinfo flag)
With last openQA snapshot 20180615 the behavior has changed, there is a new error message (1)

I will try to follow related actions and capture data.

(1) https://openqa.opensuse.org/tests/693652#step/first_boot/21
  "The screen locker is broken and unlocking is not possible anymore.                     
   In order to unlock switch to a virtual terminal 'e.g. Ctrl+Alt.F2),                    
   log in and execute the command;
   loginctl unlock-session 1"
Comment 5 Michel Normand 2018-06-20 09:41:44 UTC
Created attachment 774635 [details]
serial0.txt

I finally captured few informations via the serial console (attached serial0.txt)
and not uploaded them because of known bug of polkit tracked by https://bugzilla.opensuse.org/show_bug.cgi?id=1093033

The captured "journalctl -b" is /tmp/journalctl.log in serial0.txt
Do you need something else for investigation ?
Comment 6 Fabian Vogt 2018-06-20 09:58:44 UTC
Looks like a dbus timeout, maybe a side effect of the polkit crash.

plasmashell[1890]: "Message recipient disconnected from message bus without replying"

To confirm this, can you provide a backtrace of the running plasmashell process? ("gdb -p $(pidof plasmashell) -ex "thread apply all bt" -ex "detach")
Comment 7 Michel Normand 2018-06-20 13:16:47 UTC
unable to try the suggested command, as "zypper in gdb" is failing because of previous bug#1093033. and I don't know how to install gdb in the initial Tumbleweed install phase.
Comment 9 Michel Normand 2018-07-19 13:49:28 UTC
Created attachment 777477 [details]
bug1091401_20180719_id1006_serial0.log

Now that polkit is working again, I was able to copy/paste in attached bug1091401_20180719_id1006_serial0.log the following data:
/tmp/bt_plasmashell.log the plasmashell backstrace.
/tmp/journalctl.log the journalctl

still have same message as in comment#6
plasmashell[2372]: "Message recipient disconnected from message bus without replying"

just in case this could be interesting I also captured a video.ogv (34MB) that is available remotely https://michelmno.fedorapeople.org/boo1091401_20180719/
video.ogv starting from install to not accessible KDE Desktop
        1mn44 reboot after install (grub menu)
        1mn47 quick display of TW buble lamp
              then steady X screen with simple arrow
        2mn04 after timeout switch to console to capture data
                in serial0.txt are reported:
                /tmp/bt_plasmashell.log
                /tmp/journalctl.log
        2mn24 switch back to X, but still hang with single X arrow
Comment 10 Fabian Vogt 2018-07-19 14:43:49 UTC
(In reply to Michel Normand from comment #9)
> Created attachment 777477 [details]
> bug1091401_20180719_id1006_serial0.log
> 
> Now that polkit is working again, I was able to copy/paste in attached
> bug1091401_20180719_id1006_serial0.log the following data:
> /tmp/bt_plasmashell.log the plasmashell backstrace.

That shows that V4 crashes, but unfortunately the trace isn't helpful without debug info. Can you install it and redo the backtrace?

Does it work if plasmashell is restarted with the QV4_FORCE_INTERPRETER=1?
Comment 11 Michel Normand 2018-07-23 14:44:10 UTC
Created attachment 777769 [details]
bug1091401_20180721_id1018_serial0.log

in attached serial console bug1091401_20180721_id1018_serial0.log, there is startshell backtrace with debuginfo. (paste of /tmp/bt_plasmashell_debug.log)

I failed to try to restart plasmashell, will try later.
Comment 12 Michel Normand 2018-07-24 17:32:57 UTC
Created attachment 777904 [details]
restart_plasmashell_failure.png

Hello Fabian,
how is supposed to be restarted plasmashell with QV4_FORCE_INTERPRETER=1 ?
I tried directly from root console
but as reported by attached image there are failing messages.
Comment 13 Fabian Vogt 2018-07-24 17:47:58 UTC
(In reply to Michel Normand from comment #12)
> Created attachment 777904 [details]
> restart_plasmashell_failure.png
> 
> Hello Fabian,
> how is supposed to be restarted plasmashell with QV4_FORCE_INTERPRETER=1 ?
> I tried directly from root console
> but as reported by attached image there are failing messages.

Yes, it doesn't have the right x11 cookie.
You can either start it from the X session (not sure how though, as both plasmashell and krunner aren't available, maybe xterm in autostart) or run this in the root console:

env XAUTHORITY=/run/sddm/* QV4_FORCE_INTERPRETER=1 plasmashell
Comment 14 Michel Normand 2018-07-25 07:35:49 UTC
Created attachment 777940 [details]
restart_plasmashell_failure_xauthority.png

(In reply to Fabian Vogt from comment #13)
> [CUT] ...
> env XAUTHORITY=/run/sddm/* QV4_FORCE_INTERPRETER=1 plasmashell

next trial with XAUTHORITY setup did not change the errors as detailed in new attached image restart_plasmashell_failure_xauthority.png
Comment 15 Fabian Vogt 2018-07-25 08:04:10 UTC
(In reply to Michel Normand from comment #14)
> Created attachment 777940 [details]
> restart_plasmashell_failure_xauthority.png
> 
> (In reply to Fabian Vogt from comment #13)
> > [CUT] ...
> > env XAUTHORITY=/run/sddm/* QV4_FORCE_INTERPRETER=1 plasmashell
> 
> next trial with XAUTHORITY setup did not change the errors as detailed in
> new attached image restart_plasmashell_failure_xauthority.png

Right, DISPLAY=:0 might also be necessary:

env DISPLLAY=:0 XAUTHORITY=/run/sddm/* QV4_FORCE_INTERPRETER=1 plasmashell
Comment 16 Michel Normand 2018-07-25 09:40:19 UTC
Created attachment 777950 [details]
restart_plasmashell_failure_xdisplay_xauthority.png

Adding XDISPLAY=:0 now reports "No protocol specified" as per new attached png
Comment 17 Fabian Vogt 2018-07-25 11:12:07 UTC
(In reply to Michel Normand from comment #16)
> Created attachment 777950 [details]
> restart_plasmashell_failure_xdisplay_xauthority.png
> 
> Adding XDISPLAY=:0 now reports "No protocol specified" as per new attached
> png

That means the XAUTHORITY=/run/sddm/* part didn't work.

What's the output of rcxdm status? It should list a /run/sddm/* path, what happens if you export that as $XAUTHORITY manually?
Comment 18 Michel Normand 2018-07-25 14:56:43 UTC
Created attachment 777988 [details]
restart_plasmashell_failure_xauthority_dynamic.png

as suggested I dynamically set the XAUTHORITY variable from the file name in /run/sddm/ dir, and now the startshell seems to be started.
BUT as detailed in attached image the startshell failed to start with many error messages.
Comment 19 Michel Normand 2018-07-31 07:01:54 UTC
Hi Fabian,
any other comment or suggestion after data reported last week ?
Comment 20 Fabian Vogt 2018-07-31 07:12:06 UTC
(In reply to Michel Normand from comment #19)
> Hi Fabian,
> any other comment or suggestion after data reported last week ?

It looks to me like it works as intended, is plasma running on tty7?

If that's the case it's a bug in the V4 JIT and I'll report that upstream.

Until it's fixed we can probably disable V4 on ppc64.
Comment 21 Fabian Vogt 2018-07-31 07:27:39 UTC
(In reply to Fabian Vogt from comment #20)
> (In reply to Michel Normand from comment #19)
> > Hi Fabian,
> > any other comment or suggestion after data reported last week ?
> 
> It looks to me like it works as intended, is plasma running on tty7?
> 
> If that's the case it's a bug in the V4 JIT and I'll report that upstream.
> 
> Until it's fixed we can probably disable V4 on ppc64.

Nope - I'm wrong here: There is no JIT support for ppc (any kind) so this can't possibly make a difference.

As I don't want to dig into V4 myself a upstream bug report is the best option, but we need a minimal reproducer here.

Please try:

echo -e "import QtQuick 2.0\nRectangle {}" > test.qml
DISPLAY=:0 XAUTHORITY=(whatever you need) qmlscene test.qml

and if that crashes, please collect a backtrace.
Comment 27 Michel Normand 2019-09-23 07:47:48 UTC
no more failure since snapshot 20190920 so change status.
BUT desktop icon colors are not expected ones, tracked by bug#1051056