PXE-E78 Cannot locate boot server
-
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.8But 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.1I 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 dhcpRE: 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.8However, 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.dI am not familiar with “iptables firewall” – where should I look?
++ ++ ++ ++
Fog Server:
O/S Ubuntu V14.0x, 64-bit
Fog Software: v3121Deploy Computers:
O/S Windows 7, 64 bit
HDD: about 300 GB -
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++ ++ ++ ++
Fog Server:
O/S Ubuntu V14.0x, 64-bit
Fog Software: v3121Deploy Computers:
O/S Windows 7, 64 bit
HDD: about 300 GB -
@mkstreet Those lines in the dnsmasq.conf are safe one.
For iptables, if you key in
iptables -Lyou 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!!
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
@george1421 Can you confirm that the dhcpProxy service is running on port 4011.
netstat -an|grep 4011You should see an output like:
udp 0 0 0.0.0.0:4011 0.0.0.0:*Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
-
@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 ?
++ ++ ++ ++
Fog Server:
O/S Ubuntu V14.0x, 64-bit
Fog Software: v3121Deploy Computers:
O/S Windows 7, 64 bit
HDD: about 300 GB -
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.
-
Hmmm… If I understand this correctly, then I cannot disable dhcp relay within 10.0.253.1 as other hardware in this subnet but outside my lab would still need dhcp service for other purposes.
And, as you say, this path is getting messy.As for changing the main dhcp option 66, I could try to request this. Would this affect only my subnet or our whole facility? My lab is about 90% of my subnet, but the main dhcp is servicing the whole campus which is comprised of several subnets… If the option 66 will affect others outside my area, then it is hard for me to do.
I am setting up the new version of FOG etc under VirtualBox. I think I will complete that, as it is a new clean install. I will see if this clean start resolves anything, as opposed to this – attempting to add DNSMASQ to an existing setup that (was) working.
-
@mkstreet I understand that it is hard or maybe impossible to change the config of that 10.0.253.1 server. As you said dnsmasq can be used for exactly this purpose. So let’s give it another go. I’d say dnsmasq is answering faster as the other server as it is located right within your subnet. The PCAP output kind of proofs this. 10.0.253.24 answered 0.5 seconds before 10.0.253.1 did. So that’s good!
Then we only need to offer the correct PXE information to the client in one single DHCP answer. This is next-server and filename. Please modify the following line in your config and add the server IP as shown:dhcp-boot=undionly.kpxe, 10.0.253.24, 10.0.253.24 pxe-service=X86PC, "Boot from network", undionly, 10.0.253.24The later one shouldn’t be used but setting this correctly doesn’t hurt I’d say. Please take another PCAP capture to see if the next-server info is now being sent by dnsmasq.
[edit] I just saw that the information in the wiki page does not set those adresses. I haven’t played with dnsmasq in a while so this is just a quick idea. It’s kind of strange that you get an answer from dnsmasq that does not have next-server set… [/edit]
-
I just had a look at the dnsmasq code (version 2.68-1ubuntu0.1 used in Ubuntu 14.04) and found that from the initially posted log output it seems like next-server (mess->siaddr.s_addr in the code) is actuelly not being set. Now I know what’s going on I think. If I remember correctly dnsmasq in proxy mode does not have to send the next-server information in the first DHCP answer (reply to the first DHCP discovery request). The client knows that there is a DHCP proxy server as it got a first quick message (only containing the filename) and should contact that server (port 4011) after finishing the normal DHCP handshake to setup an IP.
In your case the next-server information sent by 10.0.253.1 is most probably interfering and confusing the client. I guess I need to think a little more about this to find a good solution… Maybe George has an idea.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Sebastian-Roth I think I like your first suggestion, updating the config file with the additional IP references:
dhcp-boot=undionly.kpxe, 10.0.253.24, 10.0.253.24 pxe-service=X86PC, "Boot from network", undionly, 10.0.253.24If that fails, get another pcap file of the booting process to let us see what changed in the conversation.
The second though is that Wow, for ubuntu dnsmasq of 2.68 that was released 08-Dec-2013, where most of the distros are at 2.72. If this doesn’t work I can setup a ubuntu VM and compile the latest version of dnsmasq to see if that helps. But before I go through that effort lets see if your edits work.
