Bug 448006

Hello,

I'm seeing this same behavior as well.  Using a RHEL4.6 DHCP/DNS server. 
Booting with a RHEL5.2-Server GA DVD.  Here is the declaration from my
dhcpd.conf file:

        host zombie {
        hardware ethernet 00:1C:23:20:64:68;
        fixed-address 192.168.1.28;
        filename "/data/installs/kickstarts/";
        next-server blacksamba.midian.home.com;
        }
}

DHCP version:  dhcp-3.0.1-59.EL4

You can see in the syslogs on the server where the client is getting its IP address:

Jun  3 21:15:49 blacksamba dhcpd: DHCPDISCOVER from 00:1c:23:20:64:68 via eth0
Jun  3 21:15:49 blacksamba dhcpd: DHCPOFFER on 192.168.1.28 to 00:1c:23:20:64:68
via eth0
Jun  3 21:15:49 blacksamba dhcpd: DHCPREQUEST for 192.168.1.28 (192.168.1.10)
from 00:1c:23:20:64:68 via eth0
Jun  3 21:15:49 blacksamba dhcpd: DHCPACK on 192.168.1.28 to 00:1c:23:20:64:68
via eth0

However, looking at ctrl+alt+f3 on the client I see the following failure:

DHCPv4 eth0 - option routers:
no DNS servers, can't look up hostname
doing kickstart... setting it up
reverse name lookup worked
bootp: bootfile is (null)
url is 192.168.1.10:(null)
file location: nfs://(null)/192.168.1.28-kickstart
failed to mount nfs source

There are no messages on the NFS server about failed nfs mount attempts.  In
fact there are no messages concerning mount attempts at all.  It looks to me
like the 5.2 client is not able to forward resolve the NFS server.

Now compare this to what I see on the client console when booting the same
machine from a Fedora 7 or 8 DVD:

DHCPv4 eth0 - option routers:
doing kickstart... setting it up
reverse name lookup worked
bootp: bootfile is /data/installs/kickstarts/
url is 192.168.1.10:/data/installs/kickstarts/
file location: nfs://192.168.1.10://data/installs/kickstarts/192.168.1.28-kickstart

**Note the absence of the message complaining about there being no DNS servers?

And on the NFS server, I see the following NFS mount authentications:

Jun  3 22:16:44 blacksamba mountd[4261]: authenticated mount request from
zombie.midian.home.com:992 for /data/installs/kickstarts (/data/installs/kickstarts)

Could this problem be caused by a name resolution error?

Just had the chance to check this out with RHEL5.0 and RHEL5.1 DVDs.  Both of
those are working.  This issue only seems to manifest itself when booting with
RHEL5.2 media.

This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.

David - have you had a chance to investigate this and see what might be going
on?  Sounds like it might be related to libnl changes to me.

Since we are out of devel capacity for the 5.3 cycle, I am going to move this
bug to be reconsidered for 5.4.  We've got too many big things going on in this
release to give this the attention it deserves, and the possibility for causing
further bugs when touching this code is too high.

Just so you know, we also have a support ticket open about this at
support.redhat.com.  The ticket number is 1832374.

it's hitting CentOS-5.2 too (of course!)
http://bugs.centos.org/view.php?id=2975

a possible workaround is to have ks=nfs:server:/path on the commandline :(

This was a regression that was introduced while fixing another problem in the loader networking code.  Attaching a patch that fixes the issue (tested locally using a RHEL 5.3 tree).

Created attachment 350049 [details]
anaconda-bootfile.patch

Patch for rhel5-branch anaconda.  Makes sure loader captures the bootfile parameter if we get that from DHCP.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Created attachment 350330 [details]
0001-Save-bootfile-if-we-have-it-from-DHCP-response-44800.patch

Latest patch.

Committed to rhel5-branch.  The fix will be in anaconda-11.1.2.185-1.

Verfifed with Snapshot 4 on architectures i386, x86_64. Issue fixed, file retrieval is working fine

moving to VERIFIED as per comment #22

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1306.html