[syslinux] PXE Chain Booting for UEFI PXE Boot

[Frantisek Rysanek]

On 10 Aug 2022 at 15:44, Lukas via Syslinux wrote:
> 
> Hi Guys,
> 
> I want to configure a pxelinux.cfg file for Chain booting to another PXE 
> Server under UEFI.
> 
Do you have a specific reason to chainload the UEFI-flavoured loader 
after pxelinux ? Want to give the user an explicit choice maybe?
Would starting a UEFI-flavoured bootloader directly by DHCP solve 
your problem?
Actually I believe a "legacy BIOS" flavoured option-ROM won't cater 
for a PXE-flavoured bootloader, and vice versa.

There is a way to configure the DHCP server to make a distinction 
between a "legacy BIOS" PXE oprom and a UEFI-flavoured PXE oprom.
DHCP then "knows who is asking", and serves the right flavour of a 
bootloader.
Below my signature I'll paste an excerpt from my config of ISC dhcpd.

That config does not prevent you from e.g. making a specific "host" 
entry that serves yet another bootloader, and overrides the more 
general config. I've used this to serve ephemeral bootable images of 
OpenWRT to a Mikrotik Routerboard (in order to flash a permanent 
image into the onboard NAND chips.)

Regarding the crossover from legacy BIOS PXE to UEFI PXE,
I've been through this before, a couple years ago - and got the same 
advice.
IME, as great as Syslinux is, and is doing a wonderful job as "legacy 
BIOS" bootloader, it hasn't quite transitioned into the UEFI era. 
That's where iPXE steps in.
If you want further help with the config of ipxe, let me know by 
private e-mail - this is a support list for systlinux, not for ipxe.

As for redirecting the diskless machines to another TFTP server for 
UEFI-specific stuff, you can do it via DHCP straight away (specify a 
different next-server in the specific config block) or you can still 
serve iPXE binaries and config from your "legacy" TFTP server, but 
load whatever follow-up bootable images from a different server 
machine (TFTP, NFS, HTTP, maybe more).

Frank
Frantisek DOT Rysanek AT post DOT cz

-------------- ISC dhcpd.conf excerpt follows -------------------

option architecture-type code 93 = unsigned integer 16;
option vendor-class-identifier code 60 = string;

# stuff needed for pxelinux custom options
option magic      code 208 = string;
option configfile code 209 = text;
option pathprefix code 210 = text;
option reboottime code 211 = unsigned integer 32;

if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
  next-server 192.168.what.ever;

  if option architecture-type = 00:00 {
    # the traditional "BIOS PXE"
    #
    # Note: as pxelinux.pathprefix is a hint to pxelinux after it has 
    # started, the "filename" for the raw PXE stack needs to contain
    # the full path
    filename "pxelinux/3.53/pxelinux.0";
    #site-option-space "pxelinux";
    option magic F1:00:74:7E;
    option configfile "cfg/default";
    option pathprefix "pxelinux/3.53/";
    option reboottime 30;
    option dhcp-parameter-request-list = concat(option 
dhcp-parameter-request-list,d0,d1,d2,d3);
  }

  if option architecture-type = 00:09 {
    # Note: as pxelinux.pathprefix is a hint to pxelinux after it has 
    # started, the "filename" for the raw PXE stack needs to contain
    # the full path
    filename "ipxe/ipxe.efi";
  }

  if option architecture-type = 00:07 {
    # Arch 07 (EFI BC) is sometimes (mis)used for EFI x64 boot
    # by some vendors. Practically observed by us.
    #
    # Note: as pxelinux.pathprefix is a hint to pxelinux after it has 
    # started, the "filename" for the raw PXE stack needs to contain
    # the full path
    filename "ipxe/ipxe.efi";
  }

  if option architecture-type = 00:06 {
    # In reality, 32bit x86 EFI can only be relevant to some
    # very old Macintosh (reportedly). Some AMI APTIO tools
    # are still published in 32b flavour, but we've never met
    # 32bit APTIO in practice, in actual PC hardware.
    filename "pxelinux/6.03/efi32/syslinux.efi";
    
    # Arch 06 (EFI IA32) is sometimes (mis)used
    # for legacy (CSM) boot of x64 machines by some vendors.
    # Not observed at our site.
  }
}