MacPro6,1 PXE boot
-
@chief I also see only the tftp request. One is asking if the file exists and the second requesting the download of undionly.kpxe (which we know is only for bios based systems).
Is your dhcp server, fog server and booting target computer on the same subnet (vlan)? That is a requirement if you want the FOG server to listen in on the dhcp messages.
-
I guess he could always just do a wireshark capture on the dhcp server.
I guess what would be the ultimate best is a third computer connected to the same computer network booting via a hub (not a switch). Just stick the hub between the target computer and the building’s network port, then use one of the hub’s spare ports to do a capture with. This will not work with a switch, only a hub would do it.
-
It is going between subnets. From server to PC subnets/VLAN.
-
@chief said in MacPro6,1 PXE boot:
It is going between subnets. From server to PC subnets/VLAN.
Is it possible for this test to get all three on the same subnet. We really need to the entire conversation here. If that isn’t possible, can you setup a wireshark system on the Mac/workstation subnet and collect a pcap of that workstation pxe booting. From this perspective we only need port
67 and port 68data. We know from the fog server that the file is being requested. We just need the part of the conversation that leads up to the request. -
@chief I am wondering if you are aware of the wiki article: https://wiki.fogproject.org/wiki/index.php/FOG_on_a_MAC
As you see there is a kind of special DHCP setup to be able to netboot MACs. There is more to it than simple DHCP - see here https://static.afp548.com/mactips/bootpd.html. I am not aware of windows DHCP server being able to do this.
A different approach would be to bless your MAC clients - setting to boot option to get a boot image from a hard coded TFTP server. Find a short description in the wiki article mentioned above.
-
@george1421 I have moved the FOG server into the same VLAN and IP subnet. I have the DHCP set up as per the BIOS and UEFI co existence post. I am now getting PXE boot on windows, but it fails with a “No configuration methods succeeded”
The screenshot is from Virtualbox, but I’ve tested on phyical Dell laptops with same issue.
-
@chief Its been a few days now so lets make sure we are on the same page.
You have the dhcp server (MS Windows??), the FOG server, and the PXE booting client all on the same vlan for testing.
The target computer PXE boots, then the iPXE kernel is sent to the target computer. But now iPXE complains about “No configuration methods succeeded”
If this is the case, my initial reaction is that this might be a spanning tree issue (assuming this happens on the dell computer).
Why?, because the target computer pxe boots and the undionly.kpxe (or ipxe.efi) is sent to the target. computer. To do that the PXE rom must be able to talk to the dhcp server to get an IP address and boot file name. When the iPXE kernel launches it momentarily resets the network interface causing the link light to drop (wink) for a second. If spanning tree is enabled on that switch port and it is not configured for one of the fast STP protocols, the port won’t go into the forwarding state for 27 seconds. By then the iPXE kernel has given up stating “No configuration methods succeeded” or in english - “I can’t get a dhcp address on any network interface”.
A quick check for a spanning tree issue is to place a dumb (unmanaged) switch between the target computer and the building network switch. If it boots into the FOG menu with the unmanaged switch in line then you need to speak to your networking group to confirm that one of the fast STP protocols are enabled. This is not a FOG issue but a networking issue.
-
@george1421 Thanks for help. Was off for a few days over the holiday period.
Yes, Windows 2012r2 DHCP server. The FOG server and PXE client are on same VLAN/Subnet.
Will test the network issues.
-
@george1421 Putting a dumb switch in between fixes the issue.
We have Dell switches with portfast enabled and a bpdufilter. After a bit of googling, I think the bpdufilter should allow the dhcp through the switches. -
@chief Ok if you put a dumb switch in between the target computer and building switch and it resolved the problem. Then its probably one of the advanced protocols causing the issue.
This is typically spanning tree being enabled and not using one of the fast stp protocols.
Or you have green ethernet (802.3az) enabled on the building switch. We’ve seen this to be an issue with some realtek nics.
