Bug 20598 - Installer won't determine hostname correctly (patch included)
Summary: Installer won't determine hostname correctly (patch included)
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-11-09 17:51 UTC by Philip Spencer
Modified: 2007-04-18 16:29 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-09-17 19:03:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Philip Spencer 2000-11-09 17:51:09 UTC
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 21:30:01 UTC
Passed to a developer to evaluate.

Comment 2 Erik Troan 2000-11-20 16:31:11 UTC
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 15:04:27 UTC
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 17:16:04 UTC
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 19:03:43 UTC
Jeremy please consider this patch.

Comment 6 Jeremy Katz 2002-01-22 00:39:21 UTC
Already done in CVS


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