Bug 20598 - Installer won't determine hostname correctly (patch included)
Installer won't determine hostname correctly (patch included)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-09 12:51 EST by Philip Spencer
Modified: 2007-04-18 12:29 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-09-17 15:03:50 EDT
Type: ---
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 Philip Spencer 2000-11-09 12:51:09 EST
Both the RedHat 6.2 and 7.0 installers, when using the de4x5 ethernet
driver and installing via NFS, fail to correctly determine the hostname.
After one has selected not to use DHCP, and manually entered an IP address
/ subnet mask / gateway, the installer initializes the ethernet driver then
tries a reverse name lookup before the ethernet driver has finished
initialization. This lookup fails.

This causes the installer to attempt its NFS mount under a hostname of
"localhost.localdomain", which causes no problems for us because our NFS
server ignores that incorrect hostname and looks at IP address only, but
could potentially cause problems for others.

On 6.2 (haven't checked on 7.0) this also causes the /etc/hosts file to be
incorrectly set up - even though you later get an opportunity to tell the
installer the correct hostname, it ignores this and associates
"localhost.localdomain" with the actual IP address instead of 127.0.0.1. As
a result, programs like ssh and rlogin (and some nfs mounts) don't work
until one manually fixes /etc/hosts.

The following patch fixes the problem (at the expense of a longer delay if
the network really is down). I'd appreciate it if this patch or something
similar/better could be included in the next bootnet.img.

--- anaconda-7.0.1/isys/dns.c.orig      Mon May  3 16:03:51 1999
+++ anaconda-7.0.1/isys/dns.c   Wed Nov  8 19:13:08 2000
@@ -112,6 +112,11 @@
 
     rc = doQuery(ipnum, T_PTR, &result, NULL);
 
+    if (rc) {
+        logMessage("DNS query failed; retrying in case ethernet wasn't
ready");
+        rc = doQuery(ipnum, T_PTR, &result, NULL);
+    }
+
     if (rc) 
        return NULL;
     else
Comment 1 Michael Fulbright 2000-11-09 16:30:01 EST
Passed to a developer to evaluate.
Comment 2 Erik Troan 2000-11-20 11:31:11 EST
Modified code to try dns queries 3 times instead of twice. Helps problems on
sparc, should help on i386.
Comment 3 Brock Organ 2000-12-13 10:04:27 EST
I am unable to see three different DNS lookup queries using the internal test
tree qa1213.0 ... instead, I only see one "reverse name lookup failed" log msg
on VC3 ... is it possibly querying 3 times, but only logging if all three failed
...?  (I just want to make sure I'm properly verifying the fix!)
Comment 4 Philip Spencer 2000-12-13 12:16:04 EST
Are you referring to the _res.retry parameter in dns.c? As far as I can tell
that parameter is being ignored. When I was first having the problem, increasing
the _res.retry parameter from 2 to 3 did not fix anything (nor did the timeout
appear to be noticeably longer, as it should have been if it really was trying
three times instead of two).

Leaving _res.retry set at 2, but performing a second call to doQuery (as in my
patch above), did fix the problem.

I had just assumed the resolver routines in the scaled-down kernel used by the
installer did not support the retry parameter, but perhaps there's some other
bug that's causing it to be ignored? Or perhaps it needs to be set as high as 4
instead of just 3?
Comment 5 Michael Fulbright 2001-09-17 15:03:43 EDT
Jeremy please consider this patch.
Comment 6 Jeremy Katz 2002-01-21 19:39:21 EST
Already done in CVS

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