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

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?

On Mon, Jun 16, 2014 at 5:57 PM, Alexander Perlis <aperlis at
math.lsu.edu> wrote:
> 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/
?
Either manual prefixing or by using option 210 (either in your DHCP
config or via pxechn.c32 with -p like you already did below).
> (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
Just to be clear, I'd recommend extracting from the binary/source
archive, not running make and just copying files as needed.

This sounds like you're using gpxelinux.0 4.07 which as I stated will
introduce issues.  Instead of using gpxelinux.0 4.07, try pxelinux.0
4.07 then do your chainload to lpxelinux.0 6.02.  If this doesn't
solve it, try 6.03-pre14.

> 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?
Errors along this line are part of what's resolved in recent versions.
That bug is likely just preventing you from hitting the section of
code leading to your hang.

-- 
-Gene

On 06/16/2014 02:57 PM, Alexander Perlis wrote:
> 
> 
> 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.)
There is a way to hard-code options into the pxelinux.0 file itself
using the "pxelinux-options" program.  Now when I think about it, that
might actually be broken (and needs to be fixed.)
> Here's what I mean by 'chainloading to install an automatic http
prefix':
The other option is to use a very small default configuration file
containing only:

default reload
label reload
   config http://...path to real config file .../  http://...new path
prefix.../

	-hpa

On 06/16/2014 05:12 PM, H. Peter Anvin wrote:
> 
> There is a way to hard-code options into the pxelinux.0 file itself
> using the "pxelinux-options" program.  Now when I think about it,
that
> might actually be broken (and needs to be fixed.)
> 
And I just fixed it, for BIOS at least (EFI will require more work; the
embedding format needs to change to support the EFI PECOFF file format.)

The fix is pushed out in Syslinux 6.03-pre15.

	-hpa

On 06/16/2014 05:14 PM, Gene Cumm wrote:
> This sounds like you're using gpxelinux.0 4.07 which as I stated will
> introduce issues.  Instead of using gpxelinux.0 4.07, try pxelinux.0
> 4.07 then do your chainload to lpxelinux.0 6.02.  If this doesn't
> solve it, try 6.03-pre14.
When I DHCP boot to lpxelinux.0 6.02, and then pxechn.c32 back to 
lpxelinux.0 6.02 with the http prefix, I get the graphical menu but then 
the host hangs.

Switching everything over to 6.03-pre17, at all stages, and 
pxechn.c32-loading over to lpxelinux.0, the host no longer hangs at the 
graphical menu. Yay!

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.

(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.)

(3) pxechn documentation on prefix option: I tried DHCP booting to 
lpxelinux.0 and then pxechn to pxelinux.0, and of course left off the 
'-p http://my.ip/', but pxelinux.0 failed because it seems to have 
picked up an implied '-p syslinux/'. My logs show it tries to load 
'syslinux/nextstage.cfg' and 'syslinux/syslinux/vesamenu.c32'
and so on.
I have to explicitly specify '-p /' to avoid that defaulted prefix. 
Perhaps the http://www.syslinux.org/wiki/index.php/Pxechn.c32 
documentation could mention default values when parameters aren't given, 
how they are computed, with some examples?

(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?

09:35:45  tftpd: RRQ filename lpxelinux.0
09:35:45  tftpd: tftp: client does not accept options
09:35:45  tftpd: RRQ filename lpxelinux.0
09:35:45  tftpd: RRQ filename ldlinux.c32
09:35:45  tftpd: RRQ filename pxelinux.cfg/44454c...
09:35:45  tftpd: RRQ filename libcom32.c32
09:35:45 webfsd: "GET /syslinux/pxechn.c32 HTTP/1.0"
09:35:45  tftpd: RRQ filename libutil.c32
09:35:45 webfsd: "GET /syslinux/lpxelinux.0 HTTP/1.0"
09:35:48 webfsd: "GET /ldlinux.c32 HTTP/1.0"
09:35:52 webfsd: "GET /nextstage.cfg HTTP/1.0"
09:35:52 webfsd: "GET /syslinux/vesamenu.c32 HTTP/1.0"
09:35:52 webfsd: "GET /libcom32.c32 HTTP/1.0"
09:35:52 webfsd: "GET /libutil.c32 HTTP/1.0"
09:35:52 webfsd: "GET /graphics.cfg HTTP/1.0"
09:35:52 webfsd: "GET /main.cfg HTTP/1.0"
09:35:52 webfsd: "GET /delldiag/delldiag.cfg HTTP/1.0"
09:35:52 webfsd: "GET /windows/windows.cfg HTTP/1.0"
09:35:52 webfsd: "GET /bios/bios.cfg HTTP/1.0"
09:35:52 webfsd: "GET /dban/dban.cfg HTTP/1.0"
09:35:52 webfsd: "GET /linux/linux.cfg HTTP/1.0"
09:35:52 webfsd: "GET /linux/debian-live.cfg HTTP/1.0"
09:35:52 webfsd: "GET /linux/debian-iso-install.cfg HTTP/1.0"
09:35:52 webfsd: "GET /linux/ubuntu-desktop-live.cfg HTTP/1.0"
09:35:52 webfsd: "GET /linux/kubuntu-tde-live.cfg HTTP/1.0"
09:35:52 webfsd: "GET /linux/linuxmint.cfg HTTP/1.0"
09:35:52 webfsd: "GET /linux/fedora.cfg HTTP/1.0"
09:35:52 webfsd: "GET /lsumath/lsumath.cfg HTTP/1.0"
09:35:52 webfsd: "GET /lsumath_graphics.png HTTP/1.0"

On 06/16/2014 07:12 PM, H. Peter Anvin wrote:
> On 06/16/2014 02:57 PM, Alexander Perlis wrote:
>> Here's what I mean by 'chainloading to install an automatic
http prefix':
>
> The other option is to use a very small default configuration file
> containing only:
>
> default reload
> label reload
>     config http://...path to real config file .../  http://...new path
> prefix.../
This works great! I'm now DHCP-invoking lpxelinux.0 and then using this 
CONFIG approach to change the global prefix to "http://my.ip/".

This is more efficient than using pxechn.c32, if the only goal is to 
reload the same NBP on the same server but simply with a different 
global prefix.

Also glad to have learned about pxechn.c32 for when we need to switch to 
a *different* NBP (e.g., a different version of syslinux).