Bug 1074214 - [Build 20171223] Live media (rescue) does not show 'openSUSE' menu
[Build 20171223] Live media (rescue) does not show 'openSUSE' menu
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Xfce
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2017-12-29 08:27 UTC by Dominique Leuenberger
Modified: 2019-03-22 12:48 UTC (History)
3 users (show)

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

freshly booted openSUSE-Tumbleweed-Rescue-CD-x86_64-Snapshot20171223-Media.iso (440.57 KB, image/png)
2017-12-29 11:58 UTC, Stefan Seyfried

Note You need to log in before you can comment on or make changes to this bug.
Description Dominique Leuenberger 2017-12-29 08:27:36 UTC
## Observation

openQA test in scenario opensuse-Tumbleweed-Rescue-CD-x86_64-rescue@64bit fails in

## Reproducible

Fails since (at least) Build [20171009](http://openqa.opensuse.org/tests/502098)

## Expected result

Last good: (unknown) (or more recent)

## Further details

Always latest result in this scenario: [latest](http://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=Rescue-CD&test=rescue&machine=64bit&version=Tumbleweed)

## More information

The 'openSUSE' application menu is not shown in the bottom left area, pressing alt-f1 though does show the menu. This is apparently only happening on the live medium
Comment 1 Stefan Seyfried 2017-12-29 11:51:14 UTC
might have something to do with the switch to whiskermenu. Chencking...

It seems to work in latest test?

is this still relevant?
Is this a "sometimes failing" issue?

I'm downloading snapshout20171223 iso right now and will test in a VM.
Comment 2 Dominique Leuenberger 2017-12-29 11:53:49 UTC
The issue is showing every now and then - and on restart of the medium disappears again.

See the history of the test - whenever desktop-main-manu fails, it's this issue
Comment 3 Stefan Seyfried 2017-12-29 11:58:34 UTC
Created attachment 754422 [details]
freshly booted openSUSE-Tumbleweed-Rescue-CD-x86_64-Snapshot20171223-Media.iso

right now I only have VirtualBox (Windows Host) to test, but I will try with qemu at home, later. I cannot really imagine a difference, though.
Comment 4 Stefan Seyfried 2017-12-29 11:59:02 UTC
Ok, I'll try harder...
Comment 5 Stefan Seyfried 2017-12-30 09:56:03 UTC
I cannot reproduce this locally. The only thing that I can see (funnily especially when giving the VM more than one CPU) is, that it often takes a considerable amount of time after loggin in the livecd user until the panel is completely displayed, so for quite a long time there is only the "show desktop" icon on the left side and the desktop-switcher, clock and "live cd user" button on the right, before the whiskermenu button (opensuse menu) on the left appears. But it still appears before Powermanager, Pulseaudio and NetworkManager plugin appear (in this order), so it still does not really match the 569250 failure, as there power manager, pulseaudio and networkmanager plugins are displayed.

Sorry, but since I cannot reproduce it, I have no real way of debugging it.

I think I have seen something similar recently on real hardware (rescue iso on an USB stick) on first login no menu, log out and back in and system was happily ever after, so I will also retry on real hardware.

JFTR: this is how I try the live iso (varying amounts of memory and CPUs):
qemu-system-x86_64 -smp 2 -m 2048 -accel kvm -cdrom openSUSE-Tumbleweed-Rescue-CD-x86_64-Snapshot20171213-Media.iso -vga qxl

Can we find out how the VM is started in openQA (preferrably without me reading all the openqa code ;-)? Maybe there is something that makes it easier to trigger the issue.
Comment 6 Dominique Leuenberger 2017-12-30 10:11:19 UTC
(In reply to Stefan Seyfried from comment #5)
> Can we find out how the VM is started in openQA (preferrably without me
> reading all the openqa code ;-)? Maybe there is something that makes it
> easier to trigger the issue.

On every test, in the Assets&Logs tab, there is an autoinst-log.txt, which contains the call used for qemu to get the VM spun up
Comment 7 Stefan Seyfried 2017-12-30 13:22:22 UTC
I found out why it took so long to spin up the session: XAUTHLOCALHOSTNAME was not set in systemd-user session and this lead to failures in starting xfce-notifyd and at-spi-bus-foo.
I fixed this in obs://home:seife:xfce/xfce4-session/xfce4-session-systemd-user-addons.patch
I will submit this, soon after a few more tests.

Let's see if this helps the issue (or at least helps hiding it in openQA ;-))
I'll still try reproducing it with the openQA qemu parameters.
Comment 9 Stefan Seyfried 2018-01-10 19:55:50 UTC
Bad. Unfortunately I have no idea how to debug this without a way to reproduce this :-(
Comment 10 Stefan Seyfried 2018-02-18 12:04:58 UTC
I have seen this in a VM installation of Leap 15, but before I was able to debug it (installing debuginfo etc), the whiskermenu plugin crashed, was restarted by xfce4-panel and then displayed correctly.
Comment 11 Vinzenz Vietzke 2019-03-22 12:48:28 UTC
I just tried to but could not reproduce this issue with TW Rescue CD 20190320 64bit in VirtualBox. Even after several reboots it didn't occur. 

As this report is quite old I guess it's obsolete and I will close it for now.