Bug 448006 - kickstart cannot retrieve bootfile from dhcp
kickstart cannot retrieve bootfile from dhcp
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
5.2
i686 Linux
high Severity high
: rc
: ---
Assigned To: David Cantrell
Marian Ganisin
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-22 16:37 EDT by K. Scott Rowe
Modified: 2010-10-22 21:18 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:52:48 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)
anaconda-bootfile.patch (3.70 KB, patch)
2009-06-30 23:03 EDT, 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 15:56 EDT, David Cantrell
no flags Details | Diff

  None (edit)
Description K. Scott Rowe 2008-05-22 16:37:18 EDT
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" 
3.
  
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 146.88.1.9:(null)
  file location: nfs://(null):/146.88.4.128-kickstart


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-03 22:24:13 EDT
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?

Comment 2 Chris Tatman 2008-06-04 10:38:10 EDT
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 10:24:43 EDT
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 12:02:43 EDT
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 15:09:45 EDT
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 12:20:19 EDT
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 12:58:17 EDT
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 :(
Comment 11 David Cantrell 2009-06-30 23:02:05 EDT
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-06-30 23:03:10 EDT
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.
Comment 13 RHEL Product and Program Management 2009-06-30 23:13:27 EDT
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.
Comment 14 David Cantrell 2009-07-02 15:56:34 EDT
Created attachment 350330 [details]
0001-Save-bootfile-if-we-have-it-from-DHCP-response-44800.patch

Latest patch.
Comment 15 David Cantrell 2009-07-02 15:58:57 EDT
Committed to rhel5-branch.  The fix will be in anaconda-11.1.2.185-1.
Comment 22 Marian Ganisin 2009-07-30 05:25:17 EDT
Verfifed with Snapshot 4 on architectures i386, x86_64. Issue fixed, file retrieval is working fine
Comment 23 Alexander Todorov 2009-07-31 07:37:09 EDT
moving to VERIFIED as per comment #22
Comment 25 errata-xmlrpc 2009-09-02 05:52:48 EDT
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

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