Imac 27" ipxe boot

  • Hi,

    we have a couple of 27" iMacs from late 2015. We’d like to run some tests with Fog in order to image them later on but so far, they can’t seem to get through ipxe.
    while booting on the ipxe option it gets to the

    "IPXE initialising devices...ok"


    "Waiting for link-up on net1... failed: Down ("

    I can the press “s” to get to the ipxe command line but I don’t know what to do from there …

    The dhcp is edited according to this post and it works fine with late 2014 21.5" iMacs

    According to the ipxe website : “This error indicates that the network link is down”, however the host is correctly added to the dhcp (it gets an IP once an OS is started).

    Any help is appreciated at this point, as I have no clue on what to do next…

    Thanks a lot.

    Seb B

  • Moderator

    @george1421 Just for clarity (and my ignorance of Macs) we are talking about a desktop computer with a built in ethernet adapter, right? You are not using a usb ethernet dongle adapter.

  • Moderator

    @Seb-B Ok then just to confirm, when you hit ‘s’ on the target computer and dropped to the iPXE kernel command prompt, and then waiting 30 seconds (for STP to timeout and start forwarding the port), when you issued a dhcp net0 or dhcp net1 nothing was detected by tcpdump? I’m trying to see if the iMac/iPXE is sending any data requests that might indicate it can talk out the network port.

    Secondly since the target computer is on a different subnet from the fog server you will not see the broadcast messages it is sending out, you will only see the unicast messages to the computer you are running tcpdump on.

  • @george1421

    Ok so we tried that and ran tcpdump on both the dhcp server and the fog server and didn’t get any result pas the bootp part where we get to choose ipxe from the mac boot menu.

    The tcpdump command we ran:
    tcpdump 'host and (portrange 67-69 or 4011)'

    The result :

    17:13:53.000214 IP > BOOTP/DHCP, Request from 38:c9:86:12:xx:xx (oui Unknown), length 295
    17:13:53.000463 IP Server.DOMAINNAME.bootps > BOOTP/DHCP, Reply, length 303
    17:13:53.000569 IP Server.DOMAINNAME.bootps > BOOTP/DHCP, Reply, length 321
    17:13:53.000643 IP Server.DOMAINNAME.bootps > BOOTP/DHCP, Reply, length 321

    And as soon as we click on the ipxe option, nothing is received

  • Moderator

    @Seb-B Well my thought was to have them on the same subnet (for testing), then setup tcpdump to capture any dhcp being emitted from the mac when you issue the dhcp net0 or dhcp net1 command. You can install tcpdump on the fog server or in your case setup wireshark to capture ports 67, 68 if done from the FOG server 67,68,69,4011 all udp ports.

    What I’m interested in is the target computer actually requesting anything on the network wire, or is there still an iPXE <-> Hardware issue. By doing the capture from the fog server and all being on the same subnet you can inspect the entire pxe booting process, from dhcp to tftp moving of the file to the target computer.

  • @george1421

    Actually no, the dhcp and fog server are on a dedicated server vlan while the host is on another vlan.

    However, we have half a hundred stations on this configuration and never encountered any trouble so far.

    We did a test where we check on the dhcp server while running dhcp net0 and get no request on the dhcp.

    We tried with several efi files and never got anything showing up on the dhcp.

  • Moderator

    @Seb-B Is your fog server, dhcp server, and target computer on the same subnet?

  • @george1421

    Ok, I’ve done that after waiting 30 secs and still got the no configuration method succeeded message.

  • Moderator

    @Seb-B OK, its been a while since I had to mess with the iPXE kernel. But the first thing I would try is to get to the iPXE command prompt. Wait 30 seconds and then key in dhcp net0 that will instruct the kernel to try to pick up a dhcp address.

    I’m going to have to create a similar issue here in my test lab to see if I can remember the commands to confirm the network adapter is ready. But starting with dhcp after 30 seconds will tell us if there is a timeout involved.

  • @george1421

    Yes it does, I tried some commands but I’m not really familiar withe the ipxe environment.

  • Moderator

    @Seb-B On the windows side, we’ve seen newer nic adapters support some more advanced functions (like green ethernet 802.3az) that seems to be causing issues with pxe booting. The unmanaged switch also blocks this type if pre-link protocols (which is good for us).

    When you get the error pxe booting does it give you an option to press ‘s’ to get to an ipxe command prompt?

  • @george1421

    The “working” Imacs are from late 2014 while the “not working” ones are from late 2015.

    I’m already plugged on a non manageable switch, that’s what I was trying to tell you in my last reply.
    Yes I checked the firmware for the IMac and it is up to date.

    As for the guessing, I checked this post and checked the cable integrity just in case but to no avail so far…

  • Moderator

    @Seb-B is the 21.5" iMac an older generation than the 27" iMac?

    With the efi kernel that shows the mac address, please install an unmanaged switch between the building switch and the target computer. This is a quick test to see if its a spanning tree/green ethernet issue.

    Understand we are now to the point if guessing a bit, since this is not a FOG issue but an iPXE booting issue.

    As long as we are guessing, is the firmware up to date on this target computer?

  • @george1421

    Yes the mac address of the device is correct.
    I don’t think it could be a spanning tree since
    a - I a m plugged on a switch port with no spanning tree
    b - other iMacs(21.5") on the same port have no problem getting through this step
    c - I think using the efi file with the 10sec delay would have worked if this was the case (not sure though)

    Once again, I could be wrong but spanning tree issues don’t seem logical to me in this case.

    Thanks anyhow.

  • Senior Developer

    If my memory is serving me correctly, there was a similar thread about this in the past, I’ll see if I can dig it up from the abyss. If I am remembering correctly they other person got it working.

  • Moderator

    @Seb-B said in Imac 27" ipxe boot:

    Well this is a different/interesting error.

    This is saying that it can’t get a dhcp address on interface net0. But what is interesting is that it now picks up the mac address of the nic. This tells me that the nic is initializing (!!). Can you confirm what device is 38:c9:86:12:xx:xx

    If this was a Dell box, at this point I would say your issue could be related to spanning tree, where the building switch is not using one of the fast spanning tree protocols like RSTP, fast stp, etc.

  • @Quazz
    Hi, we just tried with all snponly files and each time got

    Configuring (net0 38:c9:86:12:xx:xx)..............No configuration method succeeded (

    as a response.

  • Moderator

    @Seb-B Can you try using the snponly.efi files? Try all versions (delay, 7156, regular)

  • Hi!

    We’ve tried using the ipxe.pxe file from /tftpboot/10secdelay/ folder and this error :

    Could not open net1: Input/Output error (http://ipxe/org/1d6a4698)

    It then restarts the device initialisation and tres net 0 which appears down.

    Could it be that the driver for the card is missing from the pxe file?

  • Senior Developer

    You might be running into what another person informed me of (which prompted my creating a 10sec delay ipxe file).

    So the initial IP comes up from PXE, then hands off to iPXE which has to drop the link and re-open for it to get a dhcp (initial pxe I think is bootp?) that can use different protocols. In some cases the down/up is too fast, and the motherboard essentially hasn’t had time for the device to go down before the system is requesting the new dhcp request. (Leaving the device seeming to be marked in down).

    Please try the ipxe.pxe file from the /tftpboot/10secdelay/ folder and see if it at least helps?

Log in to reply

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.