Red Hat Bugzilla – Bug 863276
f18b anaconda white screen instead of the main hub, it currently only happens on a single kvm guest
Last modified: 2012-10-10 22:48:07 EDT
Created attachment 621834 [details]
the white (or gray/grey) screen
Description of problem:
In am not able to reach anaconda's main hub, but only on a certain KVM GUEST.
I don't know why yet.
* Increased memory from 1GB to 2GB
* Changed display from SPICE/QLX to VNC/CIRRUS
Issue: After 'i accept my fate', the screen remains empty (white/gray) as shown in the screenshot.
Update: I tried with F18b TC2 and it is the same.
Version-Release number of selected component (if applicable):
F18b TC1 & TC2
always (with this kvm guest)
Steps to Reproduce:
2. accept 'fate'
no main hub, installing is not possible
The anaconda is not hung, the mouse works, alt+tab works (nothing to switch to), alt+vt works. It just does not display the main hub. :-(
Created attachment 621835 [details]
Created attachment 621836 [details]
Created attachment 621837 [details]
Created attachment 621838 [details]
I can confirm this issue on F18 Beta TC1 Live KDE running on Thinkpad T410 (with nvidia graphics card)
Can we see /tmp/X.log as well?
Created attachment 622243 [details]
X.log (white screen after accepting fate)
My guess is we're hung in anaconda waiting for something - who knows what. Unless we can reliably reproduce this here to step through, or you feel like doing the debugging, though, I'm not optimistic.
I tried install gdb (to generate a core dump from anaconda) to the booted dvd but it was not possible because yum fails with a 'no module named yumain'.
So no gdb and no core dump.
Also there is no ifconfig on the dvd... not sure if a bug-report is needed for those or is it by design.
I can reliably reproduce the issue with F18 Beta TC2 KDE in VirtualBox.
Is there any way I can provide debug information? Is a GDB stacktrace of the Python process enough, or is there any Python version of GDB?
There's something called pdb for python, but the way I would approach debugging with that is to insert the following lines somewhere where the hub is getting set up:
Then switch over to tty1 when you know those lines get hit and start stepping through the code. Really, it would be easiest if I could reproduce this.
I was able to reach the main hub with F18b TC3 and the same guest.
Just in case i tested with both SPICE/QLX and VNC/Cirrus.
So, either it was fixed or it does not happen anymore with F18b TC3.
Unless everyone's now seeing success, I still think this is intermittent enough to be left open.
I found out that my problem is caused by an oxygen-gtk3 issue in the KDE spin and is unrelated to the original problem reported here.