Placing respective boot loader files for multiple firmware architectures (BIOS, EFI IA32 and EFI X64) into one common TFTP root, requires careful attention:
- each boot loader file will search for the same configuration files; and,
- c32 modules, although identically named, come in distinct incompatible architectures.
Several techniques can allow all three architectures to boot. This applies to Syslinux version 6.00 and greater (introduction of EFI32/EFI64 to Syslinux).
Common config no COM32
In this setup, you either can not use any COM32 modules or must not attempt to execute the foreign-architecture COM32 modules. This setup eliminates any use of (vesa)menu.c32.
Place the following files in the same location:
- pxelinux.0 together with ldlinux.c32 (BIOS); and,
- syslinux.efi (efi32/efi/syslinux.efi renamed uniquely, e.g. as syslnx32.efi or bootia32.efi) together with ldlinux.e32 (EFI IA32); and,
- syslinux.efi (efi64/efi/syslinux.efi renamed uniquely, e.g. as syslnx64.efi or bootx64.efi) together with ldlinux.e64 (EFI X64).
Common directory distinct config
In this setup, COM32 modules can be fully utilized. However, this setup depends on the effective use of DHCP option 209, either by:
- feeding the network booting client DHCP option 209, either by:
- encapsulating within vendor-options (DHCP option 43); or,
- forcibly inserting it into the offer/acknowledgment, as it is not requested by default; or by,
- built-in options, coded into the booting pxelinux.0/syslinux.efi binary by means of the pxelinux-options tool. In this case, clients running the same binary would use a single config.
Each architecture should be configured to utilize a respective configuration file that includes a PATH statement to an architecture-specific directory for c32 modules. If you call c32 modules only by name (ie "COM32 vesamenu.c32"), PXELINUX will then automatically search into the paths specified when the module is not found in the current directory.
From here, you can then utilize the INCLUDE directive to include more configuration files (that might be common) to build out your desired environment.
In this setup, each client's architecture boots to a respective working directory containing its own configs and its own c32 modules. File reuse can be achieved by one of several other techniques that may depend on the particular TFTP system's capabilities (e.g. symlinks). For example, BIOS clients will load "bios/pxelinux.0", EFI32 clients will load "efi32/syslinux.efi" and EFI64 clients will load "efi64/syslinux.efi". This setup allows all architectures to use their full capabilities.
Distinct directory common kernel path
When referencing a kernel file (e.g. vmlinuz), reference a common path. For example:
- "::boot/vmlinuz" - TFTP path to current TFTP server starting in its root; or,
- "http://192.0.2.3/boot/vmlinuz" - using a system capable of HTTP transfer, provided by:
- pxelinux.0 atop gPXE/iPXE with HTTP support; or,
- lpxelinux.0; and/or,
Try to avoid using "../" notation, as it does not strip a directory but rather adds another part to the path that the TFTP server must then interpret, which one hopes it would be effective (but it is often not).
Note: The paths and file names used in this section are examples only, and are not to be interpreted verbatim.
Presuming that the tftpd can resolve directory paths' symlinks, depending perhaps on a chroot...
Example for BIOS clients:
When the "boot/vmlinuz" kernel file exists, creating a symlink at "bios/boot/" targeting "../boot" or "/tftproot/boot" would allow the "boot/vmlinuz" reference to be resolved to the "/tftproot/boot/vmlinuz" file by the underlying system whose current directory is "/tftproot/bios/".
Some tftpds may also provide for a virtual path option that would work in a similar fashion.
When the "/tftproot/boot/vmlinuz" file exists, creating a "vmlinuz" symlink in the "/tftproot/bios/boot/" directory targeting "../../boot/vmlinuz" would be resolved to the "/tftproot/boot/vmlinuz" file.