PXE-T01: File Not Found Error

[easybizit]

@george1421 I believe its a legacy device. Its a windows 7 VM, not sure if that would use UEFI Is there someway I can verify that? See below for the verions of dnsmasq:

[george1421]

@easybizit I think I have a path forward now.

The version of dnsmasq does not support multiboot uefi / legacy boot based on the pxe booting client computer. This is not a problem as long as you only boot legacy or uefi alone. When you have a mix campus you will need to update this by compiling dnsmasq version 2.76. I have a tutorial on how to do this, but lets get your legacy device to pxe boot first.

If you look at your ltsp.conf file, there is a line:

pxe-service=X86PC, "Boot to FOG", undionly

And if you look at your initial screen shot, you see this is the line that is triggered because you see “Boot to FOG” clearly printed on the screen. So we know we are working with the right line.

The versions of dnsmasq before 2.76 had a unique property. If the boot file name listed was undionly dnsmasq automatically appended .0 onto the file name making the file name sent to the client undionly.0. The issue is that the real file name of the file is undionly.kpxe with undionly.0 being sent and then requested by the client the client will then get a PXE-T01: File not found

So to the fix. create a link from undionly.kpxe to undionly.0.
ln -S /tftpboot/undionly.kpxe /tftpboot/undionly.0

This should create the required (by dnsmasq) to be available to be sent to the client.

IF this doesn’t work then (based on your environment) we have a few more tweaks we will make to your ltsp.conf. So we are not done IF this fix doesn’t solve the issue. This change above is required before we do the next things.

[easybizit]

@george1421 I tried that, same error. Here is the tftboot folder with sym links:

Is that right?

[george1421]

@easybizit Yes that’s right (and still disappointing that its not working).

The next steps

1. In the pxe-service lines add ,192.168.2.99

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.

2. 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.

[easybizit]

@george1421 Thank you again. No luck with the pxe-service line:

See attached the pcap file:

0_1490611720374_output.pcap

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

[george1421]

@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)
next-server: 192.168.2.99
boot-file: undionly.kpxe
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.

[easybizit]

@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 :).

[george1421]

@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.

[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?

[george1421]

@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]

@george1421 Here is the contents of the tftpboot directory (just resnapped it):

Does this look right?

[george1421]

@easybizit yes that looks correct.

[easybizit]

@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.

[george1421]

@easybizit can you download the file manually via tftp?

[easybizit]

@george1421 I can grab the undionly.kxpe but not the undionly.0. ‘I get connect request failed’

[george1421]

@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.

[easybizit]

@george1421

So what’s up with the sym link? Its working perfectly now.

[george1421]

@easybizit That is an excellent question!!

Has selinux been set to permissive? The sym link should work no problem…

[easybizit]

@george1421
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).

[dasti]

This post is deleted!