Syslinux - Jun 2014 - Chainload pxelinux from pxelinux and pass parameters or change root dir?

When chainloading one pxelinux from another (e.g., chainloading from say 
pxelinux 4.07 to pxelinux 6.02), can one pass parameters or somehow 
control the root directory and/or server IP address?

Here's the need: we have a loaded-up PXE server working great under 
4.07, and I'm not prepared to just switch the entire setup to a newer 
version of pxelinux, too many folks depending on a working setup. 
However, if I could chainload to 6.02, then I could have a menu entry 
that allows us to go to 6.02 for testing purposes, or to deploy a 
particular thing that actually requires 6.02. Thus I would like to have 
a menu entry under pxelinux 4.07 that says something like:

LABEL chainloadtopxe6
KERNEL /syslinux6/gpxelinux.0
APPEND root=/syslinux6

Note the APPEND. The idea is that the gpxelinux.0 would then in turn 
fetch its *.c32 and pxelinux.cfg from the /syslinux6 subtree, so that 
those files can be different than the versions from pxelinux4.

Is something like that possible? If not, how hard to add support for 
that? (That is, support for passing a parameter to a chainloaded 
pxelinux?) If totally impossible, is a possible workaround to dedicate 
another IP address, and do something like

LABEL chainloadtopxe6
KERNEL http://some.new.ip/gpxelinux.0

Will that invocation of gpxelinux.0 then set the environment 
appropriately to pull the *.c32 and pxelinux.cfg from that new IP address?


I suppose my real quandary is my lack of understanding of how pxelinux.0 
is executed: the DHCP server returns the IP and base image name, the 
ethernet card pulls down that image, so pxelinux.0 is just some binary 
code loaded into memory and executed, but how does that code then know 
the IP and path for pulling down additional components? That is, how 
does pxelinux.0 gain access to the DHCP parameters that tell it the root 
path and host IP address? Do those get passed dynamically on the stack, 
or are they stored ahead of time at some hardcoded fixed memory 
locations, or how does it work? And can those values later be changed on 
a reinvocation of pxelinux.0?

Thanks,
Alex

On Mon, Jun 16, 2014 at 10:23 AM, Alexander Perlis <aperlis at
math.lsu.edu> wrote:
> When chainloading one pxelinux from another (e.g., chainloading from say
> pxelinux 4.07 to pxelinux 6.02), can one pass parameters or somehow control
> the root directory and/or server IP address?
>
> Here's the need: we have a loaded-up PXE server working great under
4.07,
> and I'm not prepared to just switch the entire setup to a newer version
of
> pxelinux, too many folks depending on a working setup. However, if I could
> chainload to 6.02, then I could have a menu entry that allows us to go to
> 6.02 for testing purposes, or to deploy a particular thing that actually
> requires 6.02. Thus I would like to have a menu entry under pxelinux 4.07
> that says something like:
>
> LABEL chainloadtopxe6
> KERNEL /syslinux6/gpxelinux.0
> APPEND root=/syslinux6
The append is useless.  I'd also suggest the explicit KERNEL-like
directive PXE instead of KERNEL but alas it won't achieve your goals.
Chainloading to another PXELINUX in another directory won't adjust the
necessary data elements.
> Note the APPEND. The idea is that the gpxelinux.0 would then in turn fetch
> its *.c32 and pxelinux.cfg from the /syslinux6 subtree, so that those files
> can be different than the versions from pxelinux4.
>
> Is something like that possible? If not, how hard to add support for that?
> (That is, support for passing a parameter to a chainloaded pxelinux?) If
> totally impossible, is a possible workaround to dedicate another IP
address,
> and do something like
Yes/no.  You need a different approach.  This is why pxechain.com was
written and is now superseded by pxechn.c32 as a more flexible COM32
solution.  The traditional COMBOOT APIs have been removed in later
versions like 6.02.  Initially I wrote pxechn.c32 to allow further
modifications of the DHCP data due to requirements by certain Nettwork
Boot Programs (specifically Windows Server 2008R2 Windows Deployment
Services.
> LABEL chainloadtopxe6
> KERNEL http://some.new.ip/gpxelinux.0
>
> Will that invocation of gpxelinux.0 then set the environment appropriately
> to pull the *.c32 and pxelinux.cfg from that new IP address?
No.
> I suppose my real quandary is my lack of understanding of how pxelinux.0 is
> executed: the DHCP server returns the IP and base image name, the ethernet
> card pulls down that image, so pxelinux.0 is just some binary code loaded
> into memory and executed, but how does that code then know the IP and path
> for pulling down additional components? That is, how does pxelinux.0 gain
By finding the DHCP data that can be found by 4 PXE-specific methods.
> access to the DHCP parameters that tell it the root path and host IP
> address? Do those get passed dynamically on the stack, or are they stored
> ahead of time at some hardcoded fixed memory locations, or how does it
work?
> And can those values later be changed on a reinvocation of pxelinux.0?
See above.

-- 
-Gene

On 06/16/2014 10:41 AM, Gene Cumm wrote:
> [...]  Initially I wrote pxechn.c32 to allow further
> modifications of the DHCP data [...]
Awesome! In fact, this might allow us to install an automatic 'http' 
prefix on all subsequent requests, to avoid slow tftp --- or is that a 
bad idea, and/or is there a way to default all transfers to http without 
using pxechn and without prefixing every filename in the *.cfg files 
with http://my.ip/ ? (We don't control our DHCP server so can't easily 
experiment with the 210 option. Chainloading just to get that prefix 
installed is itself a slowdown, so I'd love to know a better way.) 
Here's what I mean by 'chainloading to install an automatic http
prefix':

pxelinux.cfg:
------------
DEFAULT switch-to-lpxe-with-http-default
TIMEOUT 0
LABEL switch-to-lpxe-with-http-default
KERNEL http://my.ip/syslinux/pxechn.c32 
http://my.ip/syslinux/lpxelinux.0 -p http://my.ip/ -c nextstage.cfg

nextstage.cfg:
-------------
Former contents of pxelinux.cfg


I tried this with 6.02. After some unexplained delays in the 
chainloading, my graphical menu does show up! Unfortunately, the host 
locks up at that point --- doesn't respond to keypress, nor is the 
countdown timeout changing values. Ctrl-Alt-Del doesn't work either. How 
can I debug that?

If I change lpxelinux.0 above to gpxelinux.0, then the boot doesn't even 
make it to the graphical menu. gpxelinux.0 seems to correctly load 
nextstage.cfg (from my -c option above) but then also tries to load 
pxelinux.cfg, which would be an infinite loop since that's the previous 
stage's configuration. Actually it doesn't get into an infinite loop, as
it only tries "syslinux/pxelinux.cfg" and a few other paths that
don't
work, and then exits with an error.

I also tried plain pxelinux.0 (no -p parameter), and it too behaves like 
gpxelinux.0 first loading nextstage.cfg but then going back and trying 
to load pxelinux.cfg and failing.

Only lpxelinux.0 seems to correctly honor the -c parameter from 
pxechn.c32. (But then, as reported above, my host hangs.)

I'm stuck. What am I doing wrong?

I also tried all of this under 5.10, but ran into the 'netconn_write 
failed' error, so I can't use version 5 at all. I wonder whether the 
patch in 6.02 that fixes that error could be backported to 5? Or am I 
wrong to assume that 5.10 is otherwise more stable than 6.02?