UEFI Boot
-
@londonfog OK for grins, update /tftpboot/default.ipxe and add in the
-arinto the chain call. -
@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 -
@george1421 said in UEFI Boot:
… after several iterations
I have no idea why using
-arwould 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. -
@george1421 I added it to my default.ipxe and no such luck. ::shucks::
-
@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.
-
@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 80part. Seeing all communications between the FOG server and the target computer will help us see if something we don’t expect . -
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?
-
@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.
-
@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.
-
This post is deleted! -
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
