Since you have two hosts, and two network components on each host, it seems to make sense to start narrowing down the source of errors. The DHCP server can be tested from the client side (probably even as localhost
), using 'dhclient -d
'. This should report receipt of a valid IP for the client, and should cause the DHCP server to leave some information in your server's system logs. An example transcript follows:
$ su -c ' /sbin/dhclient -d'
Internet Systems Consortium DHCP Client V3.0.1
Copyright 2004 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
Listening on LPF/eth0/00:19:d1:81:8e:30
Sending on LPF/eth0/00:19:d1:81:8e:30
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPOFFER from xx.xx.xx.38
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from xx.xx.xx.38
bound to yy.yy.yy.22 -- renewal in 34082 seconds.
I see, now, that you have specified a filename in your DHCP configuration for the client. Conventionally, the filename specified here will be fetched from the server using tftp
(not NFS). I am unacquainted with the kickstart
procedure, so I will guess that the filename may be used by the kickstart client as an NFS-hosted file.
In either case, you should be able to test the server, be it TFTP (which you have not mentioned configuring) or NFS. In the case of TFTP:
$ tftp xx.xx.xx.38
tftp> get pxelinux.0
$ ls -lash pxelinux.0
16K -rw-r--r-- 1 owner group 14K Jun 10 14:11 pxelinux.0
Use your '/home/latitude/192.168.0.2-kickstart' filename (although, there may be issues with directory names prefixed to the filespec for a simple protocol like TFTP).
You can mount the NFS server from any host allowed in your /etc/exports
mount -t nfs server:/share/name /mount/point/on/localhost
Doing these diagnostics should illuminate where your problems are.