Issues booting UEFI devices a

[cnkpadobi]

it also says not bootfile name recieved.

[george1421]

@cnkpadobi IP address is not assigned by FOG, that is your dhcp server that does that.

[george1421]

@cnkpadobi said in Issues booting UEFI devices a:

it also says not bootfile name recieved.

Is your dhcp server, fog server, and pxe booting client on the same subnet. (based on the screen shots you posted I would say yes).

If that is the case we can use the fog server to capture the dhcp / pxe communication that is going on between your target computer and the network.

Here is a tutorial that will help you capture a pcap of the communications. You want to start the tcpdump capture and then pxe boot the target computer until you get the error pretty close together so you can quickly identify the booting process.
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Post the output.pcap file here for review.

[cnkpadobi]

Just to make sure we are on the same page. Since I am using a hardware dhcp server. I took the option 66 and 67 off the appliance and allow the fog server dnsmsq to handle everything correct?

I edit the dnsmmsq file and made the change suggested in the previous post.

Before I made those changes was able to legacy boot but not UEFI boot. Now we cannot do either.

Just recapping to make sure we are on the same page before proceeding.

Yes my dhcp server and is on the same subnet

[Wayne Workman]

@cnkpadobi Is or isn’t your hardware dhcp server configured to give out options 66 and 67? Your previous statement was not clear.

[cnkpadobi]

It was prior to making the change to have fog server to do the work and use dnsmasq …

0_1489707295938_output.pcap

When it was working in legacy boot it was in the appliance

[george1421]

@cnkpadobi For what ever reason your pcap didn’t make it to the FOG server. Could you post it again, please.

Looking at the pcap file. I’m not seeing a normal dhcp conversation going on.

I see the clients sending a discover request and the watchguard dhcp server sending an offer, but then the client instead of sending a request packet goes back to sending another discover packet again. And what is troubling is that dnsmasq never responded to the pxe clients discover request. Are you sure the dnsmasq service is running on your fog server? ps aux|grep dnsmasq should return something

[Tom Elliott]

@george1421 I’ve seen this a couple of times as well, but I don’t need the moderator rights to get it, basically I click on the file it gives me an error page. If I change the name just a tiny bit I get 404, when I hit back it prompts to download the file.

[cnkpadobi]

root@imagingvm:~# nobody 1502 0.0 0.0 33140 3132 ? S 15:41 0:01 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.1.1 --conf-file=/var/run/NetworkManager/dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d
root 14476 0.0 0.0 18316 2292 pts/14 S+ 17:42 0:00 grep --color=auto dnsmasq
nobody: command not found
root@imagingvm:~# root 14476 0.0 0.0 18316 2292 pts/14 S+ 17:42 0:00 grep --color=auto dnsmasq

[cnkpadobi]

@george1421 I dont think it is started but when I try I get this message

dnsmasq: illegal repeated keyword at line 2 of /etc/dnsmasq.conf

[george1421]

@cnkpadobi ok what is the illegal keyword on line 2 of the config?

[cnkpadobi]

@george1421 not sure this is what it says

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

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

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

# 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

[george1421]

@cnkpadobi are there any other config files in the /etc/dnsmasq.d directory?

dnsmasq will read all configuration files in /etc/dnsmasq.d directory. If there is more than one that has conflicting settings it will throw an error.

Now there is another check to see if dnsmasq is running netstat -an|grep 4011 It should return something that looks like this if its running. Port 4011 is managed by dnsmasq.

sudo netstat -an|grep 4011
udp        0      0 0.0.0.0:4011            0.0.0.0:*                          

[cnkpadobi]

@george1421

Here are the files listed

ltps.conf ltsp.conf ltsp.conf~ network-manager README

that command does not produce any results

[cnkpadobi]

@george1421 so if I run the sudo netstat -an|grep 4011 it should give me something correct versus taking me back to the prompt?

[george1421]

@cnkpadobi said in Issues booting UEFI devices a:

ltps.conf ltsp.conf ltsp.conf~ network-manager README

I don’t quite understand the above line. Taking it out of context it appears there are more than one configuration file.

1. ltps.conf
2. ltsp.conf
3. ltsp.conf~

In that directory.

[george1421]

@cnkpadobi said in Issues booting UEFI devices a:

@george1421 so if I run the sudo netstat -an|grep 4011 it should give me something correct versus taking me back to the prompt?

If it takes you back to the command prompt, then that tells us the dnsmasq is NOT running on your fog server.

[cnkpadobi]

@george1421

YES, all 3 config files are in that directory

[george1421]

@cnkpadobi lets remove all but the correct one (like the one I posted). We can only have one configuration file in there with the options I provided. AND if that is the case /etc/dnsmasq.conf should remain unchanged from the original install.

I would suggest that we keep the standard file of /etc/dnsmasq.d/ltsp.conf and then remove the rest.

[cnkpadobi]

@george1421 should those configure files be rename or removed?