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: Very 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"; next-server 130.219.123.456; 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 130.219.123.456 --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 gnome 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.
Are these gigabit networking cards? What sort of switch are they connected to and is the switch set up to autonegotiate?
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.
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.
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.
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 ks=nfs:my_nfs_server:/my_path_to_ks.cfg. 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.
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.
poking around: my broadcom cards worth with update1, but not update2. My e1000 stuff doesn't work with either.
This bug exists in U3 for me under nfs, and http kickstart installs. With tyan 2735 motherboards.
This should be fixed with RHEL3 U4. Please file a new issue describing your exact hardware and symptoms with U4.