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. I tried: * Increased memory from 1GB to 2GB * Changed display from SPICE/QLX to VNC/CIRRUS No efect. 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 How reproducible: always (with this kvm guest) Steps to Reproduce: 1. boot 2. accept 'fate' Actual results: no main hub, installing is not possible Expected results: main hub Additional Info: 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] anaconda.log
Created attachment 621836 [details] program log
Created attachment 621837 [details] storage log
Created attachment 621838 [details] syslog
I can confirm this issue on F18 Beta TC1 Live KDE running on Thinkpad T410 (with nvidia graphics card) anaconda-18.12-1.fc18
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: import pdb pdb.set_trace() 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.