PXE-E53: No Boot File Received

[kinger37]

I have just installed Fog 1.2.0 on Ubuntu 14.04 (VM on VirtualBox). I am not using DHCP or DNS on FOG and have installed DNSMASQ - which the status says its working. Also I have confirmed that I am able to access undionly.kpxe from my Windows PC using TFTP. I did two tests - where I boot a PC into PXE and I get this error: PXE-E53: No Boot File Received. I then create a new Windows VM in VirtualBox and boot into PXE where is loads into FOG no issues. Any ideas on what could be the issue?

[george1421]

Please describe your dhcp server? I understand you are not using FOG for dhcp services, but what are you using?

Is the PC that is not PXE booting on the same subnet as the FOG server?

Your virtual box VM that IS pxe booting, is that on the same VMHost as your FOG server? Is it on the same IP subnet as the target computer that failed to boot?

You are using DNSMASQ because your primary proxy server can’t hand out dhcp options 66 and 67?

Please post a picture (mobile phone upload that is clear is ok) of the pxe boot that filed.

[kinger37]

Hi - our DHCP server is a Juniper Switch. The PC (I have tried different PC’s as well) are all on the subnet as the FOG Server. Yes, the VM that PXE booted is on the same VMHost. I have the network adapters bridged on both VM and FOG Server and are on the same subnet.
I dont have rights to modify our DHCP server.
I have attached the two network captures, issues.pcap is the PC that wont PXE boot and the works.pcap is the VM that worked.

1_1466882742690_works.pcap
0_1466882742689_issue.pcap

[adukes40]

I just had this issue as well. I migrated a DHCP scope from an old server to the current server. It now has two scopes. For what ever reason, the boot options disappeared from the original scope but stuck with the migrated scope. I added the options 66 and 67 back to the original scope, and it worked.

/shrug

[george1421]

@kinger37 There a couple of things here.

1. When I look at the PXE screen I don’t see what I expect. (Without knowing what device this is) I would say that this target is not getting any dhcp response. Normally you would see dhcp information on this screen like client IP, dhcp server IP, subnet mask and so on. I’m not saying what we are seeing is wrong, just abnormal.

2. The pcap file is not good, it look like it is just one packet capture of a ssh conversation. It also tells me that the two devices in this conversation are on different subnets. If you FOG server and PXE booting client are in the same subnet as your dhcp server then please use this tcpdump command from your FOG server. tcpdump -w output.pcap port 67 or port 68 or port 69 This command will only capture dhcp and tftp protocol packets.

3. Understood on the juniper switch (maybe router) being your dhcp server (please clarify which, that will actually tell me a bit more about your infrastructure). Then dnsmasq is the right tool to use here if you can’t alter the juniper configuration. Understand since you can not alter the juniper configuration then your target and fog server must be on the same subnet, since dhcp and dhcpProxy is broadcast based. If you had control of your juniper and you have a routed subnet then you have options, but since you can’t touch the configuration you have to keep everything in the same broadcast domain (subnet/vlan). (note: we may need to see your dnsmasq configuration)

4. What system (specifically) are you trying to pxe boot? Is that system setup in bios mode or uefi (it does matter)?

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