Difference between revisions of "PXELINUX-Multi-Arch"

From Syslinux Wiki
Jump to: navigation, search
(Distinct directory: spell out some examples)
(Wiki formatting. Typos. Rewording.)
Line 1: Line 1:
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).
+
[[Category:PXELINUX]]
 +
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.
  
= Common config no COM32 =
+
Several techniques can allow all three architectures to boot.  
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).
+
This applies to Syslinux version 6.00 and greater (introduction of EFI32/EFI64 to Syslinux).
  
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 config no COM32 ==
  
 +
In this setup, you either can not use any COM32 modules or must not attempt to execute the {{nowrap|foreign-architecture}} COM32 modules.
 +
This setup eliminates any use of {{nowrap|(vesa)menu.c32}}.
  
= Common directory distinct config =
+
Place the following files in the same location:
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.
+
* <tt>pxelinux.0</tt> together with <tt>ldlinux.c32</tt> (BIOS); and,
 +
* <tt>syslinux.efi</tt> (<tt>efi32/efi/syslinux.efi</tt> renamed uniquely, e.g. as syslnx32.efi or bootia32.efi) together with <tt>ldlinux.e32</tt> (EFI IA32); and,
 +
* <tt>syslinux.efi</tt> (<tt>efi64/efi/syslinux.efi</tt> renamed uniquely, e.g. as syslnx64.efi or bootx64.efi) together with <tt>ldlinux.e64</tt> (EFI X64).
  
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.
+
== Common directory distinct config ==
  
= Distinct directory =
+
In this setup, COM32 modules can be fully utilized.
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.
+
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 {{nowrap|offer/acknowledgment}}, as it is not requested by default; or by,
 +
* {{nowrap|built-in}} options, coded into the booting {{nowrap|pxelinux.0/syslinux.efi}} binary by means of the {{nowrap|<tt>pxelinux-options</tt>}} tool. In this case, clients running the same binary would use a single config.
  
== Distinct directory common kernel path ==
+
Each architecture should be configured to utilize a respective configuration file that includes a [[Directives/path|PATH]] statement to an {{nowrap|architecture-specific}} directory for c32 modules.
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 ==
+
== Distinct directory ==
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/".
+
 
 +
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 {{nowrap|"bios/pxelinux.0"}},
 +
EFI32 clients will load {{nowrap|"efi32/syslinux.efi"}} and
 +
EFI64 clients will load {{nowrap|"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,
 +
* "<nowiki>http://192.0.2.3/boot/vmlinuz</nowiki>" - using a system capable of HTTP transfer, provided by:
 +
** pxelinux.0 atop gPXE/iPXE with HTTP support; or,
 +
** lpxelinux.0; and/or,
 +
** syslinux.efi.
 +
 
 +
Try to avoid using {{nowrap|"<tt>../</tt>"}} 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).
 +
 
 +
=== Distinct directory symlink path ===
 +
 
 +
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: <br/>
 +
 
 +
When the {{nowrap|"''boot/vmlinuz''"}} kernel file exists,  
 +
creating a symlink at {{nowrap|"''bios/boot/''"}}
 +
targeting {{nowrap|"''../boot''"}} or {{nowrap|"''/tftproot/boot''"}}
 +
would allow the {{nowrap|"''boot/vmlinuz''"}} reference
 +
to be resolved to the {{nowrap|"''/tftproot/boot/vmlinuz''"}} file
 +
by the underlying system whose current directory is {{nowrap|"''/tftproot/bios/''"}}.
  
 
Some tftpds may also provide for a virtual path option that would work in a similar fashion.
 
Some tftpds may also provide for a virtual path option that would work in a similar fashion.
  
== Distinct directory symlink file ==
+
=== 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"
+
 
 +
When the {{nowrap|"''/tftproot/boot/vmlinuz''"}} file exists,  
 +
creating a "''vmlinuz''" symlink
 +
in the {{nowrap|"''/tftproot/bios/boot/''"}} directory
 +
targeting "''../../boot/vmlinuz''"  
 +
would be resolved to the {{nowrap|"''/tftproot/boot/vmlinuz''"}} file.

Revision as of 18:24, 12 December 2014

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.

Distinct directory

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,
    • syslinux.efi.

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).

Distinct directory symlink path

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.

Distinct directory symlink file

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.