[syslinux] Chainloading from one PXELINUX to another (with some iPXE in the mix)?

[Jeffrey Hutzelman]

On Wed, 2011-06-08 at 14:55 -0700, Mike Sollanych wrote:
> 
> ----- Original Message -----
> > From: "Jeffrey Hutzelman" <jhutz at cmu.edu>
> > To: "For discussion of Syslinux and tftp-hpa" <syslinux at zytor.com>
> > Cc: jhutz at cmu.edu
> > Sent: Wednesday, June 8, 2011 2:04:03 PM
> > Subject: Re: [syslinux] Chainloading from one PXELINUX to another (with some iPXE in the mix)?
> >
> > I admit there's not a whole lot of documentation, but there's also
> > not really much to document.
> 
> Fair enough, I guess it either works for what you want or it doesnt! :-)
>  
> > > "pxechain.com [FOG SERVER FQDN]::pxelinux.0"
> > 
> > Yup, that's what should happen.  Assuming, of course, that you don't
> > actually have brackets in your config file.
> 
> Yep, didn't think it was necessary to give out my server name.
> 
> > PXECHAIN should do that for you; in fact, that's its main purpose.
> > It works by updating the PXE stack's cached DHCP reply, which works
> > with the Intel reference stack and with every PXE stack I've seen on real
> > hardware, but might _not_ work with software stacks like gpxe/ipxe.
> 
> Can you elaborate on this? From what I can tell, the pxelinux.0 loaded from
> the FOG server is executing, but then it's trying to get its config file via
> TFTP from the original master server. 
> 
> If I understand you correctly, you're saying that the PXECHAIN.COM module
> edits the name of the TFTP server in memory, loads the provided file via
> TFTP, and then runs it; and that the newly running file (the FOG pxelinux, 
> in my case) should use the now-edited TFTP server name to fetch its config.
> 
> If that's the case, and it should be loading configs from the FOG server,
> then that's not working here.

It's a little more complicated.
The response from the DHCP server doesn't contain a TFTP server _name_;
it contains the _address_ of the server to use.  PXECHAIN does the
following:

- Parse the server::path you gave it
- Look up the server's address, if you gave a name
- Ask the PXE stack for the cached DHCP response
- Rewrite the next-server and bootfile fields in that response with
  the new server address and filename
- Fetch the file you named and boot it (actually, we ask PXE to do this)

That last step does _not_ use the cached DHCP response -- it uses the
values you provided, passed in separately to the PXE "Restart TFTP"
call.  However, the next NBP (in this case, another PXELINUX) _does_ use
the cached response to find out where to look for its config file.

In the Intel reference PXE stack and many others, the "Get Cached DHCP
Response" call returns a pointer to the actual buffer in which the
received BOOTP/DHCP packet was stored, and returns the _same_ pointer
every time.  So simply overwriting parts of that buffer works fine.

Other stacks (IIRC, gpxe has this problem) return a pointer to a _copy_,
so changing it has no effect.

> > We've had it work on pretty much every PXE-capable box we've seen in
> > the last few years.  But, again, without first loading an alternate PXE
> > stack.
> 
> I guess iPXE could be getting in the way, but it's a requirement of our 
> setup here to have iPXE first - there are other things it can load up instead
> of SYSLINUX depending on the configuration in a specific department.

Yup.  If I were doing this I'd be loading PXELINUX first, using that to
do the first-level selection, and then loading something else if needed.
But your requirements may make that impossible, and in any case you have
existing infrastructure that works, and replacing it is not a task to be
undertaken lightly.


> Do you know who the maintainer is for that particular module? I wouldn't mind
> getting into contact with him/her to see if they'd be interested in adding
> the functionality I'm looking for. I can't see it being that complicated.
> 
> There does seem to be some work on a chain com32 that is more powerful:
> http://syslinux.zytor.com/archives/2010-November/015571.html
> 
> The author is Gene Cumm, who I'm CC'ing on this message in the hopes
> that he notices and lets me know where he's at with pxechn.c32.
> 
> I don't seem to have that in my distribution of PXELINUX, though I
> presently rely on someone else to build PXELINUX for me on the master 
> server as I don't have the rights to do it at the present time :-P

PXECHAIN is mine, though I haven't touched it in a while, and I believe
other people have contributed changes since it got merged into the
Syslinux repository.

I haven't heard anything from Gene on pxechn yet, but that's definitely
targeted to be the replacement for PXECHAIN and should end up working
more reliably with more PXE stacks.  I hope.

Processing of the CONFIG command is part of the syslinux core, so this
mailing list is as good a place as any to ask about it.  Or, for that
matter, to submit a patch, if you feel so inclined.

-- Jeff