PXE-E78 Cannot locate boot server

mkstreet

@Sebastian-Roth 10.0.253.24 is my server. This is the server that has Fog as well as my newly setup DNSMASQ.

I setup DNSMASQ following the instructions for:
“Using FOG with an unmodifiable DHCP server”
https://wiki.fogproject.org/wiki/index.php?title=Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server

Because I don’t have access to / it’s not easy to change (if at all) the 172.x.x.x server.

I thought this was the intent of the DNSMASQ setup for “Using Fog with an unmodif…” ?

What can I send you from 10.0.253.24? I can send the DNSMASQ.conf and the ltsp.conf files?

If it’s essential now or going forward operationally, I can disconnect from the 172.x.x.x network and run isolated from that while loading with Fog.

george1421

@mkstreet OK then let me see if I can put the bits together now.

10.0.253.24 is your FOG server with DNSMASQ running on it.
10.0.253.1 is your router on the 10.0.253.0 subnet. It is also running a dhcp relay/helper service that forwards dhcp requests to your site dhcp server.
172.16.1.1 is your corporate dhcp server that is untouchable (and a bit suspicious at the 1.1 address but…)

As long as the dnsmasq server is in the same subnet as the pxe booting client this setup should work no problem. What Sebastian noted is that your dnsmasq server is handing out the name of the boot-file but its not handing out the IP address of the next-server (so the pxe client is listening to what its getting from the 172.16.1.1 dhcp server).

Can you post the complete ltsp.config file from your dnsmasq setup? Some where you are missing a command. Hint: There should be two spots where you have to enter the IP address of your fog server in the dnsmasq configuration.

mkstreet

@george1421

10.0.253.24 is your FOG server with DNSMASQ running on it.
*** Correct.

10.0.253.1 is your router on the 10.0.253.0 subnet. It is also running a dhcp relay/helper service that forwards dhcp requests to your site dhcp server.
*** I accept your description as correct. I have not specifically configured 10.0.253.1 … so where/how it is setup, I am not certain.

172.16.1.1 is your corporate dhcp server that is untouchable (and a bit suspicious at the 1.1 address but…)
*** Yes…

Here is the ltsp.conf. The very last line references the MAC addr of the computer I want to load. Because long term I was nervous about this DNSMASQ answering requests from the wider network, I planned to list the roughly 50 hosts in this file by MAC Addr. My proof of concept was to just put one MAC Addr in to start with…

compteach@iepcomlabsrv:/etc/dnsmasq.d$
compteach@iepcomlabsrv:/etc/dnsmasq.d$ cat ltsp.conf

# 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,,10.0.253.24

# 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

# 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=10.0.253.24,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
dhcp-host=f8:0f:41:a0:04:75,net:allow
dhcp-ignore=#allow

MOD Edit: Added code block for readability

mkstreet

I should make clear that before this network change that led to me attempting DNSMASQ,
this Fog server was working fine. So, is my problem a Fog configuration setting that needs to change to recognize working with DNSMASQ?

In other words, DNSMASQ is newly added to a Fog server that had been working before…

mkstreet

I’ve just noticed too when I tried to do sudo apt-get update that it seems the 10.0.253.24 cannot resolve hostnames because the apt-get update fails because it cannot locate the update mirror.
Further, something like ping google.com cannot find the host either.

But if I do…
sudo service dnsmasq stop

Then everything is golden. Can apt-get update, can ping google.com, etc.

george1421

@mkstreet You have a few things going on here lets take the easy ones first.

Unable to resolve internet names.

What does the /etc/resolv.conf point to ? Guess: 127.0.0.1? Your fog server resolve.config should point toward your buildings internal dns server not itself.

As for the dnsmasq, I want you to remove (comment out) the dhcp hosts and ignore at the end of the ltsp.config file then restart dnsmasq. From a sanity standpoint dnsmasq only works on a multinet broadcast so by default it will not cross a router unless you setup stuff on the dhcp relay. So running it on your single subnet is not an issue. Remove those settings to ensure that the right information gets passed out. I confirmed that your ltsp.config file matches my example file exactly. (I added the code block around your config file so it was a bit more readable).

NO change is needed to FOG for dnsmasq since all settings are external to FOG.

george1421

@george1421 Justs for clarity, the device you are attempting to pxe boot is in BIOS (legacy) mode?

FWIW: Your ltsp.config will only respond to requests from bios (legacy) based computers.

mkstreet

After sudo service dnsmasq stop, then /etc/resolv.conf has

compteach@iepcomlabsrv:/etc$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 110.164.252.222
nameserver 8.8.8.8

But when I start … sudo service dnsmasq start then the /etc/resolv.conf has, as you said,:

compteach@iepcomlabsrv:/etc$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

I am not sure how to fix this because the /etc/resolv.conf is dynamic and overwritten (as the files own comments state). Do I list the internal DNS in the /etc/network/interfaces ?

compteach@iepcomlabsrv:/etc/network$ cat interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto em1
iface em1 inet dhcp

RE: LTSP.CONF
I’ve removed the two lines at the end of ltsf.conf.
And did a sudo service dnsmasq restart
the boot results are the same… meaning I get the PXE-E78 error…etc

RE: BIOS.
I looked in the BIOS settings. It says Boot Mode Auto, and Boot Priority Legacy First.
I haven’t changed these BIOS settings in probably over a year and it was working before with this FOG server…

george1421

@mkstreet Well the first issue is that the FOG server MUST be at a static IP address (period). The issue comes (even if you use dhcp reservations) just as you noted the resolv.conf file will change based on outside forces. Once the network mode is set to static then resolve.conf should stay put. I don’t know if dnsmasq is forcing a dhcp renew or not, but what you have is not what I see on my FOG-Pi server that IS running dnsmasq.

george1421

@george1421 The pxe error PXE-E78 means that the boot server that is either being returned by dhcp either doesn’t exist or that value is not being returned. Lets fix the IP address on the fog server. You can keep it at this address, it just needs to be configured in linux as static. Once you do that you should inspect the content of the /etc/resolv.conf file to make sure it is configured as you need it.

mkstreet

@george1421

Ok I changed /etc/network/interfaces and did a reboot (to be sure my changes were implemented):

compteach@iepcomlabsrv:/etc/network$ cat interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto em1
iface em1 inet static
address 10.0.253.24
netmask 255.255.255.0
gateway 10.0.253.1
dns-nameservers 110.164.252.222 8.8.8.8

However, I still seem to have unknown hosts and the resolv.conf just has the loopback address:

compteach@iepcomlabsrv:/etc/network$ sudo service dnsmasq status
 * Checking DNS forwarder and DHCP server dnsmasq                                                                                                                       * (running)
compteach@iepcomlabsrv:/etc/network$
compteach@iepcomlabsrv:/etc/network$
compteach@iepcomlabsrv:/etc/network$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
compteach@iepcomlabsrv:/etc/network$ ping google.com
ping: unknown host google.com
compteach@iepcomlabsrv:/etc/network$

Do I need to do anything with the /etc/dnsmasq.conf file ?

george1421

@mkstreet This is very strange, indeed. If you manually set the values in resolv.conf and then start and stop dnsmasq does it change the settings? I’m going to confirm on my Pi server to see if it does the same things. In my experience it does not.

george1421

@george1421 OK I sit here a bit red faces, since my server does the same thing AND I have it setup to use dhcp. AND my server is working correctly. I need to look into this now.

george1421

@george1421 Just to be clear every line in /etc/dnsmasq.conf is commented out?

And actually dnsmasq is suppose to rewrite the file. I takes what was in there and caches it internally and then puts the loopback address in to point to itself.

Also you disabled the iptables firewall on this server right?

mkstreet

@george1421

For the /etc/dnsmasq.conf, the last lines are NOT commented out as shown here:

# For debugging purposes, log each DNS query as it passes through
# dnsmasq.
#log-queries
# MKS 04-Oct-2016
log-queries

# Log lots of extra information about DHCP transactions.
#log-dhcp
# MKS 04-Oct-2016
log-dhcp

# Include another lot of configuration options.
#conf-file=/etc/dnsmasq.more.conf
#conf-dir=/etc/dnsmasq.d
# MKS 04-Oct-2016
conf-dir=/etc/dnsmasq.d

I am not familiar with “iptables firewall” – where should I look?

mkstreet

I found this…

compteach@iepcomlabsrv:/etc$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

george1421

@mkstreet Those lines in the dnsmasq.conf are safe one.

For iptables, if you key in iptables -L you should either get a response back like I don’t know what you are talking about or it should show you 3 filters with accept. If your iptables output looks like this one you have iptables turned on. The content isn’t important just if you see rules in there other than allow you need to disable iptables.

hain INPUT (policy DROP)
target     prot opt source               destination         
ufw-before-logging-input  all  --  anywhere             anywhere            
ufw-before-input  all  --  anywhere             anywhere            
ufw-after-input  all  --  anywhere             anywhere            
ufw-after-logging-input  all  --  anywhere             anywhere            
ufw-reject-input  all  --  anywhere             anywhere            
ufw-track-input  all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ufw-before-logging-forward  all  --  anywhere             anywhere            
ufw-before-forward  all  --  anywhere             anywhere            
ufw-after-forward  all  --  anywhere             anywhere            
ufw-after-logging-forward  all  --  anywhere             anywhere            
ufw-reject-forward  all  --  anywhere             anywhere            
ufw-track-forward  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ufw-before-logging-output  all  --  anywhere             anywhere            
ufw-before-output  all  --  anywhere             anywhere            
ufw-after-output  all  --  anywhere             anywhere            
ufw-after-logging-output  all  --  anywhere             anywhere

george1421

@mkstreet Ok then iptables is disabled. I’m looking over your previous pcap file now.

This should be working!!

george1421

@george1421 Can you confirm that the dhcpProxy service is running on port 4011.

netstat -an|grep 4011

You should see an output like:

udp        0      0 0.0.0.0:4011            0.0.0.0:*

george1421

@george1421 I’m seeing the same thing as Sebastian saw. Let me check a pcap file I captured the other day.

This is very strange indeed. Our configurations are basically the same, except I’m running the latest version of dnsmasq to test uefi booting. In my pcap dnsmasq is sending out its IP addresss in the dhcp offer for next server, but in yours its not sending out the next server address at all. This is the only difference. Plus after the ACK from my main dhcp server (soho router) the target computer connects to the dhcpProxy port and then download the boot file.

PXE-E78 Cannot locate boot server

171

11.6k

17.1k

154.6k