Bug 112683 - Primary nameserver field on IP config screen cannot be corrected
Primary nameserver field on IP config screen cannot be corrected
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
1
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
: 120349 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-27 23:03 EST by Jonathan Wakely
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-24 08:18:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Allow nameserver to be changed after it is first set (715 bytes, patch)
2003-12-29 07:07 EST, Jonathan Wakely
no flags Details | Diff
Simpler patch to allow nameserver to be corrected (338 bytes, patch)
2003-12-29 07:18 EST, Jonathan Wakely
no flags Details | Diff

  None (edit)
Description Jonathan Wakely 2003-12-27 23:03:59 EST
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.
Comment 1 Jonathan Wakely 2003-12-29 06:50:28 EST
(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. 
Comment 2 Jonathan Wakely 2003-12-29 07:07:46 EST
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  :-)
Comment 3 Jonathan Wakely 2003-12-29 07:18:21 EST
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!
Comment 4 Jeremy Katz 2004-01-03 15:21:58 EST
Applied in CVS.
Comment 5 Jeremy Katz 2004-04-07 21:55:02 EDT
*** Bug 120349 has been marked as a duplicate of this bug. ***

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