[syslinux] Chainload pxelinux from pxelinux and pass parameters or change root dir?

[H. Peter Anvin]

On 06/17/2014 09:36 AM, Alexander Perlis wrote:
> 
> Some observations:
> 
> (1) bug in gpxelinux 6.03-pre17 unrelated to pxechn: When I DHCP boot
> directly to gpxelinux.0 it snags on 'KERNEL
> http://my.ip/syslinux/pxechn.c32' with the error "Failed to load COM32
> file http://my.ip/syslinux/pxechn.c32", but my transfer logs show no
> transfer attempt! If I change that line to just 'KERNEL
> syslinux/pxechn.c32' then it works.
> 

Interesting, that might be fixable.

> (2) another bug in gpxelinux 6.03-pre17 possibly related to pxechn: When
> I DHCP boot to lpxelinux.0 and then pxechn to gpxelinux.0, with '-p
> http://my.ip/' and '-c nextstage.cfg', gpxelinux.0 seems to ignore the
> '-c' option and just tries to load pxelinux.cfg (I see this in my
> transfer logs). Furthermore, it does this with TFTP and not HTTP, so
> seems to also ignore the '-p' option. (And then, because it loaded my
> pxelinux.cfg, it finally hits the other bug reported in the prior
> paragraph.)

The layering of gPXE (which is so outdated, we really need to drop it)
in there is really messy.  I'm strongly feeling we should just drop
gpxelinux post 6.03 and let people who want to use iPXE do the wrapping
themselves.  Early on we had to make patches to gPXE, but that is
historic at this point.

> (4) lpxelinux-to-lpxelinux delays: When I DHCP boot to lpxelinux.0 and
> then pxechn back to lpxelinux.0, I observe delays. Refer to the logs
> below. The initial DHCP-induced TFTP transfer of lpxelinux.0 and
> associated libraries followed by HTTP transfer of pxechn.c32 (which
> pulls in libutil.c32 over TFTP) and then pxechn's HTTP loading of
> another copy of lpxelinux.0 all happens within the first second. But
> then there is a 3-second delay (!), after which the second copy of
> lpxelinux.0 seems to be the one who does an HTTP transfer of
> ldlinux.c32, but then there is another 4-second delay (!) before
> everything else is pulled down and our graphical menu appears, all
> within that final second. Note that the initial DHCP-induced run of
> lpxelinux.0 has no delays, nor does pxelinux.0-to-lpxelinux.0
> chainloading introduce delays. Only lpxelinux.0-to-lpxelinux.0
> chainloading seems to introduce those delays on the second invocation of
> lpxelinux.0. Furthermore, when I try this repeatedly, the delays are
> inconsistent. I've seen repeated 3-second delays between each pair of
> multiple successive HTTP requests, yet seen other boots with essentially
> no delay. Perhaps this is a problem with my HTTP server, or a network
> problem, yet I can only reproduce it when I do
> lpxelinux.0-to-lpxelinux.0. Any ideas?

One of the tricky bits with lpxelinux.0 is that it wants to talk to the
UNDI (driver) layer, while keeping the BC (the ROM UDP/IP stack) alive
for the purpose of chainloading.  It is possible that your particular
PXE ROM gets messed up by this process.

	-hpa