PXELINUX-Multi-Arch

From Syslinux Wiki
Revision as of 16:53, 9 October 2014 by GeneC (talk | contribs) (Distinct directory: spell out some examples)

Jump to: navigation, search

Placing multiple architectures (BIOS, EFI32 and EFI64) into 1 common TFTP root requires careful attention as the they will search for the same configuration files and COM32 modules and library modules although identically named, come in 3 distinct incompatible architectures. Outlined below are several techniques that can allow all three to boot. This applies to Syslinux 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 eliminates any use of menu.c32/vesamenu.c32 through the UI directive (setting DEFAULT to point at a ui system like menu.c32/vesamenu.c32 is discouraged).

Place pxelinux.0/ldlinux.c32 (BIOS), syslinux.efi(efi32/efi/syslinux.efi renamed uniquely as syslnx32.efi or bootia32.efi)/ldlinux.e32(EFI32), and syslinux.efi(efi64/efi/syslinux.efi renamed uniquely as syslnx64.efi or bootx64.efi)/ldlinux.e64(EFI64) into the appropriate directory on the TFTP root.


Common directory distinct config

In this setup, COM32 modules can be fully utilized however this depends on the effective use of DHCP option 209, either by built-in options (coded into the booting binary pxelinux.0/syslinux.efi by pxelinux-options) or by feeding the PXE booting client DHCP option 209, either by encapsulating within vendor-options (DHCP option 43) or forcibly inserting it into the offer/acknowledgement, as it's not requested by default. If utilizing the built-in options, this would make all clients running a single binary use a single config.

All 3 architectures should be configured to utilize a unique configuration file that includes a PATH statement to an architecture-specific directory for COM32 modules and library modules.

Distinct directory

In this setup, each architecture boots a unique directory, has its own configs and COM32 modules and library modules. File reuse can be achieved by one of several other techniques that may depend on the particular TFTP system's capabilities (ie symlinks). For an example, BIOS clients will load "bios/pxelinux.0", EFI32 clients "efi32/syslinux.efi" and EFI64 clients "efi64/syslinux.efi". This allows all architectures to use their full capabilities.

Distinct directory common kernel path

When referencing a kernel file, ie vmlinuz, reference a common path ie "::boot/vmlinuz" (TFTP to current TFTP server starting in root) or "http://192.0.2.3/boot/vmlinuz" (if using a system capable of HTTP transfer; pxelinux.0 atop gPXE/iPXE with HTTP support, lpxelinux.0, and syslinux.efi can provide this). Avoid using "../" as that does not strip a directory but rather adds another part to the path that the TFTP server must then interpret which one hopes would be effective (but is often not).

Distinct directory symlink path

If the file "boot/vmlinuz" exists, creating a symlink at "bios/boot/" targetting "../boot" or "/tftproot/boot" (presuming the tftpd can resolve this symlink depending perhaps on a chroot) would allow the reference "boot/vmlinuz" to be resolved to the file "/tftproot/boot/vmlinuz" by the underlying system for BIOS clients whose current directory is "/tftproot/bios/".

Some tftpds may also provide for a virtual path option that would work in a similar fashion.

Distinct directory symlink file

If the file "/tftproot/boot/vmlinuz" exists, creating a symlink "vmlinuz" in the directory "/tftproot/bios/boot/" targeting "../../boot/vmlinuz" would be resolved to the file "/tftproot/boot/vmlinuz"