UEFI Boot



  • Hi There,

    trying to set up uefi boot, we have it setup correctly on the dhcp side with correct options. When selecting uefi boot I get an address, it finds the server and the following happens:
    tftp://fogip/default.ipxe… ok
    http://fogip/fog/service/ipxe/boot.php…Connection Timed out (http://ipxe.org/4c0a6092)
    Could not boot: connection timed out (http://ipxe.org/4c0a6092)
    Chainloading failed, hit ‘s’ for the iPXE shell; reboot in 10 seconds

    Legacy boot still works fine. Are there parameters I need to change in boot.php or maybe in default.ipxe?

    Thanks in advance!


  • Moderator

    @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



  • 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



  • This post is deleted!

  • Moderator

    @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.



  • @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.


  • Moderator

    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?


  • Moderator

    @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 .


  • Developer

    @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 I added it to my default.ipxe and no such luck. ::shucks::


  • Developer

    @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.


  • Moderator

    @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


  • Moderator

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



  • @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


  • Moderator

    @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



  • @george1421 1.5.5


  • Moderator

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



  • @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


  • Moderator

    @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.



  • @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?


  • Moderator

    @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.


Log in to reply
 

309
Online

7.0k
Users

14.2k
Topics

134.2k
Posts