Bug 112683
| Summary: | Primary nameserver field on IP config screen cannot be corrected | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan Wakely <fedoration> | ||||||
| Component: | anaconda | Assignee: | Jeremy Katz <katzj> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike McLean <mikem> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 1 | CC: | 64bit_fedora, jos | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2005-06-24 12:18:11 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
(I should have explicitly said this is when entering IP conf manually,
not with DHCP)
This is only a guess, but from a quick perusal the problem seems to be
line 529 in anaconda-9.2/loader2/net.c:
if (!(cfg->dev.numDns)) {
if (c.ns && *c.ns && inet_aton(c.ns, &addr)) {
cfg->dev.dnsServers[0] = addr;
cfg->dev.numDns = 1;
}
}
Because of the outermost if() this seems to only use the user-supplied
nameserver, c.ns, if there are no nameservers already set - which
means once an incorrect address has been entered it cannot be updated
(which is the problem I'm seeing).
If I'm reading the code correctly, this block of code should only be
done when DHCP is not being used, and therefore should be done around
line 479 when the other user-supplied data are read.
Created attachment 96719 [details]
Allow nameserver to be changed after it is first set
This patch hasn't been tested, it hasn't even been compiled - so it might be
best to ignore it completely and start from scratch when fixing this bug.
Anyway, I provide it to embarrass myself when it's flaws are pointed out :-)
Created attachment 96721 [details]
Simpler patch to allow nameserver to be corrected
This is a less intrusive patch that simply checks whether we're configuring the
network manually (!cfg->isDynamic) and if so then a user-supplied nameserver
replaces any existing setting.
Again, this hasn't even been compiled, let alone tested!
Applied in CVS. *** Bug 120349 has been marked as a duplicate of this bug. *** |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-GB; rv:1.4) Gecko/20030703 Description of problem: While doing an HTTP install of the fc1_x86_64 preview at fedora.linux.duke.edu I mistyped my IP into the "Configure TCP/IP" screen, as 193.x.y.z instead of 192.x.y.z and the typo was propagated to the gateway and nameserver fields. After timing out finding the host name I went back to the TCP/IP config screen, fixed the three IP addresses to 192.*.*.* and tried again. The host name lookup timed out again, so I went back and found the nameserver field was still 193.x.y.z. No matter how many times I corrected this field the lookup seemed to be done with the original (incorrect) value and the field had the wrong value when I went back to it. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Choose "linux rescue" install over HTTP 2. Give wrong IP for nameserver in Configure TCP/IP screen and choose OK 3. Wait for name lookup to timeout and go Back 4. Correct nameserver IP and choose OK 5. GOTO 3 Actual Results: Nameserver field always retains original incorrect value, and name lookup done using incorrect value. The only way I could find to continue the install was to reboot. Expected Results: Second name lookup should use corrected nameserver value and succeed (step 5 of the steps-to-reproduce should be the next screen, not a goto). Additional info: This was only seen on the fc1_x86_64 preview - I haven't tried it on FC1 proper.