PXE-T01: File not found
Fred53 last edited by
I did a fresh install of Debian 9 following this page : https://wiki.fogproject.org/wiki/index.php?title=Debian_8
Then I followed Install dnsmasq on CentOS 7 (https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq) as my DHCP server is a home internet box.
During FOG setup, I didn’t choose any DHCP/DNS option (seen here : https://wiki.fogproject.org/wiki/index.php?title=Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server).
Now when I boot a PC client, DHCP works (IP found) but it doesn’t boot (PXE-T01: File not found, PXE-E3B : TFTP Error - File Not found)
/etc/dnsmasq.d/ltsp.conf contains this : https://framabin.org/?98496140ffa228a1#FNmhScXt0cwbQm8ya2SY2AYRhjcRdlTRX4zksG3drwI=
/tftpboot contains this : https://framabin.org/?cf5d1f8abaff3b10#dUhgKqKg8r/Opl32tHKEgTyev40sIdhUlWTgoHC0qGs=
PC and FOG server are Lenovo ThinkCentre M79
Have you got an idea of what is wrong ?
Fred53 last edited by
@george1421 I’m using dnsmasq 2.76.
I just tried your ltsp.conf file and it works.
Thank you very much.
I have worked with this area of pxe booting on some pretty tough problems. So I have a few things I can tell you.
First for your dnsmasq if you can install / or have installed dnsmasq 2.76 or 2.77 your configuration will be a bit easier. I would first focus on getting on this release. I have not personally done this with Debian but I have a tutorial on how to compile dnsmasq 2.76 and I know it works on Ubuntu. https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support
Before you go through all of that open a command window on your fog server (or dnsmasq server) and key in the following command
dnsmasq -vto get the dnsmasq version. If its less than 2.76 then consider compiling an update using my instructions.
If you are on 2.76 or later consider using my ltsp.conf from this end of this post [ https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support/6 ]. I can say for absolute this configuration works perfectly. Make sure you change the
<fog_server_IP>to the IP address of your fog server. Don’t forget to restart dnsmasq after you make a change to the config file. Also ensure that when you reboot your fog server that dnsmasq restarts too.
I have seen what Sebastian said about home routers. They do send their IP address as the next server but no boot file. That isn’t very helpful if you want to pxe boot at home. So far I’ve been able to use dnsmasq to over ride home dhcp setups of all kinds. In my home right now my home router does exactly what we are talking about, sends itself as the next server with no boot file name. I’m running FOG and dnsmasq on a Raspberry Pi3 server and I can pxe boot both uefi and bios systems no problem. If we take my config file and make a small tweak to it, we should be able to override even a valid dhcp server sending out a proper next server and boot file.
The other thing that Sebastian mentioned was to capture the network traffic using wireshark or tcpdump. Since the pxe booting process needs dhcp and dhcp is communicated via broadcast messages we can have any computer on the same subnet eavesdrop at least on the dhcp process to understand what is going on. There is no need for a mirror port. If you use tcpdump running on the FOG server you can view the entire pxe booting process, even after the target computer switches over to unicast communication since it is talking directly to the fog server at that point. I do have a tutorial on that too: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
@Fred53 The issue with home internet router I have seen myself is that some of them send DHCP option 66 (next-server) but leave the filename (option 67) empty. For a client trying to PXE boot this is a problem because ProxyDHCP (dnsmasq) can only work if the DHCP does not send any PXE boot information at all. If it sends next-server option the client expects to read the filename information from that same DHCP packet as well and simply ignores the packet received from dnsmasq.
Well that’s just a guess in the wild. To make sure you need to capture the network traffic on the client side. Either using a monitoring port on the switch or by intercepting the packets on an old network hub that you connect just in front of the client. Hook up another client to the monitoring port or hub and install wireshark. Capture the traffic while trying to PXE boot the other client. Use display filter
bootp || tftpto see just that stuff and suppress all the other packets.