Red Hat Bugzilla – Bug 20598
Installer won't determine hostname correctly (patch included)
Last modified: 2007-04-18 12:29:46 EDT
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
Passed to a developer to evaluate.
Modified code to try dns queries 3 times instead of twice. Helps problems on sparc, should help on i386.
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!)
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?
Jeremy please consider this patch.
Already done in CVS