Bug 117748 - nfs mount fails when kickstarting using CD-ROM boot with DHCP
Summary: nfs mount fails when kickstarting using CD-ROM boot with DHCP
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda   
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-08 04:18 UTC by Ryan Golhar
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-01 15:23:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ryan Golhar 2004-03-08 04:18:39 UTC
Description of problem:

The NFS mount for the CD images fails when kickstarting using DHCP.  
I'm boot the client machine by CD-ROM and enter "linux ks" at the 
boot promt.  The kickstart file is read but the NFS mount fails

Version-Release number of selected component (if applicable):

RHEL WS 3 Update 1

How reproducible:


Steps to Reproduce:
1. Kickstart a machine with CD-ROM and enter "linux ks" at boot 
prompt.  Kickstart is able to obtain IP address and ks.cfg from 
DHCP/NFS server, however it reports it is unable to mount the NFS 
share specified in ks.cfg.  (I'm booting via CD cause I can't find 
the bootnet.img for RHEL W3.)
Actual results:

Install goes to interactive mode

Expected results:

Install goes unattended

Additional info:

Here's the important contents of my dhcpd.conf file:

	group {
		# used for kick-start
		filename "/kickstart/ks.cfg";
		host hydrogen {
			option host-name "hydrogen";
			hardware ethernet 00:0D:56:0A:60:0B;
			fixed-address 130.219.789.010;

Here's the important stuff from my kickstart file:

install nfs --server --dir /kickstart/RedHat
lang en_US.UTF-8
langsupport --default en_US.UTF-8 en_US.UTF-8
keyboard us
mouse genericwheelps/2 --device psaux
xconfig --card "Intel 865" --videoram 65536 --hsync 30-80 --vsync 56-
76 --resolution 1280x1024 --depth 24 --startxonboot  --defaultdesktop 
network --device eth0 --bootproto dhcp

I made /kickstart on the DHCP/NFS server an NFS share and can mount 
it from other machines without any problems.  When trying to 
kickstart, it obtains the correct IP address and network settings.  
It also reports that it found ks.cfg correctly as well.  It then 
reports that it wasn't able to mount the NFS share and goes to 
interactive install.  I can't figure out why, but wonder if its a 
timing issue?  These machines are 3.2 Ghz machines.

Comment 1 Jeremy Katz 2004-05-06 21:13:04 UTC
Are these gigabit networking cards?  What sort of switch are they
connected to and is the switch set up to autonegotiate?

Comment 2 Ryan Golhar 2004-05-07 04:53:48 UTC
Yes, the NIC cards are gigabit cards.  The switch is a Cisco switch 
running at 10 Mbps.  I'm not sure if its half or full duplex.  

When I changed the NFS mount from /kickstart to /products everything 
seemed to work correctly.  I tried switching it back to /kickstart 
and it failed.  I was able to mount /kickstart after building a 
machine using /products however.

Comment 3 seph 2004-05-10 14:32:24 UTC
I observed similar things. My dell precision 400 machines have onboard
intel gigabit cards. When plugged into netgear equipment the kickstart
would get dhcp (would ping too), but would fail to fetch the http ks
file. Manually continueing would use the network fine.

I saw this with both a netgear gigabit switch, and a 10/100 *hub*.
Using a linksyst switch worked, and using broadcom gigabit cards worked. 

I also saw this with both fedora core 1, and rhel.

Comment 4 Rebecca Hepper 2004-05-11 14:57:42 UTC
I have observed something similiar with RH 9.  I am kickstarting via 
a USB keychain device which contains my ks.cfg.  Kickstart fails to 
mount my NFS server and I receive an error "That directory could not 
be mounted from the server".  I hit 'ok' and a second screen prompts 
me for NFS server setup.  If I just accept what is there, the 
kickstart continues on unattended.

My custom system contains an Intel D865GBFLK motherboard which 
requires the e1000 module.  I get the above results when I am 
directory connected to the company network and when my network goes 
through a NetGear hub.

Comment 5 Shawn Sivy 2004-05-12 00:58:36 UTC
I have experience the same problems describe previously.  Using
tcpdump I found that the "next-server" specified in the DHCP config
file is not even contacted, i.e. no traffic is seen to the NFS server.
 The log messages seem to indicate it found the info via DHCP but
doesn't seem to do anything with it. I was able to get the kickstart
file recognized if I specified it on the boot loader line using

I was also getting the "That directory could not be mounted from the
server" message after the kickstart file was read.  I finally tried
adding a trailing slash to the nfs --dir=path/ option on the nfs line
in the kickstart file and that worked.  The docs don't mention this is
needed, and it wasn't needed in rh8.

Comment 7 Simon Lockhart 2004-06-22 07:00:07 UTC
I have experienced the same problem on Redhat WS 3u2, on a Dell PE750,
which also uses the e1000 driver.

This certainly appears to be a timing issue, as I've been able to
resolve the issue by editting anaconda-9.1.2/loader2/nfsinstall.c and
adding a sleep(5) before each of the two doPwMount() calls.

Not a proper fix, but hopefully this points people in the right direction.

Comment 8 seph 2004-08-03 19:11:50 UTC
poking around: my broadcom cards worth with update1, but not update2.
My e1000 stuff doesn't work with either.

Comment 9 Samuel Flory 2004-09-08 19:54:06 UTC
  This bug exists in U3 for me under nfs, and http kickstart installs.
 With tyan 2735 motherboards.

Comment 10 Jeremy Katz 2004-12-01 15:23:37 UTC
This should be fixed with RHEL3 U4.  Please file a new issue describing your
exact hardware and symptoms with U4.

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