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

[Gene Cumm]

On Wed, Jun 8, 2011 at 17:55, Mike Sollanych <msollany at sfu.ca> 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.
>
>> 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.
>
>> > Seeing as how I've had luck with that CONFIG directive (config.c32)
>> > at loading the default file, it makes sense (to me anyway) that a
>> > modification of that module to support loading PXELINUX config files
>> > using the same precedence as the initial load would do the trick quite
>> > nicely.
>>
>> I don't believe there's currently a way to do that.  It's possible
>> there's something new, though; I haven't looked at recent code in a
>> while.
>>
>> -- Jeff
>
> 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

http://syslinux.zytor.com/archives/2011-May/016581.html

I'd still classify it more in the alpha phase but aside from asking
others for peer review and testing, I've got a small list of to-dos.
I've taken care of opt66/SNAME.  I still need to work on importing the
DHCP option packing.

The setting of arbitrary options I'm holding until last for several
reasons.  First, make sure everything else works first (so far for me,
yes).  Second, I'm still bouncing ideas around on formatting (but
definitely welcome feedback/ideas).  I'm thinking it should at least
understand character strings, IPv4 strings and hex byte strings
(probably something like hyphen or colon delimited or just
concatenated; concatenated would be quickest).

I also thought today of the idea of touching multiple packets to try
to help certain NBPs that ignore the third packet.

-- 
-Gene