UEFI Boot

[Sebastian Roth]

@londonfog Absolutely sure there is no typo in the “fogip” part of the URL? Would you run tcpdump -nn port 80 on your FOG server when booting the client in UEFI mode to see if it even tries to open the TCP connection?

[londonfog]

@Sebastian-Roth I’m sure there is no typo considering legacy boot still works fine. But when I get into the office I’ll do a dump to see if anything stands out.

[londonfog]

@george1421 I happened to look at /opt/fog/.fogsettings and noticed that bootfilename= is ‘undionly.kpxe’ should this be changed to include ipxe.efi?

[george1421]

@londonfog The .fogsettings file would be only used if FOG was your dhcp server. I don’t think that is the case here.

The tcpdump that Sebastian recommended would surely capture if that uefi client was talking to the FOG server. I might add in port 69 so you get the timing of the tftp download too.

so the tcpdump command would be tcpdump -nn port 80 or port 69 From there you should see the tftp download of ipxe.efi, then ipxe reaching out to get default.ipxe file, and then ipxe attempting to access boot.php via http protocol.

For completelness here is my tutorial on when pxe booting goes back what to do: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

The relevant capture string from there is: tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 In your case you want to add in http so the capture string would look like this tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 or port 80 This will output the capture into the output.pcap file you can review in wireshark.

[londonfog]

@george1421 so after the connection times out I decided to hit ‘s’ and drop to the iPXE prompt. And then I manually called the chain command I saw listed near the bottom of my boot.php file which is:
:bootme
chain -ar http://xxx.xx.xx.x/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot

I manually typed out the chain line and it boots to my fog menu page… So i’m glad I can atleast make the connection, i’m just stumped why it’s not automatically doing it?

[george1421]

@londonfog Can you get me a screen shot of that exact text?

The reason why I question it is the default.ipxe file should have a different format. What you are telling me, I might expect from the boot.php file itself. So this IS a clue to what is going sideways.

Here is what the default.ipxe file should look like

#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch ${buildarch}
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
param sysuuid ${uuid}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://<fog_server_ip>/fog/service/ipxe/boot.php##params

Here is the very bottom of what boot.php outputs

param sysuuid ${uuid}
:bootme
chain -ar http://<fog_server_ip>/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot

Well rereading your post. I can see I was off point here. Lets try this.

When you pxe boot and get the http timeout error, hit s to stop and then key in manually.

chain http://<fog_server_ip>/fog/service/ipxe/boot.php I’m only interested to see if you get an output from boot.php. It may be nonsensical but that will test if http works from the target computer.

If that works, find a inexpensive unmanged switch and place that between the pxe booting computer and the building network switch. The cheaper the switch the better (think the $20 monoprice switch). While I SERIOUSLY doubt this is a spanning tree issue, it might explain random communications.

[londonfog]

@george1421

default.ipxe
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch ${buildarch}
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
param sysuuid ${uuid}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://<fogIP>/fog/service/ipxe/boot.php##params

bottom of boot.php
param sysuuid ${uuid}
:bootme
chain -ar http://<fogIP>/fog/service/ipxe/boot.php##params ||
goto MENU
autoboot

Now I have hit ‘S’ at the time out error to drop to a ipxe shell and have successfully booted to the fog menu by running
chain -ar http://<fogIP>/fog/service/ipxe/boot.php##params

[george1421]

@londonfog I can’t believe I did not ask you the version of FOG you are using. What version of FOG?

[londonfog]

@george1421 1.5.5

[george1421]

@londonfog Hmm, ok that isn’t it then. I thought it was possible that something happened with the 1.5.8 update and ipxe.efi was damaged some how.

In each of the boot loaders (undionly.kpxe and ipxe.efi) there is a script that calls default.ipxe on the FOG server… But thinking about it now, its getting past that point because it calls default.ipxe which chains to bootp.php. That http call is failing for some reason. So default.ipxe has already been loaded by ipxe.efi.

I don’t have an answer why only uefi has this issue. I can say that 1.5.5 is kind of old, but I don’t remember your issue being an issue in 1.5.5. I guess you could try ipxe.efi from 1.5.8 to see if that changes anything. Here is the link to the github site where you can download ipxe.efi https://github.com/FOGProject/fogproject/tree/master/packages/tftp

[londonfog]

@george1421 interesting.

when I type `chain http://fogip/fog/service/ipxe/boot.php’ it times out

it does not time out when I run `chain -ar http://fogip/fog/service/ipxe/boot.php’

[george1421]

@londonfog OK for grins, update /tftpboot/default.ipxe and add in the -ar into the chain call.

[george1421]

@londonfog Very sneaky for the @developers to use an undocumented command switch to make things “just work” when we don’t expect them to.

use the undocumented "chain -ar" option (--autofree and --replace); this will prevent iPXE from running out of memory after several iterations

ref: https://forum.ipxe.org/showthread.php?tid=6944

[Sebastian Roth]

@george1421 said in UEFI Boot:

… after several iterations

I have no idea why using -ar would fix the issue for @londonfog. Very funny I think. From my point of view it wouldn’t hurt to add this to our default.ipxe as well. Though this is pretty much untested and I am not sure we want it in the 1.5.x branch.

[londonfog]

@george1421 I added it to my default.ipxe and no such luck. ::shucks::

[Sebastian Roth]

@londonfog To me it all sounds as if there is a web filter killing some of those requests but not all. I have no idea why it would only happen for the UEFI devices though.

The only chance I see to really know what’s going on is to capture network packets and see what we can find in that. Install packet tcpdump on your FOG server and run tcpdump -w /tmp/out.pcap host x.x.x.x and port 80 (put in the IP of the client which is trying to PXE boot instead of x.x.x.x!)

Leave that command alone and boot up the client till it hits the error. Then stop tcpdump (ctrl+c), grab the out.pcap file, upload to a fileshare and post a link here.

[george1421]

@londonfog said in UEFI Boot:

I added it to my default.ipxe and no such luck. ::shucks::

So why when you hit s to escape and type in the same exact command does it fail? There seems to be something inconsistent here. Again the only variable I see is time, if you are typing it in exactly as you see in the default.ipxe file one might think you should get the same answer.

I think we DO need to get a pcap of this dialog.

I think I would modify sebasitan’s pcap by dropping the and port 80 part. Seeing all communications between the FOG server and the target computer will help us see if something we don’t expect .

[george1421]

I think we need to add a bit of detail to this thread too.

Is only one specific uefi doing this, or have you tested with multiple uefi systems?

What mfg and model of computer have you tested this failing on?

[londonfog]

@george1421 I have tested with two different UEFI systems. Both Dell however.

I have a pcap now, looking through it I see this line [ETHERNET FRAME CHECK SEQUENCE INCORRECT] and it’s corresponding to the boot.php.

[george1421]

@londonfog It would be helpful if one of us could look at the pcap. Upload it to a file share site and either post the link in the forum or DM either sebastian or myself and we will look at the capture. Once we look at it you should remove the pcap from the fileshare site.