UEFI Boot

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.

londonfog

This post is deleted!

londonfog

This ended up being the case. Apparently there was a bug in the version of ipxe.efi and cloning the version in the github repo below resolved the issue. I was so caught up in other things I forgot to actually try this until I was reading over this thread again today.

Thank you for your help!

@george1421 said in UEFI Boot:

@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

UEFI Boot

149

11.7k

17.2k

154.7k