Has something changed with UEFI?
-
@svalding The problem specifically, I think is the boot file you’re using. What file do you have set for this machine? Keep in mind different files for different architectures via dnsmasq.
After knowing what file you’ve always used for UEFI, we can then back track, trying different versions of that file, until we find a version that is working. After that, we can begin to move forward to find the version where it breaks, and figure out what changed. Do you understand?
-
I’ve got BOOTP settings as follows:
Boot File: undionly.kpxe
Next Server: Fog server IP address
Boot Server: Fog server IP addressLegacy clients are using the undionly.kpxe, while UEFI devices are using ipxe.pxe (I believe, this could be flip flopped, going from memory at the moment)
-
@svalding UEFI should not be using ipxe.pxe, it should be using ipxe.efi.
-
I lied, I am looking at my dnsmasq config now. It’s snponly.efi
-
@svalding You need to ensure you have the latest version of dnsmasq since earlier versions do not support efi very well (at all). Even if their configs say they do. You need the release that was created since (about) may 2016
-
I have updated to the latest version that was linked here earlier.
-
@svalding said in Has something changed with UEFI?:
I have updated to the latest version that was linked here earlier.
OK, just wanted to make sure you weren’t using your linux distro’s version which may be a few releases behind. Version 2.76 or newer is where you want to be.snponly.efi should work or you can use ipxe.efi (contains all known drivers) if you have issue with snponly.efi.
-
I’m going to switch the config to ipxe.efi and see what happens.
-
I want to put this out there that I got that information from a file called ltsp.conf in /etc/dnsmasq.d.
There is an /etc/dnsmasq.conf file, but it is completely commented out like it is not being used for anything.
-
@svalding Not sure I understand, but the dnsmasq.conf is the old style/way to setup dnsmasq. The newer way is for each dnsmasq service to place its config file in /etc/dnsmasq.d directory. When the dnsmasq process starts it reads through the dnsmasq.conf file (which is commented out) and then it processes the config files in the dnsmasq.d directory. Think of the dnsmasq.conf file is for global dnsmasq settings (for all dnsmasq services) and the individual files for service specific settings. Understand the dnsmasq can do a lot more than just proxyDHCP.
-
So after looking over this thread, I have to ask the question, why are you using dnsmasq? What dhcp server do you have? Is it restricted so you can’t make changes?
-
That makes perfect sense, so this is setup how it should be. dnsmasq starts, reads the commented file, and then moves on to ltsp.conf, where we have defined all of our settings.
I just tried with snponly.efi, and ipxe.efi and neither of them are loading up.
Here is a screen grab from a video I took of the process.
And here is the screen it immediately jumps to.
-
Also, I want to point out some stuff with dnsmasq that has tripped me up before.
Firstly, it uses WHAT-EVER it finds inside
/etc/dnsmasq.dDoesn’t matter what it’s named. ltsp.conf, ltsp.conf.old, MyXmasWishList.txt - it does not care. If you have backup configurations in there, move them somewhere else.
Maybe that issue is resolved in the newer version, I don’t know.
Second - when dnsmasq sends out it’s ProxyDHCP - it appends
.0to thefilenameit gives. You could do some complex stuff with symbolic links, but I prefer not to. I prefer to copy the file I want to use. In your case, let’s go with ipxe.efi. You’d copy that like so:cp /tftpboot/ipxe.efi /tftpboot/ipxe.efi.0 -
@george1421 We use an Infoblox appliance that is controlled by the main campus of our university. We have some control over it, such as adding in the DHCP options, but not much else.
-
@svalding said in Has something changed with UEFI?:
@george1421 We use an Infoblox appliance that is controlled by the main campus of our university. We have some control over it, such as adding in the DHCP options, but not much else.
OK understood. I just wanted to make sure we are going down this path for the right reasons.
I forgot about the part that Wayne mentioned (the weird behavior of dnsmasq with adding .0 to the file name). As a test you can do the copy thing, but I would create a symbolic link instead. That way if/when you update FOG you won’t have an old (static) copy of ipxe.efi causing issues.
-
Sure thing. My brain is fried for the day. I’m going to pick this up tomorrow morning. Hopefully the network guy is in the office at main campus and I can work with him on getting some tcp dumps from the traffic for this dhcp offer/ack process.
Also I am going to try to setup port mirroring on the switch this machine is plugged into and do a wireshark there. I’ll get to the bottom of it!
I appreciate all you gentleman’s help today. It’s been quite a learning curve having to pick this up while the guy who usually handles it is out.
-
@svalding If you have some skills you can do the packet capture right from the fog server.
If you install tcpdump on your fog server you can capture what you need with.
tcpdump -w output.pcap port 67 or port 68 or port 69Start the capture then boot the pxe target, keep recording until the pxe client errors out then stop the capture. If the dhcp server, fog server and target computer are in the same subnet the fog server will hear everything since dhcp communications are broadcast based. Just take the pcap file and load it into wireshark to review it. If you have questions then post the pcap file to the forum so the devs can take a look at it. The answers will be in the pcap what is really going on.
-
Here’s the PCAP file. It looks like TFTP is trying to give it undionly.kpxe, which isn’t right!
-
I"m going to do another capture against a mirrored port. The machine and the fog server are on separate VLANs, so i’m not sure I’m grabbing all the packet data that I can get if I were to mirror the port on the switch. I’ll post that information as well once I have it.
-
@svalding Just for clarity the fog server is not in the same broadcast domain (vlan) as the target computer or the dhcp server?
