Syslinux - Dec 2014 - Using of pxelinux configfiles for both BIOS and UEFI boot

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

> Maybe the mentioned debate can be reopened since multi boot
> architecture are more common today? 
> 
 
Please, let's _not_ reopen this debate, yet again.

Every time someone tries network booting with mixed architectures / 
firmwares with Syslinux for the first time, we get to this discussion 
of using different filename extensions. Let's not waste time again.

There are at least 2 basic reasons to keep the same ".c32":

_ prior configuration files are re-usable, as-is, for whichever 
architecture supported by Syslinux;

_ in-common configuration files are used as-is.

To be clear, I am providing these 2 reasons for general information 
only, and this should not be interpreted as an open door for additional 
debate from my part. Of course, anyone is free to re-debate this until 
feeling nauseous, and my opinion is as valid as anyone's. I am just 
pointing out, as clear as I can, that this matter was discussed many 
times already, and the resolution has been implemented since version 
6.00(-pre).

FWIW, the ldlinux.{c32,e32,e64} modules _can_ be used in the same 
directory if so desired, together with {l,}pxelinux.0, bootx64.efi and 
bootia32.efi. So all this matter is only relevant when using additional 
modules.

Using dhcp options 209 and 210 should allow for 3 different initial 
configuration files, according to the architecture / firmware of the 
client.

Together with those 2 dhcp options, the (optional) usage of Syslinux 
directives such as:
PATH
INCLUDE
CONFIG

and the cmd.c32 module, there is enough flexibility for different types 
of users / cases.

If there is some case that is not covered, perhaps that's a matter of 
(lack of) documentation, and someone with experience might be able to 
provide / suggest / analyze specific alternatives. Let's focus on such 
particular case / situation.

Regards,
Ady.

On Mon, Dec 8, 2014 at 10:44 AM, Leenders, Peter
<Peter.Leenders at computacenter.com> wrote:
> 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.
No need. Again, you have choices.

http://www.syslinux.org/wiki/index.php/PXELINUX#Hardcoded_options

-- 
-Gene

> On Mon, Dec 8, 2014 at 10:44 AM, Leenders, Peter
> <Peter.Leenders at computacenter.com> wrote:
> 
> > 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.
> 
> No need. Again, you have choices.
> 
> http://www.syslinux.org/wiki/index.php/PXELINUX#Hardcoded_options
> 
> -- 
> -Gene
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
A couple of comments that might be relevant:

_ You mentioned you "have 2 different boot files in 2 different 
locations". You should be able to use 2 different boot files with 2 
respective configuration files, all in one-and-the-same root location. 
In other words: dhcp option 209 (pxelinux.configfile) would point to 2 
different config files, while option 210 (pxelinux.pathprefix) _can_ be 
the same for both types of firmware.

_ pxelinux-options was broken since 4.00, so you need version 6.03 (or 
newer).

Regards,
Ady.

> On Mon, Dec 8, 2014 at 10:44 AM, Leenders, Peter
> <Peter.Leenders at computacenter.com> wrote:
> 
> > 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.
> 
> No need. Again, you have choices.
> 
> http://www.syslinux.org/wiki/index.php/PXELINUX#Hardcoded_options
> 
> -- 
> -Gene
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
I could be wrong about this, but... I think that it could still be 
possible to get multiple architectures / firmwares mixed together while 
using c32 modules, without dhcp options, and perhaps even without 
applying pxelinux-options.

If I understood correctly, this tftp server can choose between 2 boot 
files, depending on BIOS/UEFI client, and the problem is choosing a 
different config file.

According to prior pcap reports, syslinux.efi searches for syslinux.cfg 
(too), while (l)pxelinux.0 will be searching for "default". This means
that using something *similar* to:

 pxelinux.cfg/default:
  PATH bios
  CONFIG common-config.cfg ::bios
  # the bios modules should be located in the bios subdir

and
 pxelinux.cfg/syslinux.cfg
  PATH efi64
  CONFIG common-config.cfg ::efi64
  # the efi64 modules should be located in the efi64 subdir

could / perhaps / might / work. It would also depend on how the path 
notation is expressed in "common-config.cfg", considering that the 
CONFIG directive is changing the working directory.

This might very well fail too, but perhaps this idea triggers some 
additional feedback from someone else.

Regards,
Ady.