Bug 871129
| Summary: | Network is considered 'up' even if DHCP fails | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
| Component: | anaconda | Assignee: | Radek Vykydal <rvykydal> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | anaconda-maint-list, g.kaviyarasu, jonathan, nonamedotc, robatino, rvykydal, tgl, vanmeeuwen+fedora |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | AcceptedNTH RejectedBlocker | ||
| Fixed In Version: | anaconda-18.22-1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-11-08 09:39:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 752664 | ||
|
Description
Adam Williamson
2012-10-29 17:28:54 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. (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. https://admin.fedoraproject.org/updates/anaconda-18.22-1.fc18 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). anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.23-1.fc18 anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.24-1.fc18 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. https://admin.fedoraproject.org/updates/anaconda-18.25-1.fc18 anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.26-1.fc18 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 . |