PXE-T01: File Not Found Error
easybizit last edited by easybizit
- FOG Version: 1.3.5
- OS: CentOS 7
- Service Version:
I am a newbie to the FOG world and am doing a POC to see if it will suit a small organisation. The software looks awesome but I can’t seem to be able to take an image of a PC.
Whenever I PXE boot I receive the following error:
I have followed the CentOS guide to the letter, and am using the dnsmasq solution as well. I have found the other forums discussing the need to:
chown -R fog:root /tftpboot
alas to no avail. It is worthy of note that I am trying to image a VMWare test box (Workstation 12 Pro) and this in itself might be the issue. I will try a physical in the morning. I have tried the stuff listed here, nothing. Firewall is off for testing.
I feel so close, I can’t help but feel its a simple permissions issue but I can’t seem to track it down. Any suggestions?
dasti last edited by
I had exactly the same problem with some old pc/laptops (i.e. hp probook 4411s) but not on recent pc
- fog 1.3.0rc8 on debian
- the dhcp server was handled by a juniper switch ex3300 junos 12.3R10.2
- made some test with a pfsense vm v2.3.2 acting as a dhcp server
When I captured packets on the server, I noticed that the client was requesting a files that did not exist so I decided to mirror the port and capture the complete process as I was expecting something with the dhcp
the main difference seems to be that the juniper dhcp includes the filename in the option 67 (in addition of being also in the "boot file name¨ ) and pfsense doesn’t, and some legacy computer seems to not handle that properly and adds some caracters at the end of the filename which make the tftp request wrong which makes the tftp server to not understand what file is requested
here’s my notes from the captures
differences in dhcp offer (dhcp answer to the client) JUNIPER (not working) PFSENSE (working) ------------------------------------------------------------------------------------ server hostname 10.0.5.90 "not given" dhcp option 67 undionly.kpxe "not set" differences in TFTP read request (client asks the file to the pxe-tftp server) JUNIPER (not working) PFSENSE (working) ------------------------------------------------------------------------------------ source file undionly\377 undionly.kpxe in details undionly\357\277\275 undionly.kpxe hexa before "octetsize" ff00 00 differences in TFTP server answer (from pxe-tftp server to client) JUNIPER (not working) PFSENSE (working) ------------------------------------------------------------------------------------ answer error code (5) file not found option acknowledgement
I hope the can be helpfull to you !
dasti last edited by dasti
This post is deleted!
Here is the latest copy (I rebuilt the box to a different environment but had the same issue this is the latest copy, hence I think I’ve done something dumb).
@easybizit That is an excellent question!!
Has selinux been set to permissive? The sym link should work no problem…
So what’s up with the sym link? Its working perfectly now.
@easybizit Well that one is a bit confusing. I’m not seeing anything wrong.
Lets replace the link with a real file.
cp /tftpboot/undionly.kpxe /tftpboot/undionly.0
And then try with the tftp again from a remote windows client.
@george1421 I can grab the undionly.kxpe but not the undionly.0. ‘I get connect request failed’
@easybizit can you download the file manually via tftp?
@george1421 hmm… So why won’t it grab the file on PXE boot? I’m afraid I’m not strong in this area but I get the feeling that there something really silly that I’ve missed.
@easybizit yes that looks correct.
@george1421 Here is the contents of the tftpboot directory (just resnapped it):
Does this look right?
@easybizit You do need to create the symbolic link between undionly.0 and undionly.kpxe for that bit to work.
ln -s /tftpboot/undionly.kpxe /tftpboot/undionly.0 ln -s /tftpboot/ipxe.efi /tftpboot/ipxe.0
easybizit last edited by easybizit
@george1421 Hi! Sorry, my boss send me on a three week escapade with a days notice, I’m back now. Eureka! I think we may have found the problem. I can tftp many files but not the undionly.0 file. See below:
How do I fix that? Could it be permissions on the other side of the sym link?
@easybizit It looks like I forgot to include this, I dreamed it, or thought and the forgot it.
Using a windows computer (for windows install the tftp application) or another linux computer. Use tftp and attempt to download the undionly.0 file from the fog server. That will test to see if the file “could” be acquired by the target computer. It bugs me that it “should” be working, but is not.
@george1421 hmmm, ok. I’ll try it on a physical machine and see if its not just an issue with the vm’s that I’m using. It will take me a day or so to get a lab up and running. Let you know ASAP.
Thank you once again for your support, incredible how well you look after the community :).
@easybizit reading through the pcap this is what I see:
First of all this appears to be a good pcap (meaning it should be working!!).
packet 1 (discover)
pxe booting client vmware
firmware: IA x86 (legacy mode)
packet 2 (dhcp offer dnsmasq)
Your ip: 0.0.0.0 (this is good since dnsmasq doesn’t supply IP addresses for dhcp-proxy)
packet 3 (dhcp offer dhcp server)
next-server: not given
boot-file: not given
Your IP: 192.168.2.110
packet 4 (request [client announcing I need to know this stuff])
(various item requested not relevant)
packet 5 (ack from dhcp server)
(here is the stuff you asked for that I know about)
packet 6 (proxyDHCP request from client to dnsmasq server)
I haven’t been able to figure out how to decode this line. I assume the client is asking the proxyDHCP server about the file it needs.
packet 7 (proxyDHCP request from client to dnsmasq server)
I haven’t been able to figure out how to decode this line either.
packet 8 (client asking tftp server for file size of undionly.0)
packet 9 (client asking tftp server for the file undionly.0)
now I would have expected to see additional tftp request since undionly.0 can not fit in just one packet.
@george1421 Thank you again. No luck with the pxe-service line:
See attached the pcap file:
I needed to modify the tcpdump command a smidge to make it work:
tcpdump -w /output.pcap port 67 or port 68 or port 69 or port 4011 -i ens33
@easybizit Yes that’s right (and still disappointing that its not working).
The next steps
- In the pxe-service lines add
pxe-service=X86PC, "Boot to FOG", undionly, 192.168.2.99
This sends the for IP address as part of the “boot to fog” request. Don’t forget to restart dnsmasq when you make this change.
- Now if you have no success with the above add. The next thing is to capture what is going down the wire to see what communication is going on and what is missing. We’ll use tcpdump on the fog server to capture this communication. You could use wireshark on a third computer instead of tcpdump, but we’ll go the tcpdump route: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Capture the pxe boot process and then post the output.pcap file here so we can look at the pxe boot dialog. Out side of that I would say this is a normal pxe booting process.
I guess the next step is to attempt to get undionly.0 via another system. So if you have another linux system or if you install the tftp client on a windows system. Can you download undionly.0 from the FOG server?
I have to say this is a unique case, its not normally this difficult to get devices to pxe boot. Another test would be to see if you can just pxe boot a physical system to remove any issues with the virtual environment. I seriously doubt this is the issue since everything is flowing what I would consider normal.
- In the pxe-service lines add
@george1421 I tried that, same error. Here is the tftboot folder with sym links:
Is that right?