I'm trying to kicktart a CentOS 4.3 x86_64. However, anaconda is unabled to do dhcp, complaining about"no DHCP reply received". While tailing the log on the dhcp server, I clearly see a request come in and address is offered. This same machine kicks fine with CentOS 4.1 (32-bit). Since anaconda could potentially use a different NIC (this system contains 2 NICSs), I've tried plugging both interfaces into the kickstart network (I've seen interfaces swapped before) as a test.
I know that the CentOS 4.3 x64 setup I have works fine because I can kick a different hardware with it.
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?
Any help is appreciated.
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
I've done thousands of kicks before. I normally only get this problem if I have a system with multiple dissimilar NICs (eth0 during PXE may swap to become eth1 and vice versa). In this case, this hardware has the exact same e1000 NICs. This hardware kicks fine with CentOS 4.1 (32-bit) and Fedora Core 5. It just won't kick with CentOS 4.3 x64. However, another server (different hardware) kicks fine using this exact same CentOS 4.3 x64 kick.
dhcpd logs multiple discover requests follow by multiple offers. The client just won't accept the offer:
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 May 24 16:02:16 fong-31-100 dhcpd: DHCPDISCOVER from 00:07:e9:32:b8:46 via eth1 May 24 16:02:16 fong-31-100 dhcpd: DHCPOFFER on 192.168.1.254 to 00:07:e9:32:b8:46 via eth1 May 24 16:02:19 fong-31-100 dhcpd: DHCPDISCOVER from 00:07:e9:32:b8:46 via eth1 May 24 16:02:19 fong-31-100 dhcpd: DHCPOFFER on 192.168.1.254 to 00:07:e9:32:b8:46 via eth1 May 24 16:02:25 fong-31-100 dhcpd: DHCPDISCOVER from 00:07:e9:32:b8:46 via eth1 May 24 16:02:25 fong-31-100 dhcpd: DHCPOFFER on 192.168.1.254 to 00:07:e9:32:b8:46 via eth1 May 24 16:02:36 fong-31-100 dhcpd: DHCPDISCOVER from 00:07:e9:32:b8:46 via eth1 May 24 16:02:36 fong-31-100 dhcpd: DHCPOFFER on 192.168.1.254 to 00:07:e9:32:b8:46 via eth1 May 24 16:02:46 fong-31-100 dhcpd: DHCPDISCOVER from 00:07:e9:32:b8:46 via eth1 May 24 16:02:46 fong-31-100 dhcpd: DHCPOFFER on 192.168.1.254 to 00:07:e9:32:b8:46 via eth1 May 24 16:02:46 fong-31-100 dhcpd: DHCPDISCOVER from 00:07:e9:32:b8:46 via eth1 May 24 16:02:46 fong-31-100 dhcpd: DHCPOFFER on 192.168.1.254 to 00:07:e9:32:b8:46 via eth1
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@karan.org 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@centos.org http://lists.centos.org/mailman/listinfo/centos
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@karan.org 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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
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.
On 5/24/06, Jim Perrin jperrin@gmail.com 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@karan.org 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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org 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@centos.org http://lists.centos.org/mailman/listinfo/centos
On 5/24/06, Joshua Gimer jgimer@gmail.com 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@gmail.com 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@karan.org 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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org 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@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Thx Joshua Gimer _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 25/05/06, Fong Vang sudoyang@gmail.com wrote:
May 24 23:01:38 fong-31-100 in.tftpd [29880]: tftp: client does not accept options
Googling for "in.tftpd tftp: client does not accept options" returns lots of results which imply this is pretty typical when Kickstarting systems and doesn't prevent the boot/install process from working. And lots of stuff about Broadcom interfaces in particular.
That's how I'm kicking. Again, this profile works fine on a different machine. I'm thinking that it's hardware related.
Have you tried completely disabling one of the interfaces in the BIOS to see if this gets you any further?
Will.
I'ts hardware related. I have two supposedly similar machines from the same order. One kicks fine and not the other. BIOS setting is the same on both servers. This is strange.
anyway, thanks for all the responses.
On 5/26/06, Will McDonald wmcdonald@gmail.com wrote:
On 25/05/06, Fong Vang sudoyang@gmail.com wrote:
May 24 23:01:38 fong-31-100 in.tftpd [29880]: tftp: client does not accept options
Googling for "in.tftpd tftp: client does not accept options" returns lots of results which imply this is pretty typical when Kickstarting systems and doesn't prevent the boot/install process from working. And lots of stuff about Broadcom interfaces in particular.
That's how I'm kicking. Again, this profile works fine on a different machine. I'm thinking that it's hardware related.
Have you tried completely disabling one of the interfaces in the BIOS to see if this gets you any further?
Will. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Are these two machines connected to the same network switch ? i have dhcp problems in my kickstart too but it depends on which network switch the machine is connected ... i've asked the network admin guy to have a look at the port configuration (using cisco switches) because if i use another switch (or connect the same machine on a simple 3com hub linked behind a cisco one) the kickstart is ok ... I suppose it's the same problem ... FYI i have this problem with a IBM x306m with broadcom nic inside ...
On Fri, 2006-05-26 at 11:22 -0700, Fong Vang wrote:
I'ts hardware related. I have two supposedly similar machines from the same order. One kicks fine and not the other. BIOS setting is the same on both servers. This is strange.
anyway, thanks for all the responses.
On 5/26/06, Will McDonald wmcdonald@gmail.com wrote:
On 25/05/06, Fong Vang sudoyang@gmail.com wrote:
May 24 23:01:38 fong-31-100 in.tftpd [29880]: tftp: client does not accept options
Googling for "in.tftpd tftp: client does not accept options" returns lots of results which imply this is pretty typical when Kickstarting systems and doesn't prevent the boot/install process from working. And lots of stuff about Broadcom interfaces in particular.
That's how I'm kicking. Again, this profile works fine on a different machine. I'm thinking that it's hardware related.
Have you tried completely disabling one of the interfaces in the BIOS to see if this gets you any further?
Will. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 26/05/06, Fabian Arrotin fabian.arrotin@arrfab.net wrote:
Are these two machines connected to the same network switch ? i have dhcp problems in my kickstart too but it depends on which network switch the machine is connected ... i've asked the network admin guy to have a look at the port configuration (using cisco switches) because if i use another switch (or connect the same machine on a simple 3com hub linked behind a cisco one) the kickstart is ok ... I suppose it's the same problem ... FYI i have this problem with a IBM x306m with broadcom nic inside ...
In your instance you might want to request your network guys configure your ports or the whole switch (bar any ports involved in a spanning tree) in Portfast mode.
http://www.google.co.uk/search?hl=en&q=kickstart+portfast&meta=
Will.
-
Fabian Arrotin -
Fong Vang -
Jim Perrin -
Joshua Gimer -
Karanbir Singh -
Will McDonald