Description of problem: The installer hangs on launch from a VM (Vbox) that has a valid IP, but no internet access. Version-Release number of selected component (if applicable): Fedora-Live-Desktop-x86_64-19-Beta-TC3-1.iso anaconda 19.24-1 How reproducible: Always. Steps to Reproduce: 1. VirtualBox VM, network set to Bridge mode, valid IP address is assigned via DHCP, but there is no internet access. 2. Launch the installer. Actual results: Hang. No error message, no splash or language screen. Expected results: To allow installation anyway, as if there were no network connection, or to at least provide an error message. Additional info: If the VM is set to NAT or Off, the installer launches OK.
Proposing as beta blocker, violates alpha criteria: "The installer must run when launched normally from the release-blocking images."
Created attachment 744307 [details] anaconda.log
Created attachment 744308 [details] ifcfg.log
Created attachment 744309 [details] program.log
Created attachment 744310 [details] storage.log
Created attachment 744312 [details] anaconda-tb
Discussed at 2013-05-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-08/f19beta-blocker-review-4.2013-05-08-16.00.log.txt . Our general feeling was this isn't likely to be common enough to merit blocker status, but we thought it'd be best to experiment a bit to make sure. In particular it'd be good to know if it can be reproduced in similar bare metal or KVM configurations. We'd also like to know how long Chris waited for it to recover (though the logs indicate an actual traceback occurred, so it probably is a non-recoverable crash).
More than 5 minutes, less than 10? I'm unable to reproduce with a router providing DHCP for a valid IP, but with internet disconnected from the router. So it must be the port redirect is in place with hotels, airports, and airplanes intended to get you to pay for a session, and is causing anaconda's confusion. Since I can't reproduce with vbox, I'm also unable to reproduce the condition leading to the problem in order to test with qemu or bare metal.
Discussed at 2013-05-13 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-13/f19beta-blocker-review-5.2013-05-13-16.00.log.txt . Rejected as a blocker: it seems like it takes a very specific scenario to produce this effect, and there's an obvious workaround (disconnect from the hotspot or sign in to it).
I can't seem to reproduce this, so I'm not sure if it got fixed as part of something else or I just didn't get the right network conditions, but, based on the traceback: anaconda 19.24-1 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/__init__.py", line 547, in busyCursor window.set_cursor(Gdk.Cursor(Gdk.CursorType.WATCH)) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/__init__.py", line 303, in setup busyCursor() File "/sbin/anaconda", line 1078, in <module> anaconda._intf.setup(ksdata) AttributeError: 'NoneType' object has no attribute 'set_cursor' and the fact that it's a live install, my hunch is that it's an xauth vs. hostname thing like in bug 1045280. Can you try with F20, and if it's still an issue, can you try running the following command in a terminal before hitting "Install to Hard Drive": xhost +si:localuser:root