Bugzilla – Bug 1074214
[Build 20171223] Live media (rescue) does not show 'openSUSE' menu
Last modified: 2019-03-22 12:48:28 UTC
## Observation openQA test in scenario opensuse-Tumbleweed-Rescue-CD-x86_64-rescue@64bit fails in [consoletest_finish](http://openqa.opensuse.org/tests/569250/modules/consoletest_finish/steps/13) ## 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
might have something to do with the switch to whiskermenu. Chencking... It seems to work in latest test? https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=Rescue-CD&test=rescue&machine=64bit&version=Tumbleweed is this still relevant? Is this a "sometimes failing" issue? I'm downloading snapshout20171223 iso right now and will test in a VM.
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
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.
Ok, I'll try harder...
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.
(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
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.
https://openqa.opensuse.org/tests/578094?flavor=Rescue-CD&test=rescue&arch=x86_64&machine=64bit&version=Tumbleweed&distri=opensuse&limit_previous=50#step/desktop_mainmenu/2 This seems still to happen (sometimes)
Bad. Unfortunately I have no idea how to debug this without a way to reproduce this :-(
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.
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.