Bug 871129 - Network is considered 'up' even if DHCP fails
Network is considered 'up' even if DHCP fails
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
All All
unspecified Severity high
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
AcceptedNTH RejectedBlocker
:
Depends On:
Blocks: F18Beta-accepted/F18BetaFreezeExcept
  Show dependency treegraph
 
Reported: 2012-10-29 13:28 EDT by Adam Williamson
Modified: 2012-11-08 04:39 EST (History)
8 users (show)

See Also:
Fixed In Version: anaconda-18.22-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-08 04:39:56 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2012-10-29 13:28:54 EDT
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 07:46:11 EDT
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 12:38:32 EDT
(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 12:46:58 EDT
(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 12:52:47 EDT
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-10-31 22:51:36 EDT
anaconda-18.22-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.22-1.fc18
Comment 6 Fedora Update System 2012-11-01 14:27:18 EDT
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:
https://admin.fedoraproject.org/updates/FEDORA-2012-17432/anaconda-18.22-1.fc18
then log in and leave karma (feedback).
Comment 7 Fedora Update System 2012-11-02 00:06:06 EDT
anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.23-1.fc18
Comment 8 Fedora Update System 2012-11-02 21:05:34 EDT
anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.24-1.fc18
Comment 9 Tom Lane 2012-11-04 11:44:54 EST
Works for me now in Beta-TC7.
Comment 10 Adam Williamson 2012-11-05 16:33:49 EST
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 17:24:39 EST
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 18:47:34 EST
(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 18:58:10 EST
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-05 20:40:43 EST
anaconda-18.25-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.25-1.fc18
Comment 15 Fedora Update System 2012-11-06 21:12:46 EST
anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.26-1.fc18
Comment 16 Adam Williamson 2012-11-08 04:39:56 EST
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.