Description of problem: dhcpd running on FC4 with a relatively simple configuration, that offers per-client kickstart files, works just fine. On FC5, the very same configuration fails, and the client reports errors trying to reach 0.0.0.0:/path/file.ks, such that the kickstart install fails. If I specify ks=nfs:<dhcpserver>:/path/file.ks on the client's boot prompt, instead of just ks, then the install succeeds. I don't have a next-server declaration in the server's dhcpd.conf, but the docs say that implies the server's IP address is used instead. I think I actually tried to add next-server explicitly the other day, to no avail. Version-Release number of selected component (if applicable): dhcp-3.0.3-26 How reproducible: Every time Steps to Reproduce: 1.Set up a dhcp server such that it tells a client to use a certain file from itself as the kickstart file 2.Boot up the installer on the client with `ks ksdevice=eth0´ Actual results: No luck getting the kickstart file from host 0.0.0.0 Expected results: Same as on FC4, where it worked just fine with the same configuration Additional info:
With the upstream ISC DHCP 3.0.3 release, they removed support for providing a default siaddr setting of the dhcp server's address, as this contravenes the RFC, and prevents the use of explicit next-server or tftp-boot-server options on many clients. To set the tftp-boot-server address, place this setting in /etc/dhcpd.conf in the same scope as your boot clients: next-server = config-option dhcp-server-identifier; or next-server XXX.XXX.XXX.XXX; where XXX.XXX.XXX.XXX is the address of the dhcpd server. If a valid next-server IP address is in scope, I've never seen a boot client fail to get the "filename" with tftp - note also that for PXE tftp download of the boot file to work, these dhcpd.conf statements must be in scope: allow booting; allow bootp; next-server = config-option dhcp-server-identifier; filename "/linux-install/pxelinux.0"; and the /etc/xinetd.d/tftp service on the next-server must have 'disabled=no' and 'server_args = -s /tftpboot' . Under these conditions, I've never seen the tftp boot to fail - if it fails for you, please gather a tcpdump of dhcp traffic on the server while a failed client session is in progress: # tcpdump -nl -vvv -i any -s 8192 port bootps or port bootpc \ >/tmp/tcpdump.bootp.log 2>&1 & and send me the /tmp/tcpdump.bootp.log file. I guess I'll be updating a future version of dhcpd to set the siaddr field to its IP address by default, retaining legacy behavior, IFF: o no next-server option is specified in scope o no server-name option is specified in scope o no tftp-server-name option is specified in scope o no new 'no-default-next-server on;' option is specified in scope. it is because setting the siaddr overrides ALL the other ways of specifying the tftp server in many clients, which contravenes the RFC, that the ISC stopped making the server set the siaddr by default.
Aha! When I re-read the docs, I thought I'd tried next-server and it didn't fix it, but your explanation I recalled I'd actually tried server-name. I've just tried next-server and that restored the kickstart functionality I liked. Thanks!