Unable to PXE boot XenCenter VM to Fog
-
I just built a virtual Windows 10 image and I’m trying to upload it to Fog. I changed the info on the DHCP server for line 066 & 067 to my Fog server and bootfile name (undionly.kpxe).
VM IP - 10.1.1.4
FOG IP - 10.1.1.244When I boot to network this is what I get:
066 and 067 for this subnet used to be set to a different server. The IP address 10.1.1.44 is from the previous entry. I’m not sure why it’s searching there or if it’s a DHCP issue.
tftp://10.1.1.44/default.ipxe… No such file or directory
-
Did you change the IP address of the fog server after fog was installed from 10.1.1.44 to 10.1.1.244? If so there is a process to update the configuration of the FOG server to reflect the new IP address.
-OR-
Do you have 2 dhcp servers on your network (i.e. a primary and a secondary)?? -
@SBrady Well that seems to be an interesting case. In the picture we see that in the first round of DHCP the next server is actually pointing to 10.1.1.244 and properly downloads undionly.kpxe. This is then executed and does call out for DHCP once again. We have an embedded script compiled into iPXE that you find here: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src/ipxescript
You see it do the DHCP in line 2 and then goes on to check for next server information in two places. First is the information provided by a DHCP proxy (if you have one) and second is ${next-server} from the DHCP server answer.
I changed the info on the DHCP server for line 066 & 067 to my Fog server and bootfile name
So please let us know more about your setup. What kind of DHCP server do you have? If it’s a Windows server, might be you have two and they failed to sync? Or possibly you have installed dnsmasq as DHCP proxy at some point to get it to work without changing DHCP server directly and this is causing the trouble now.
-
@george1421 The IP address for fog was never changed. The 10.1.1.44 was a provisioning server that is not related but was previously in the 66 & 67 lines on the DHCP Server for this specific subnet. My initial theory was maybe I need to restart the DHCP service because it’s still showing the previous entry.
@Sebastian-Roth Our DHCP Server is Windows 2008, we only have 1 and no dnsmasq or proxy. Using Microsoft DHCP, does it require a specific boot class or is the default boot class OK?
-
So I shutdown the 10.1.1.44 server and now when I try to PXE boot it points to a totally different server, unrelated. Is there anything in the undionly.kpxe file that controls that?
-
@SBrady If the fog server is on the same subnet as the target computer, please follow this tutorial to get a pcap (packet capture) of what is going on here. Random hosts should not appear in this booting process. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Upload the pcap to a file share site like google drive, share it as public and then either DM me or post the link to the pcap file here and I will review it.
-
@SBrady This is really scary. You seem to have random PXE boot information being spat out in your network. Definitely would go with George’s hint on capturing a PCAP to take a look what really is on the wire there.
-
@SBrady Looking at your pcap, you have 3 servers responding to the bootp request from your target computer. It appears the real dhcp server is at the .181 address and the 2 proxyDHCP servers are at .44 and .45. Both of the proxyDHCP servers are overriding what your main dhcp server is telling the target computer for where to get the boot file from.
I can’t tell from the proxyDHCP response what type of computer it is. The response doesn’t look like a Microsoft SCCM or WDS response because it is so short. I would focus on what .44 and .45 are and why they are responding to the bootp request.
Edit: Looking a bit more into the pcap there is also a WDS server responding to the DHCP DISCOVER query at the .217 address. That makes a total of 4 dhcp (and proxy servers responding) overriding what the main dhcp server was sending for dhcp options 66 and 67.
