I am having a similiar problem. The OS I'm using to put out via kickstart is RHEL AS4u5 32bit. Though it doesn't matter which OS I use as the OS to put out via kickstart. Same problem with any version of the 32 and 64 bit versions of RHEL AS4, as well as Fedora 7 and RHEL5.
The anaconda portions of the boot (with DHCP and tftp) go very well. I can see in VC3 and VC4 that the booted system gets all the right network attributes and have carefully verified them (hostname, IP, GW, dns, NM, broadcast, network, next_server, and domain). In VC3, eventually, I get the error message "reverse name lookup failed", then it says "failed to mount nfs source". It displays a url and file location, both of which are, in fact, correct. Efforts at toying with various anaconda options for the pxeconfig isolinux file provide no improvement.
On the kickstart server, I configure it for use of a MAC address for another system that I've successfully kickstarted before (within dhcp and the tftp/pxeconfig link), boot that other system and the installation goes perfectly to completion. The nfs mount occurs instantly here, where it times out and fails on the other server. I switch the MAC address back on the kickstart server to the problem box (no other changes to this world) and the NFS fails at the same point again. When manually attempting to continue the build interactively, the information is given for the NFS server (192.168.10.2) and the directory (/kickstart/ks-files/ks.cfg) but always results in the error message "That directory could not be mounted from the server". Yet a manually built VM, on the same physical server where the kickstarted VM is can immediately mount the exact same path without fail.
The physical network is a 4-port Linksys hub (yes hub), 1 PC with Fedora 7 installed and configured for the kickstart server, one Dell XPS laptop with VMware Workstation v6 installed (32 bit VM's kickstarted into here always install successfully) and a MacPro with Windoze XP 64 bit installed and it also has VMware Workstation v6 installed (32/64bit VM's kickstarted into here ALWAYS exhibit the problems outlined above). Regardless of isolating this hub from the internet or making it standalone, the results are the same.
To do other troubleshooting, I've 'shared' the C: drive of the MacPro, mapped it into a drive letter on the Dell, pointed VMware on the Dell to the mounted filesystem on the Mac for the 'problem' VM and it boots, installs to completion 3 times in a row. I try it natively on the Mac again, with failure as before. I've temporarily replaces Windoze XP on the Mac with Windoze 2003, and the VM died at the same place.
Also, I can successfully manually build, via ISO image any RHEL AS4, RHEL5, Fedora 7 OS I want, either 32 and/or 64 bit on the MacPro. Subsequently to the build, NFS mounts work correctly.
Unfortunately, entries to the RedHat kickstart mailing list didn't provide any useful help. One suggestion was to switch over to squid and apache on the kickstart server and 'try' that. Not good suggestions for me in resolving an NFS problem within anaconda. My customer has a pretty widely installed base deployed via NFS based kickstart servers. Nor am I familiar with squid/apache and their complexities.
Reviews of /var/log/messages on the kickstart server show only normal DHCP handshacking. No DNS, DHCP or NFS errors. Any suggestions on what I can do to temporarily elevate the volume of messages those services provide into syslog, or some other log file for review for problems that I'm not aware of yet??? Any suggestions on what I can do to further troubleshoot this NFS mount problem?
R,
-Joe
R,
-Joe Wulf, RHCSA(RHEL6), FITSP-D, CISSP, VCP3, CPO(USN/RET)
Senior IA Design Engineer/ISSE
