UEFI PXE not downloading ipxe.efi file

[zacadams]

@hammett131 said in UEFI PXE not downloading ipxe.efi file:

@zacadams I have had a few issues with ipxe.efi file boot a couple options I have found one @george1421 already mentioned updating the bios helped but I also legacy booted with an undionly.kpxe and then have it download the uefi image then before it tries to boot into windows change back to uefi. I know it’s alittle annoying but it did work for those that even when I updated the bios was having an issue. (and where I work quick turn around is more important then spending along time on imaging)

So you are saying I should try to boot with undionly.kpxe in UEFI?

[Hammett131]

@zacadams It will boot to legacy bios but you download your uefi image then just changed to uefi after the imaging is done. Or are you trying to upload an image?

[zacadams]

@hammett131 the problem occurs when downloading the image from the fog server.

[george1421]

@zacadams were you ever able to upload the file to a dropbox/google drive? If you don’t have that available, change the extension from .pcap to .txt and upload it into the fog forum. The Developers don’t typically like that because it consumes space on their servers. The pcap file will tell us a bit more of what is going on.

Just for clarity, you can only boot a uefi boot loader (ipxe.efi) on uefi hardware and you can only boot a bios boot loader (undionly.kpxe) on bios/legacy hardware. Any other combination will not work.

[zacadams]

@george1421 I have not yet, unfortunately my office flooded last week so I am just now getting back in. I will attempt to get it today.

[Sebastian Roth]

@zacadams Looking at the picture I not only see ipxe.efi* but there seem to be even more random bytes at the end of that filename. No wonder this is not being properly downloaded by the client.

What kind of DHCP server do you use? Please post config here.

[zacadams]

@sebastian-roth the campus has multiple DHCP servers so I am not completely sure, but we use Infoblox as a means of applying settings across networks.

[Sebastian Roth]

@zacadams said in UEFI PXE not downloading ipxe.efi file:

Infoblox

Ahh right, ok. Haven’t looked into Infoblox myself much but as far as I know it’s based on ISC DHCP - which we use when installing FOG with a DHCP server as well. Would you be able to take a screenshot of the configuration and post here?

[george1421]

Well I see what the issue is, but I’m not sure how to fix it (hint: the splat ( * ) indicates what’s wrong). It seems to be a DHCP server problem.

I was working with @zacadams over chat this afternoon and he shared a pcap from the point of view of the pxe client. Here is the relevant part of the pcap.

Note in option 67 the boot file name is ipxe.efi and the length is 8. Sweet that looks right. But if you look at the hex code associated with the entry You see it starts out with 0x69 which is the ascii letter i. If you look immeiatly to the left of that letter I you see 0x08, meaning the name is 8 characters log. All good. If you look to the end of the name after .efi you see a splat character, well damn. If you continue on the next hex code is 0x04, 0x81, 0x78. Now look at the source file from the from the original pcap.

Notice that the hex codes associated with that file name is pretty close to the troubled dhcp packet.

Just for a contrasting opinion. Here is what a proper dhcp packet looks like

Note the boot file name here is undionly.kpxe. If you look at the hex code you see that to the left of the ascii u there is 0x0f ==15. But the key here is look at the hex code next to the e in kpxe. 0x00 is the end of string character. That hex code is missing from the broken dhcp offer. In the broken dhcp offer its a splat ( * ) so the pxe booting client thinks the rests of the text is part of the file name until it finds the first 0x00 hex code.

[Sebastian Roth]

@george1421 @zacadams Yeah, good catch. I am fairly sure you’re right there! Missing 0x00 string termination in the filename is probably causing the issue. Not sure what to do about this.

[george1421]

@sebastian-roth I looked at the shared pcap with a fresh set of eyes this AM and that is consistent throughout the dhcp server responses. It correctly sets the string length but doesn’t terminate the string with 0x00. While it complies with the letter of the IEEE document, it doesn’t follow common practices. I did check a few other pcaps I had laying around and all responses from those random dhcp servers had the string length and 0x00 in the hex code. It appears this Infoblox dhcp server is doing something a bit different. The OP may need to get with Infoblox and show them what he is seeing.