Detect if PXE client is already iPXE

  • This would have the impact of potentially removing the need for TFTP for those PXE clients and using only HTTP or perhaps even HTTPS at some point.

    For example, lets say I have a VM running on Nutanix, which by default uses SeaBIOS and iPXE as the boot ROM. It’s a bit redundant to load undionly.0 and then ipxe.0 and then proceed down the path of booting into the FOG menus.

    It’s fairly straightforward to get an existing iPXE ROM to load a script or menu via HTTP using DHCP …


    if exists user-class and option user-class = "iPXE" {
        filename "http://${next-server}/fog/service/ipxe/boot.ipxe";
    } else {
        filename "undionly.kpxe";


    # The dhcp-match sets the ipxe tag for requests from iPXE.
    # iPXE sends a 175 option
    # The boot filename, Server name, Server Ip Address

    May also be able to use the DHCP option “user class” in dnsmasq.conf, but the above works just fine. I have only tested in proxy mode but it does work just fine … my DHCP server will be off-limits in production.

    So, trying this I copied over /tftpboot/default.ipxe into /var/www/fog/services/ipxe/boot.ipxe.

    The first thing that happened when dnsmasq sent over boot.ipxe as the file to load, exception thrown because all of the “params” and “param” statements in that file were of course not recognized by my iPXE boot ROM causing an exception and halting any progress. Based on a quick look through boot.php in the ipxe directory and then other php code further up the chain (bootmenu.class.php etc), I assume these are PHP arrays and variables. Of course, the FOG-provided chain loaded iPXE ROM seems to load just fine - so perhaps “default.ipxe” is the wrong place for me to start … I’m still digging around 🙂

    Now, if I trim back boot.ipxe (default.ipxe) to instead contain only the following, I successfully boot to the FOG menu … however it has no styling or background PNG, only plain ncurses type PXE menu but all of the standard FOG options are there.

    cpuid --ext 29 && set arch x86_64 || set arch ${buildarch}
    chain http://${next-server}/fog/service/ipxe/boot.php?mac=${net0/mac}

    Now from here all I tried to do was click on the deploy image option and again I was given an exception stating that “params” was an unknown.

    I’m going to continue to poke around, because obviously FOG is already working properly via iPXE once it’s chain loaded from undionly. So, I believe this may not require much in the way of codebase change, but perhaps configuration change.

    As a side note, for physical hosts my plan would be to utilize UEFI HTTP Boot to load the iPXE ROM (vs using the Intel hardware PXE ROM) and then loading up the same boot.ipxe script via HTTP as shown above. Goal would be to eventually move all of this to HTTPS, but … baby steps!!

    If you have any quick tips about where to look next that would be appreciated. I think as you look to the future and using UEFI HTTP(S) Boot and removing the hard requirement for TFTP for that initial undionly.0 for folks that may not want TFTP installed, this could be a good feature request.

  • @Sebastian-Roth Thanks that all makes sense.

    Thanks Sebastian — from my point of view I could still get rid of TFTP by recognizing either UEFI HTTP Boot (physical hardware) or existing iPXE ROM (in my Nutanix VM) vi DHCP headers (vendor class / user class) and in either case chainload the FOG iPXE binary (with “params” enabled) via HTTP and eventually perhaps HTTPS.

    This should be pretty straightforward, I’ll see if I can work it out and I’ll post back - may be worth a wiki article.

    Now … the next item to tackle would be replacing FTP (vsftpd) with SFTP 🙂

    Feel free to close this thread if it’s no longer appropriate as a “feature request”.

  • Senior Developer

    @jms On the one hand side you are definitely on the right track using /tftpboot/default.ipxe as basis to start from. The error you see about “params” being unknown stems from a iPXE binary (included in the VM) that does not have the “params” command option compiled into it. From my point of view this is kind of a show breaker as a couple of things within our FOG menu only work using params. Sure you can get around some of them as you did by converting the initial default.ipxe but I am afraid this is not a route we generally want to go with FOG. Although it would be really great to get rid of TFTP altogether I think the time has not come yet.

    But don’t feel discouraged by what I say. Keep playing with this and you might find a great way to achieve what you want and can share this with us!

    Maybe start by asking Nutanix if they will provide an iPXE binary with params enabled. See here for the setting in the header file we use: EFI and legacy BIOS (full set of configs we compile EFI style and legacy BIOS iPXE from)