PXE-E78 Cannot locate boot server
-
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…
-
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 stopThen everything is golden. Can apt-get update, can ping google.com, etc.
-
@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 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.
-
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…etcRE: 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… -
@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 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.
-
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 ?
-
@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 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 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?
-
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?
-
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
-
@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
-
@mkstreet Ok then iptables is disabled. I’m looking over your previous pcap file now.
This should be working!!
-
@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 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.
-
I did some experimenting and noticed this anomaly.
The Fog server and the host I want to load are on two switches which are connected together.
When I attach the Ethernet cable to the outside LAN / Internet to one of those switches, then I get the behavior as noted. Meaning the DHCP gets answered but when I press F8 to network boot, I get the PXE-E78 error.When I disconnect that cable to the outside, then the PC I want to load can no longer find the DHCP. So something external to the LAB must be helping get the initial requests to 10.0.253.24 ?
-
compteach@iepcomlabsrv:~$ netstat -an|grep 4011 udp 0 0 0.0.0.0:4011 0.0.0.0:* compteach@iepcomlabsrv:~$
-
@mkstreet said in PXE-E78 Cannot locate boot server:
When I disconnect that cable to the outside, then the PC I want to load can no longer find the DHCP. So something external to the LAB must be helping get the initial requests to 10.0.253.24 ?
This I understand. Since dnsmasq is not providing dhcp services for you, its only providing dhcpProxy services (filling in the gaps left out by your main dhcp server). What is strange is that your main dhcp server is sending out itself as the next server. I simply can’t understand why its not working here. It SHOULD BE WORKING.
TBH right now I’m at a loss, on where to turn next everything should be working. If you can disable the dhcp relay in your router (10.0.253.1) for 10.0.253.0 subnet then you can have the fog server with isc dhcp enabled supply the IP address (then also dnsmasq is not needed) or on your router (10.0.253.1) add yor dnsmasq server as the last dhcp server in its list. But this is starting to get messy.
The only other thing is to see if you can get your main dhcp server to NOT send out dhcp option 66 {next-server}. But its not clear if this will fix the issue either.