On 5/24/06, Joshua Gimer <jgimer@xxxxxxxxx> wrote:
I would try commenting out the option for your tftp server in dhcp.conf. And see if the machine takes the lease. There is an ACK being sent back so the machine accepts the lease.
Keep in mind that kickstart via pxe. The first ACK is during PXE. It's the anaconda part that the client is not accepting the address offered by the dhcp server. Here's what I'm seeing: 1) during pxe, IP address is offered by dhcpd and accepted by client (machine doing kickstart) 2) the client machine downloads the kernel and ramdisk from the tftp server 3) kernel initialize, anaconda loads and performs ANOTHER dhcp request to obtain the IP address (KS file says to use DHCP). It's during this part when the ip address is offered by the dhcpd server repeatedly.
May 24 23:01:38 fong-31-100 in.tftpd [29880]: tftp: client does not accept options You notice that the machine requests the lease and then ACK before this, it is as if the machine is sending out the DHCP_DISCOVER and the server replies but the machine does not request the address. If this the case then you might think about putting the install files on an nfs share and then recreating your kickstart file with the nfs server information.
That's how I'm kicking. Again, this profile works fine on a different machine. I'm thinking that it's hardware related.
On 5/24/06, Jim Perrin <jperrin@xxxxxxxxx> wrote: > > dhcpd logs multiple discover requests follow by multiple offers. The > > client just won't accept the offer: > > It actually gets the IP, as there's a DHCPACK in the log. > If the client is refusing the address or the options for some reason, > then it's possible that it's a minor misconfiguration in the DHCP > server. > The dhcp server appears to be 192.168.1.1, according to the logs, is > it also the gateway (would be the routers stanza in the dhcpd.conf)? > Does the server declare itself as authoritative for the zone? > There are also occasionally things within the dhcpd.conf that need to > be set for pxe to work. Have you done these? > > > > > May 24 16:01:36 fong-31-100 dhcpd: DHCPDISCOVER from 00:07:e9:32:b8:46 via eth1 > > May 24 16:01:37 fong-31-100 dhcpd: DHCPOFFER on 192.168.1.254 to > > 00:07:e9:32:b8:46 via eth1 > > May 24 16:01:38 fong-31-100 dhcpd: DHCPREQUEST for 192.168.1.254 > > (192.168.1.1) from 00:07:e9:32:b8:46 via eth1 > > May 24 16:01:38 fong-31-100 dhcpd: DHCPACK on 192.168.1.254 to > > 00:07:e9:32:b8:46 via eth1 > > May 24 23:01:38 fong-31-100 in.tftpd[29880]: tftp: client does not > > accept options > > > > > The kickstart server (dhcp, tftp, etc.) and the machine being kicked > > (dhcp client) are directly connected via a crossover cable. > > > > > > On 5/24/06, Karanbir Singh <mail-lists@xxxxxxxxx> wrote: > > > Fong Vang wrote: > > > > > > > > Any idea what else to check for? Could it be that the e1000 driver in > > > > CentOS 4.3 x64 is older than the CentOS 4.1 driver? > > > > > > dont know about the rest of your issues, but the e1000 driver has > > > definitely been updated since 4.1 days... > > > > > > - KB > > > > > > -- > > > Karanbir Singh : http://www.karan.org/ : 2522219@icq > > > _______________________________________________ > > > CentOS mailing list > > > CentOS@xxxxxxxxxx > > > http://lists.centos.org/mailman/listinfo/centos > > > > > _______________________________________________ > > CentOS mailing list > > CentOS@xxxxxxxxxx > > http://lists.centos.org/mailman/listinfo/centos > > > > > -- > This message has been double ROT13 encoded for security. Anyone other > than the intended recipient attempting to decode this message will be > in violation of the DMCA > _______________________________________________ > CentOS mailing list > CentOS@xxxxxxxxxx > http://lists.centos.org/mailman/listinfo/centos > -- Thx Joshua Gimer _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
