Lenovo L13W Yoga not booting to FOG
We are running on FOG 1.5.9 and I have just recompiled the TFTP boot files but we are still not able to boot this new machine to FOG.
Boots to the nic and gets an ip and then says
NBP filename is ipxe.efi
NBP filesize is 0 Bytes
PXE-E18: Server Respone timeout
Any help would be great. Thanks
@john-l-clark This is what the bios looks like.![0_1650315892952_L13W Bios.jpg](Uploading 0%) ![0_1650315978606_L13W Bios.jpg](Uploading 0%)
@sebastian-roth Yes we are still able to image other machines.
@sebastian-roth If DMA protection is an option, turn it off.
I have tried to fog lenovo’s in the past and there something about the bios on those things that make it a difficult process. If I remember correctly (and i may be wrong) they have no legacy support at all and therefore require your DHCP server to have some somewhat complex settings in order to support UEFI boot processes. For reference: https://gal.vin/posts/old/pxe-booting-for-uefi-bios/
@strahd We are a Dell and Lenovo district and we are as of last summer only using UEFI booting because of no legacy support in the bios on those machines. We have had no trouble till this new machine has come in.
@john-l-clark I think I would like to see a pcap of the pxe booting process for this specific lenovo computer. If the fog server and pxe booting computer is on the same subnet you can use this process: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
If the fog server and target computer are on different subnets then use a witness computer (third computer in the mix) with wireshark. Use the capture filter of
port 67 or port 68
Upload the pcap to a file share site, share it public (read with link) and then post the link here or DM me the link. I want to see what is special about these computers.
The FOG server process will give us the best details into why its not working.
@george1421 Ok update, we are able to boot and capture and image when the machine is on the same subnet as FOG. Yet when on a different subnet it will not. We are looking into this. Thank you all for the help. Also all other machines are still booting to FOG on different subnets and using the same boot file.
@george1421 Ok I have found with the MAC passthrough in the Bios turned on we are not able to boot to FOG unless we were on the same subnet. With it turned off i was able to boot to FOG on other subnets. So this is not good for us as when you register the machine you have to keep the dongle with the device. Thank you all again for the help.
Ok I have found with the MAC passthrough in the Bios turned on we are not able to boot to FOG unless we were on the same subnet.
This is interesting. My intuition is telling me it might be an MTU issue. We have seen that with tftp, Where (typically) on the other side of a VPN WAN link the MTU of the data packet is less than the block size of tftp. The block size of 1468 comes to mind for tftp. When the network MTU dips below that level it causes fragmentation of the tftp packet, then the transfer fails.
Using the instructions I provided before for collecting a pcap on the fog server, you are interested in udp port 69. Start the packet capture and then pxe boot the target computer on the remote subnet. See if it attempts to contact the fog server. The tftp query will be 2 times before data is transferred, the first time the client queries the tftp server on the size of the file and the second time it asks for the file. My bet is that it will ask for the file size, but then the file is never sent.