Bug 871129 - Network is considered 'up' even if DHCP fails
Summary: Network is considered 'up' even if DHCP fails
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: All
OS: All
Target Milestone: ---
Assignee: Radek Vykydal
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedNTH RejectedBlocker
Depends On:
Blocks: F18Beta-accepted, F18BetaFreezeExcept
TreeView+ depends on / blocked
Reported: 2012-10-29 17:28 UTC by Adam Williamson
Modified: 2012-11-08 09:39 UTC (History)
8 users (show)

Fixed In Version: anaconda-18.22-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-11-08 09:39:56 UTC
Type: Bug

Attachments (Terms of Use)

Description Adam Williamson 2012-10-29 17:28:54 UTC
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!

Comment 1 Radek Vykydal 2012-10-30 11:46:11 UTC
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.

Comment 2 Tom Lane 2012-10-30 16:38:32 UTC
(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.

Comment 3 Tom Lane 2012-10-30 16:46:58 UTC
(In reply to comment #2)
> Yeah.  There's a possibly independent issue

Oh, I see somebody already filed that as bug #870570

Comment 4 Adam Williamson 2012-10-31 16:52:47 UTC
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.

Comment 5 Fedora Update System 2012-11-01 02:51:36 UTC
anaconda-18.22-1.fc18 has been submitted as an update for Fedora 18.

Comment 6 Fedora Update System 2012-11-01 18:27:18 UTC
Package anaconda-18.22-1.fc18:
* 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).

Comment 7 Fedora Update System 2012-11-02 04:06:06 UTC
anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18.

Comment 8 Fedora Update System 2012-11-03 01:05:34 UTC
anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18.

Comment 9 Tom Lane 2012-11-04 16:44:54 UTC
Works for me now in Beta-TC7.

Comment 10 Adam Williamson 2012-11-05 21:33:49 UTC
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.

Comment 11 Adam Williamson 2012-11-05 22:24:39 UTC
http://jkeating.fedorapeople.org/updates.img has the fix for this bug reverted, so we can see if it causes the 'nothing selected' problem.

Comment 12 Tom Lane 2012-11-05 23:47:34 UTC
(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.

Comment 13 Adam Williamson 2012-11-05 23:58:10 UTC
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 .

Comment 14 Fedora Update System 2012-11-06 01:40:43 UTC
anaconda-18.25-1.fc18 has been submitted as an update for Fedora 18.

Comment 15 Fedora Update System 2012-11-07 02:12:46 UTC
anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18.

Comment 16 Adam Williamson 2012-11-08 09:39:56 UTC
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 .

Note You need to log in before you can comment on or make changes to this bug.