Splitting off from Tom Lane's report in https://bugzilla.redhat.com/show_bug.cgi?id=855526#c29 .
It seems that if you have a network connection 'up' at the physical level, but DHCP doesn't work - so you have no IP address, DNS resolution etc - newUI/NM still consider the connection 'up'. As described by Tom this means that in such a case, where static network configuration is required, there's no way to get the installer to work; I guess either you can't reconfigure it to static networking or, even if you do, the change isn't taken into account.
Nominating as a Beta blocker. If, as seems to be the case, this means you can't do a network install interactively in a static networking config, that's pretty bad. If it's actually workaroundable in the UI, I wouldn't be so worried. It may also be workaroundable by configuring the network via command line parameters for the installer, I guess, in which case I'd also be -1 and we could document the issue.
Tom / Radek, can you clarify the issues above for blocker consideration? Thanks!
You should be able to reconfigure the device in network spoke invoked from hub, also command line parameters should work. But still, the information in the hub (connected) is incorrect and the pre-hub network configuration step is skipped.
I'd vote for NTH at least. I have a patch fixing the issue ready.
(In reply to comment #1)
> I'd vote for NTH at least.
Yeah. There's a possibly independent issue that if the pre-hub network config step is skipped, and you manage to get to the hub screen with nonfunctional networking, the "installation source" spoke is broken and it's very unclear how to get it to work after you've fixed the network config. You'd think that a change in networking would trigger an automatic re-eval of installation source, but no. The only way I've found so far to un-break the source config after fixing the network config is to intentionally put in a bogus URL in the source screen, go back to the hub screen and let it fail again, then return to the source screen and reset to "nearest mirror". It shouldn't be that unfriendly.
(In reply to comment #2)
> Yeah. There's a possibly independent issue
Oh, I see somebody already filed that as bug #870570
Discussed at 2012-10-31 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-31/f18beta-blocker-review-6.2012-10-31-16.00.log.txt . As this shouldn't actually prevent the use of such configs according to comment #1, only lead to some confusion and inconvenience, this is rejected as a blocker, but it is accepted as NTH on the basis that it's clearly annoying to fix up and can't be fixed with an update.
anaconda-18.22-1.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.22-1.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18.
anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18.
Works for me now in Beta-TC7.
Could this fix be causing the problem some testers are seeing where, when they reach the hub, Installation Source shows 'nothing selected' and they have to go in, change it to http://something, go out again, go back in, and change it back to 'closest mirror' to make it happy? see http://forums.fedoraforum.org/showpost.php?p=1612038&postcount=140 and other posts around there - nonamedotc and smr54 have both seen this, and I saw it a couple of times with an unofficial image I was testing.
http://jkeating.fedorapeople.org/updates.img has the fix for this bug reverted, so we can see if it causes the 'nothing selected' problem.
(In reply to comment #10)
> Could this fix be causing the problem some testers are seeing where, when
> they reach the hub, Installation Source shows 'nothing selected' and they
> have to go in, change it to http://something, go out again, go back in, and
> change it back to 'closest mirror' to make it happy?
Probably not, considering that behavior was seen before any of this stuff got fixed.
I'm betting that what you describe is a variant of bug #870570, and that network config updates are just one of several things that the installation-source code ought to be reacting to and is not. Changing that setting back and forth is just a workaround for its failure to notice relevant status changes on its own.
Tom: I know about 870570, but this problem doesn't really match it. That bug explains why working around it is such a PITA, but it doesn't explain why the bug happens at all, I wouldn't say. I've filed the race problem as https://bugzilla.redhat.com/show_bug.cgi?id=873468 .
anaconda-18.25-1.fc18 has been submitted as an update for Fedora 18.
anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18.
18.26 went stable. Closing. (Bodhi closing of bugs when updates go stable is currently broken). Note this does not appear to be anything to do with https://bugzilla.redhat.com/show_bug.cgi?id=873468 .