DHCP failed booting to the PXE
-
i have FOG 1.2.0 installed on a Centos 6.7, when i try to boot “some” of the Dell or HP computers on PXE it takes long time to get the DHCP and after that it doesnt boot to the FOG menu
the error i got is:
no config method
dhcp failedFOG server 1.2.0
my DHCP is on Sophos devicesophos setting
code: 67 (bootfile-name)
name: bootfile-name
type:
text: undionly.kpxe
scope: global
comment:
code: next-server
name: next-server
type:
address: “i used the fog server name”
scope: global
comment:
code: 66(tftp-server-name)
name: tftp-server-name
type:
text: “i used FOG server IP address”
scope: global
comment: pxelinux.0
fog tftpp setting
FOG_TFTP_HOST “i used my fog ip address”
FOG_TFTP_PXE_KERNEL_DIR /var/www/html/fog/service/ipxe/
FOG_TFTP_PXE_KERNEL bzImage
FOG_KERNEL_RAMDISK_SIZE 127000
FOG_PXE_BOOT_IMAGE init.xz
FOG_PXE_IMAGE_DNSADDRESS “i used my dns address”
FOG_TFTP_PXE_KERNEL_32 bzImage32
FOG_PXE_BOOT_IMAGE_32 init_32.xz -
@saif said:
…when i try to boot “some” of the Dell or HP computers…
Do I get this right? Some PCs work but others don’t with your PXE setup?? Please provide picture(s) of the error(s) you see on screen.
-
@Sebastian-Roth yes some of them yes and some are no
i will attache a photo now
thx -
-
@saif Please try connecting a mini switch between that client you took the picture from and the cable that connects it to your LAN. See if you still have the problem with a mini switch in between.
-
@Sebastian-Roth you mean the signal is degraded?
-
@Sebastian-Roth it works thaaaaaaaanks a lot
-
@saif No the signal is not degraded but your main switch (where the client is connected to) does some kind of magic. Possibly it’s just spanning tree. Tell your network guys to configure “port fast” for all the client ports. But it could be an auto-negotiation issue as well - then you’d need to set static port speed on that main switch for this client’s port.
-
Just adding some background to what Sebastian posted.
During the pxe booting process there are 3 distinct transitions as each of the kernel(s) boot PXE ROM -> iPXE, iPXE->iPXE, and finally iPXE->FOG target OS [FOS]. Each one of these transitions causes the network link light to “wink” or go out for a second or two as the new booting kernel configures the network interface. If spanning tree is enabled, in normal mode, it takes about 30 seconds to the switch port to move to a forwarding state. Since the booting process is so fast, by the time the switch goes into the forwarding state its too late. So when this happens the developers will recommend that you put a mini or unmanaged switch between the target computer and then building switch for debugging purposes. These mini switches are dumb (which is a good thing) they just pass traffic and don’t do any advanced stuff. This also isolates the target computer’s network wink during booting from the building switch, so the Spanning Tree stays in the forwarding mode the whole time. If this is the case, then the recommendation is for you to contact your network people and to confirm that the building network ports are in RSTP, fast STP, or port-fast (depending on the switch manufacturer)
If the mini switch doesn’t work for debugging then we can focus on other things.
-
but why its happening ti the computers that far from the main switch while its not happening to the close ones ? that what made me think that the signal is degraded
by the way i am the network guy but i start work lately and i didnt know everything in the company
i just logged into the main switch its set to auto negotiation for all ports
i will change the config soon and check if it solve the problem or not
the STP is not enabled
thx again@Sebastian-Roth said in DHCP failed:
@saif No the signal is not degraded but your main switch (where the client is connected to) does some kind of magic. Possibly it’s just spanning tree. Tell your network guys to configure “port fast” for all the client ports. But it could be an auto-negotiation issue as well - then you’d need to set static port speed on that main switch for this client’s port.
-
@george1421 thx , the mini switches works and i will change config for the main switch
thx a lot for explanation -
@saif said
i just logged into the main switch its set to auto negotiation for all ports
i will change the config soon and check if it solve the problem or not
the STP is not enabled
thx againJust as an FYI. It is good practice to have spanning tree enabled to prevent loopbacks (which will bring the network to a crawl if they happen). You need to ensure that the device ports have port fast or any one of the other fast recovery spanning tree protocols enabled. Also if the ports support green ethernet or 802.1az turn that off too. That causes problems with certain realtek nics.
-
@george1421 thanks a lot for the information
i just want to add that i switched a computer which was booting to one of the ports that was not
it still can boot
but my problem is with the computers that are far from the main switch
the STP is enabled and i will check ports one by one
and the auto negotiation is enabled too -
@saif said in DHCP failed booting to the PXE:
i just want to add that i switched a computer which was booting to one of the ports that was not
it still can bootGuess that means (at least from my point of view) an auto-negotiation or 802.3az issue with that particular NIC!!
-
@Sebastian-Roth yes, you were right
i found auto-negotiation enabled -
@saif said in DHCP failed booting to the PXE:
i found auto-negotiation enabled
Which is not a bad thing in general! Usually this works great. But we have seen quite a few people with that kind of issue. You can configure static speed on that client port then.
-
@Sebastian-Roth i will do that
thanks a lot for help