[syslinux] Using of pxelinux configfiles for both BIOS and UEFI boot

[Leenders, Peter]

Hello Gene,

thank you for your answer


> > - Is there a standard approach to use different vesamenu.c32 (and other architecture depending ) files in the pxelinux.cfg/default file depending on the boot architecture - especially for BIOS/Legacy and EFI64?

>  I'd say there's no standard but there are choices.  Check out this page I wrote up.

> http://www.syslinux.org/wiki/index.php/PXELINUX-Multi-Arch

>> > - Is it e.g. possible to set and use variables depending on the boot architecture in the default menu  pxelinux.cfg/default to address different vesamenu.c32 files?

> Not quite.  INCLUDE and PATH with a different initial config per architecture (which I apparently didn't finish).  Ensure each architecture gets a different initial config file that's two lines:

>  PATH bios
>  INCLUDE common-config

>  PATH efi32
>  INCLUDE common-config

>  PATH efi64
>  INCLUDE common-config
This look promising, if I could separate the config files for the different boot architectures Bios and UEFI. I have 2 different boot files in 2 different locations, but after startup they both  refer to the tftproot/pxlinux.cfg/default config file. The DHCP Option 209 may solve this if the ZENworks tftp server support this option with different values depending on the architecture. Unfortuanelly til now I didn’t found out if there is a support for this option.


> > For belonging ldlinux module the extensions (*.c32, *.e32 and *.e64) allows to use UEFI and BIOS parallel. Unfortunately this concept is not working for the other modules like vesamenu and depending modules. Is there a plan to extent this concept to the other modules?

>I believe that there was debate and the decision was common name extension.
Meanwhile I found a workaround for my problem by using different extensions depending on the architecture by patching the binaries. Since using different com32 module in multi arch environments is problematic not only in my environment – I think loud: Can this be an approach to handle this problems in a simple an clearly laid out way. It would be simple to handle multi-arch com32 files on a simple tftp server without using not always supported dhcp options or complicated config files? It’s just a renaming of binaries and of the dependencies in the source code and 1 extension for each boot architecture. E.g. *.c32 for bios and *.e64 for UEFI.

Maybe the mentioned debate can be reopened since multi boot architecture are more common today?

Peter