PXE-E53: No Boot File Received

[Sebastian Roth]

@george1421 Not seeing any addresses seems a bit strange indeed but from what I see here it seems normal. The error means that the clients received an answer from the DHCP but misses the boot file information that is needed to load that file from the TFTP server.

@kinger37 Great that you uploaded PCAP files as those are telling us the truth. In both files I see two DHCP offer replies. One obviously from your juniper switch (x.x.x.33) which is handing out the IP address. Seems good to me. The other one must be DNSMASQ (x.x.x.43). This one is answering with nextserver (x.x.x.43) and bootfile (undionly.kpxe) options set in the reply. All looking good I find. Now the interesting part. In the working PCAP I see the client send a DHCP request after the initial DHCP discover just like it should. But in the other PCAP the client comes back after three seconds with another DHCP discover as if it had not seen the DHCP offer from DNSMASQ. Possibly the BIOS of that machine does not like the DNSMASQ DHCP offer and simply ignores it. Can you please try a different machine just to see if this is an issue with this particular machine model?

But there is another thing in the “working” PCAP that needs to be addressed I reckon. While DNSMASQ sends undionly.kpxe as filename in the DHCP offer (as reply to the initial DHCP discover) it sends undionly.0 in the DHCP ack message (as reply to the DHCP request). While the virtualbox machine does not mind it I’d still suggest you make sure to adjust your config to have it send the same filename on both replies. Quoting my own post from about a months back:

@Sebastian-Roth said in Upgrade to Trunk, Kernel Panic:

Sure, even better symlink undionly.kpxe as undionly.0 and use:

pxe-service=X86PC, "Boot from network", undionly, x.x.x.x
dhcp-boot=undionly.kpxe, x.x.x.x, x.x.x.x

[edit] That’s another thing I hate about dnsmasq - there are different options that seem to do the same kind of thing and I had to study the code to find out which is doing what - and sure I forgot again already [/edit]

[KnightRaven]

@kinger37
You might try adding the dhcp option(s) to
/etc/dnsmasq.conf
I was having issues with getting the file from the right address. Adding the info to dnsmasq.conf helped where having it in ltsp.conf didn’t work for me.

Have a look at my post here…
https://forums.fogproject.org/topic/7723/pxe-ipxe-dnsmasq-next-server-undionly-config-tip-s

[kinger37]

@Sebastian-Roth I have attempted this with a couple different Machines, same thing happens. I do have a symlink that points undionly.0 to undionly.kpxe. Here is my LTSP.conf file:

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Dnsmasq can also function as a TFTP server. You may uninstall
# tftpd-hpa if you like, and uncomment the next line:
# enable-tftp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,128.119.61.43,128.119.61.43

# rootpath option, for NFS
#dhcp-option=17,/images

# kill multicast
#dhcp-option=vendor:PXEClient,6,2b

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Press F8 for boot menu", 3

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot from network", undionly, 128.119.61.43

# A boot service type of 0 is special, and will abort the
# net boot procedure and continue booting from local media.
#pxe-service=X86PC, "Boot from local hard disk", 0

# If an integer boot service type, rather than a basename is given, then the
# PXE client will search for a suitable boot service for that type on the
# network. This search may be done by multicast or broadcast, or direct to a
# server if its IP address is provided.
# pxe-service=x86PC, "Install windows from RIS server", 1

# This range(s) is for the public interface, where dnsmasq functions
# as a proxy DHCP server providing boot information but no IP leases.
# Any ip in the subnet will do, so you may just put your server NIC ip here.
# Since dnsmasq is not providing true DHCP services, you do not want it
# handing out IP addresses.  Just put your servers IP address for the interface
# that is connected to the network on which the FOG clients exist.
# If this setting is incorrect, the dnsmasq may not start, rendering
# your proxyDHCP ineffective.
dhcp-range=128.119.61.43,proxy

# This range(s) is for the private network on 2-NIC servers,
# where dnsmasq functions as a normal DHCP server, providing IP leases.
# dhcp-range=192.168.0.20,192.168.0.250,8h

# For static client IPs, and only for the private subnets,
# you may put entries like this:
# dhcp-host=00:20:e0:3b:13:af,10.160.31.111,client111,infinite

Mod edited to use code box.

[kinger37]

@george1421 Here is two new pcap files - one on a machine that will not work and one from the VM that is working. The system I am trying to boot is an Dell Optiplex 7040M - where I have tried both BIOS and UEFI - would prefer to use UEFI. We have juniper EX3300 switches which I believe are providing DHCP services - but 100% percent sure.

1_1467047901006_output-error.pcap
0_1467047901006_output.pcap

[george1421]

@kinger37 Ah ok. For testing please leave it in BIOS/legacy mode. There is an issue with dnsmasq and uefi systems right now. So lets remove one variable. Plus I just received my order of 7040s (still sitting in boxes) that we can compare against if it is a system issue.

Looking at Pcap now.

[george1421]

@kinger37 OK we need to identify some actors here.

128.119.61.55 == pxe booting computer
255.255.255.224 == subnet mask (?? range 192.119.61.33 - 192.119.61.62)
128.119.61.33 == relay agent (maybe a router?)
128.119.61.43 == FOG Server (next-server) boot-file=undionly.kpxe
128.119.10.12 == DHCP server (on another network)
128.119.10.17 == DHCP server (offered by 128.119.61.33 ?)
128.119.101.1 == DNS server

target device is identifying it self to dhcpProxy as IA x86 PC (intel pc in bios mode)

It appears that everything is working. Maybe Sebastian can see something more.

I can tell you the 7040 I have did display the pxe boot screen as I expected. It shows the mac/guid and a spinning cursor waiting for a dhcp response, then ip address and dhcp server, the normal ROM PXE boot screen (something that your display lacked).

I can say that on this system I when into the bios and set everything back to default (bios mode) then rebooted. Then went back into bios and enabled hard drive and network booting only. I think I went and check the network adapter to ensure that pxe booting was enabled and also checked the box to enable pxe booting in UEFI mode. Once I did that and saved the settings, during boot I pressed F12 and selected the bios network boot option.

[Vanlue IT Guy]

Hi all, I don’t want to pile on here, but I came in this morning and I am having this issue now as well. Everything was working fine yesterday.

My DHCP is Server 2012 R2. I have confirmed that the 66 and 67 options are configured correctly. I have rebooted my FOG server. Nothing fixes the issue. Nothing has changed on my end. I have updated FOG to 5768 with no change. Any thoughts?

[Vanlue IT Guy]

@Vanlue-IT-Guy I wanted to update everyone - I have tried a different boot server entirely (an old kace vm) and I am getting the same error message - PXE-E53: No Boot Filename Received. I am beginning to think there’s a DHCP in windows somewhere.

[george1421]

@Vanlue-IT-Guy If your target computer (one you are pxe booting), dhcp server and FOG server are in the same subnet then…

1. Start your own thread
2. Post the pcap file using this command from your FOG server console. tcpdump -w output.pcap port 67 or port 68 or port 69

How you should go about doing this is to get your target computer ready to pxe boot (like through the F12 menu). Then start the packet capture on your FOG server. Boot the target until you get the error, then stop the capture. Look at the pcap file in wireshark if you want to see what is going on and or post the pcap to your new thread so we can review.

[Sebastian Roth]

@kinger37 Once again in the failing PCAP I see a proper DHCP offer reply from the server. Where do you capture those? On the FOG server? Would you be able to use a network hub to connect between your client and the network and capture traffic there just to make sure the reply is actually making it to the client. If that’s the case I’d think the BIOS (as George said, dnsmasq and UEFI are not working very well) of those machines just does not like the dnsmasq answer. Possibly the vendor specific information (option 43)?! I don’t know. Have you tried other PC models?

[kinger37]

@Sebastian-Roth @george1421 Thank you both for all your responses, I am going to change our setup and use a isolated network for FOG and cloning computers. I will update everyone once I have set it up and tested.

[kinger37]

@Sebastian-Roth @george1421 After setting up a fresh install of Ubuntu 14.04 Server and FOG Server 1.2.0 I have finally got it working on a isolated network - only thing now is that the switch I want to use has to have STP disabled (waiting to get a console cable). Thank you all for your help.