My existing network environment provides the following:

  • DHCP server that sends PXE clients to a particular TFTP server
  • TFTP server with SYSLINUX "pxelinux.0" file for booting

The SYSLINUX installation defaults on timeout to "boot from local disk", which allows existing clients to reboot correctly but also provides for the option of booting into a rescue or provisioning environment.

I am testing a new provisioning environment which resides on a different TFTP server than the one pointed to by the DHCP server. Existing clients depend upon the current environment, but I'd like to refer test clients to the new TFTP server for provisioning.

Ideally I'd like to be able to use a particular menu option from the SYSLINUX prompt that would cause the client to boot from another (hardcoded, rather than DHCP-server-provided) TFTP server.

I tried installing a custom gPXE image as a menu option on SYSLINUX. The custom image (re-)acquired a DHCP address and went to the hardcoded TFTP server, but it's missing a piece that I don't think gPXE is capable of fulfilling.

The new provisioning system is based upon Cobbler, and it depends upon the usual PXE sequence where the client looks for a file named with its MAC address before settling for a less-specific, and eventually generic, file. From what I can tell, it appears that gPXE isn't capable of doing this mac-address-based boot sequence.

Can anyone tell me of another way to do this? I've been banging my head for several days on this problem. Thanks in advance!

2 Answers 2


PXE/TFTP chaining within same server

Put the other PXE boot loader as kernel.

This is the example I used to chain load BSD PXE boot loader from Linux PXE chain loader.

LABEL openbsd
    MENU LABEL ^OpenBSD 3.9
    KERNEL openbsd_3.9/pxeboot.0

PXE/TFTP chaining to another server

pxechain.com used to chain load other PXE server.

pxechain.com is available within syslinux-common package in Debian/Ubuntu or syslinux project archive under different filename pxechn.c32.


LABEL pxeserver2
        menu label Switch to 2nd PXE server...
        kernel pxechain.com

Example2: (Thanks to Ashark) In case your pxelinux's config file name and/or path to it differs on both pxe servers, you should explicitly define them with options -p and -c, otherwise, it wont't work (it will try to use a value defined by dhcp that was used for current booting).

On the DC-ISO2 server config:

        MENU LABEL DC-ISO1 (BIOS mode)
        KERNEL pxechn.c32
        APPEND -c default -p /
        TEXT HELP
Boot the legacy dc-iso1 menu in bios mode.

On the old DC-ISO1 server config:

        MENU LABEL DC-ISO2 (BIOS mode)
        KERNEL pxechn.c32
        APPEND -p /configs/ -c bios.cfg
        TEXT HELP
Boot the new dc-iso2 menu in bios mode.

Technically, you can now even disable DC-ISO1's dhcp server (but not tftp), and you will always boot to DC-ISO2 first, while being able to switch between both server's menus.

  • 1
    In my case (pxelinux 6.04-pre1-41-g5e426532) it did not work without specifying a config file, so my working config looks like this: LABEL pxeserver2 MENU LABEL pxeserver2 (BIOS mode) KERNEL pxechn.c32 APPEND -c bios.cfg
    – Ashark
    Commented Oct 31, 2019 at 9:21
  • @Ashark, thank you, I will append you example to my answer, it may help coming users
    – user.dz
    Commented Oct 31, 2019 at 9:28
  • 1
    I now understood why I needed to specify config file name. And I had a problem with booting a first menu again from the second menu. You should redefine values if they differs on your dhcp servers. I have now edited an information in you answer.
    – Ashark
    Commented Nov 4, 2019 at 8:56
  • @Ashark, thank you for the info and sharing. It wasn't the case when I test it before because for me it was only for Linux&BSD and all machines were in BIOS mode so used only default config. I still think if you use default paths/names, boot leader ./pxelinux.0 & config ./pxelinux.cfg/default you don't have to specify anything. UEFI has its own bootstrap loader syslinux.efi , not sure about its default paths for config.
    – user.dz
    Commented Nov 4, 2019 at 9:39
  • 1
    Booting to different mode is impossible. You need to boot the client machine in different mode manually. As of pxelinux 6.04.pre2, you cannot even chainload uefi->uefi menu: there is no pxechn.c32 for efi64 mode. (Сan grub2 do that?) But if you try to chainboot from bios to uefi mode, it will not work either. I made "APPEND -p /configs/ -c efi64.cfg" in bios.cfg and got: ``` pxechn.c32: Attempting to load '': loaded. ...Ready to boot: Attempting to boot... Booting... _ ``` With the cursor blinking.
    – Ashark
    Commented Nov 5, 2019 at 2:26

Take pxelinux.0 from Ubuntu 10.4 LTS. That will go through the "normal" iteration: MAC - IP in HEX - ... default.

It would be simpler to tell your DHCP server NOT to anwer to certain requests and set up another DHCP in the same network (not authoritative) that answers your test-server requests (and does not answer to anything else).

  • I don't have control over the DHCP server. Once the new provisioning system is "live" I may be able to get them to cut over directly to the new TFTP server, but only if I can place the rescue environment and other images out there. I will never be able to get changes made on a per-server basis. Commented Apr 1, 2012 at 0:41
  • Which pxelinux.0 boot file should the Ubuntu version replace? The one on the initial "main" TFTP server? If that's the case, will this still allow us to use the menu options that we're currently using out there? What should be in the new menu option that will point the client to the second TFTP server? Commented Apr 1, 2012 at 0:43
  • @Tony I thought you already solved that secondary TFTP part an were searching for a solution there? Anyway you can replace both. Syslinux from Ubuntu is quite "new" - compared to RedHat 5 or SLES 10. So it should be able to parse your syntax.
    – Nils
    Commented Apr 1, 2012 at 20:21
  • I had been able to point the client at the secondary TFTP site, but it was going straight for "pxelinux.0" at the secondary site and not using the normal MAC address-based sequence of requests. I felt a change on the first TFTP server might cause the client to correctly work wrt the second TFTP server. I'll give this a try and see if it does any good, although I have a feeling some config file stanzas will need to change. Commented Apr 2, 2012 at 17:30
  • @TonyKolstee what is wrong with going for pxelinux.0? That will in turn go for the "MAC"-request, then to the "IP/Hex" request.
    – Nils
    Commented Apr 2, 2012 at 21:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .