Fog Trunk no longer PXE booting
-
@eldiablo909 do you mean default.ipxe?
-
@Tom-Elliott Yes… that’s what i meant, sorry sleepless night last night
-
@eldiablo909 so it’s a 192.168 dhcp server handing out information to a 10.0 network?
-
@Tom-Elliott yes, i had it on the same network prior but it was doing the same thing so i decided to try using windows DHCP vs my firewall.
-
This often happens when there are two DHCP servers running on the same network.
-
@Quazz I don’t have another DHCP server on either the 10.80. or the 192.168. network.
-
@eldiablo909 We see that the first round of DHCP seems to work out because the Intel PXE boot ROM is able to grab an ip, get next-server/filename info and load the iPXE binary. One thing I notice here is the DHCP server IP address being totally different to the client IP and gateway address. This does not have to be an issue. It’s just a bit unusual and I wanted to point this out in case…
Version 6213 might not be the very latest but from what I see in the repo we haven’t changed the embedded iPXE script since then. So upgrading to the very latest won’t help I reckon!
From the message you see it seems like your DHCP server does not send next-server (option 66) on the second DHCP round (when iPXE is asking). Possibly your DHCP server decided to not like the DHCP options send by iPXE/gPXE/Etherboot anymore (e.g. option 175).
About the TFTP error. Make sure the TFTP server is running on your FOG server. I remember there have been issues with this on ubuntu.
service tftp-hpa restart
. As well follow this: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP -
@eldiablo909 I think we are back to requiring a pcap file so we can see what is going on… on the wire. Make sure tcpdump is installed on your FOG server then run the following command
tcpdump -w output.pcap port 67 or port 68 or port 69
Next pxe boot the client computer. You will get the question for the fog server IP enter it and take it to the final error where you can’t go any more. Then post the pcap file here. We’ve instructed tcpdump to only capture broadcast bootp and tftp requests.
-
@george1421 What about the “router” setting in the DHCP server?
-
@Tom-Elliott Ok, we fixed it… we looked at the pcap dump here and found it was one of my colleagues and his sonicwall pulling a sarah palin and went rogue. Issue resolved.
Again my hats off to you guys and the community thank you so much!