Bug 448006 - kickstart cannot retrieve bootfile from dhcp
Summary: kickstart cannot retrieve bootfile from dhcp
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda
Version: 5.2
Hardware: i686
OS: Linux
Target Milestone: rc
: ---
Assignee: David Cantrell
QA Contact: Marian Ganisin
Keywords: Regression
Depends On:
TreeView+ depends on / blocked
Reported: 2008-05-22 20:37 UTC by K. Scott Rowe
Modified: 2018-10-20 02:42 UTC (History)
17 users (show)

Clone Of:
Last Closed: 2009-09-02 09:52:48 UTC

Attachments (Terms of Use)
anaconda-bootfile.patch (3.70 KB, patch)
2009-07-01 03:03 UTC, David Cantrell
no flags Details | Diff
0001-Save-bootfile-if-we-have-it-from-DHCP-response-44800.patch (4.29 KB, patch)
2009-07-02 19:56 UTC, David Cantrell
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:1306 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2009-09-01 10:20:11 UTC

Description K. Scott Rowe 2008-05-22 20:37:18 UTC
Description of problem:

Version-Release number of selected component (if applicable):
dhcp-3.0.1rc14 on Solaris8 and dhcp-3.0.5-7.el5 on RHEL5.1

How reproducible:
This happens every time on both machines tried against both dhcpservers tried.

Steps to Reproduce:
1. setup a host decloration in dhcp with filename and next-server for kickstart
2. boot from the 5.2 CD with "ks text" 
Actual results:
looking at ctrl-alt-f3 I see the following...
  DHCPv4 eth0 - option rouiters:
  no DNS servers, can't look up hostname
  doing kickstart... setting it up
  bootp: bootfile is (null)
  url is
  file location: nfs://(null):/

Expected results:
I would expect bootfile to what filename is defined as in the dhcp host
decloration instead of just (null).

Additional info:
Have same problem with x86_64 media.

Comment 1 Chris Tatman 2008-06-04 02:24:13 UTC

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;
        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 to 00:1c:23:20:64:68
via eth0
Jun  3 21:15:49 blacksamba dhcpd: DHCPREQUEST for (
from 00:1c:23:20:64:68 via eth0
Jun  3 21:15:49 blacksamba dhcpd: DHCPACK on 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
file location: nfs://(null)/
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
file location: nfs://

**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?

Comment 2 Chris Tatman 2008-06-04 14:38:10 UTC
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.

Comment 3 RHEL Product and Program Management 2008-06-16 14:24:43 UTC
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.

Comment 4 Chris Lumens 2008-07-11 16:02:43 UTC
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.

Comment 5 Chris Lumens 2008-07-15 19:09:45 UTC
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.

Comment 6 K. Scott Rowe 2008-07-16 16:20:19 UTC
Just so you know, we also have a support ticket open about this at
support.redhat.com.  The ticket number is 1832374.

Comment 7 Tru Huynh 2008-07-17 16:58:17 UTC
it's hitting CentOS-5.2 too (of course!)

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

Comment 11 David Cantrell 2009-07-01 03:02:05 UTC
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).

Comment 12 David Cantrell 2009-07-01 03:03:10 UTC
Created attachment 350049 [details]

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

Comment 13 RHEL Product and Program Management 2009-07-01 03:13:27 UTC
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

Comment 14 David Cantrell 2009-07-02 19:56:34 UTC
Created attachment 350330 [details]

Latest patch.

Comment 15 David Cantrell 2009-07-02 19:58:57 UTC
Committed to rhel5-branch.  The fix will be in anaconda-

Comment 22 Marian Ganisin 2009-07-30 09:25:17 UTC
Verfifed with Snapshot 4 on architectures i386, x86_64. Issue fixed, file retrieval is working fine

Comment 23 Alexander Todorov 2009-07-31 11:37:09 UTC
moving to VERIFIED as per comment #22

Comment 25 errata-xmlrpc 2009-09-02 09:52:48 UTC
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.


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