Syslinux - Feb 2014 - [RFC, PATCH] core/pxe: Add architecture-specific discovery request for PXE config file

In other words, the dhcp server has to start the client on the correct binary
for it's arch and by virtue of running different bins, we can determine the
most appropriate config file for the client?



On Monday, February 24, 2014 9:13 AM, Gene Cumm <gene.cumm at gmail.com>
wrote:
 
On Mon, Feb 24, 2014 at 3:14 AM, Jeremy Kerr <jk at ozlabs.org> wrote:
> When serving PXE config files to machines of different architectures
> (requiring separate boot images and config files), this means we
> cannot use the autodisovery mechanism without having prior knowledge of
> a MAC/IP/uuid-to-architecture mapping.
Actually, you can.? COM32 modules are not usable across architectures.
I'd suggest separating them to different directories.? I don't think
I've documented this alternate strategy yet but the overview is to
place each in differing directories then determine a strategy for
shared content (if any).? If symlinks are allowed on the tftpd system
(ie a Linux box with ext3), this would probably be the easiest
strategy as you otherwise need to develop a strategy for specifying
URL-like file locations.? Generally ".." in a URL is a bad idea.

Quick example:

Return a boot file name of "pxelinux.0" or "bios/pxelinux.0"
for BIOS
clients, "efi32/bootia32.efi" for EFI x86 and
"efi64/bootx64.efi" for
EFI x86-64.

-- 
-Gene

_______________________________________________
Syslinux mailing list
Submissions to Syslinux at zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

On 02/24/2014 09:30 AM, Don Cupp wrote:
> In other words, the dhcp server has to start the client on the
> correct binary for it's arch and by virtue of running different bins,
> we can determine the most appropriate config file for the client?
That is definitely one way to deal with it.

There is no way around the fact that you have to have different binaries
for different architectures; there is nothing that Syslinux can do about
that, and it has to be dealt with before Syslinux is even running.

Now, with lpxelinux.0 you can also enable HTTP cookies which contain a
*lot* of system information that you can use dynamically on your HTTP
server via PHP or whatever you want.

	-hpa

Hi all,
>> In other words, the dhcp server has to start the client on the
>> correct binary for it's arch and by virtue of running different
bins,
>> we can determine the most appropriate config file for the client?
> 
> That is definitely one way to deal with it.
> 
> There is no way around the fact that you have to have different binaries
> for different architectures; there is nothing that Syslinux can do about
> that, and it has to be dealt with before Syslinux is even running.
Yep, definitely.

As Gene has mentioned, we could indeed do this in pxelinux through
serving different binary images, but this means we need a different
method for different pxe loader implementations, and this won't work
when the loader binary is already present on the machine.

What I'm looking to do here is establish a bit of a convention for
allowing machines of multiple architectures to be perform PXE
configuration in a uniform way (in this case, without requiring the DHCP
server to send out different lease parameters in response to the
client's DHCP architecture ID).

For this to be useful, my aim is that different pxe loader
implementations to follow the arch-xxxx convention too; I'm proposing a
similar change in petitboot:

 http://git.ozlabs.org/?p=petitboot;a=commitdiff;h=3bc86f99

I have a patch in development for u-boot too.

In the petitboot & u-boot cases, the pxe loader code is already present
on the machine, so we don't have the "which loader binary to
serve"
issue, only the "which config to use" one.
> Now, with lpxelinux.0 you can also enable HTTP cookies which contain a
> *lot* of system information that you can use dynamically on your HTTP
> server via PHP or whatever you want.
That sounds great. I'd like to do the same in petitboot, and it'd be
good to use the same format there. However, I do still need to support
TFTP discovery too.

Cheers,


Jeremy