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

[Jeffrey Hutzelman]

On Tue, 2011-06-07 at 18:04 -0700, Mike Sollanych wrote:
> Hello SYSLINUX folks, thanks for all your hard work over the years!
> 
> I'm working on a fairly complex deployment services project, and one of the 
> aspects of it is to make it possible to federate deployment services across
> our university. Supporting existing deployment services is a priority, so
> I am presently trying to integrate an existing PXELINUX install, part of a 
> FOG windows imaging service, with a larger iPXE / SYSLINUX setup.
> 
> The boot order is as follows:
> F12 network boot -> local PXE -> iPXE from master server -> Syslinux VESA menu.
> 
> iPXE is in the chain first because we have some custom scripting that runs that
> could result in a machine not booting to SYSLINUX, but that functionality is all
> working well at the moment.
> 
> Once we hit Syslinux, one of the submenus covers a department's existing FOG
> server. FOG uses PXELINUX itself, and provides a number of static boot lines 
> in its own pxelinux.cfg/default file. Those lines were simply integrated into 
> our new master Syslinux setup. 
> However, FOG assigns a "task" to a machine by creating a MAC-address specific 
> config file in its TFTP pxelinux.cfg directory, so that when the machine boots, 
> it runs a specific kernel with a complex APPEND string of options (including the 
> image file to use and more). Without this APPEND line, FOG is broken.
> 
> Within the framework of this federated deployment project, after much head
> scratching, the next easiest method for me to use was to create a shim of 
> sorts, written in PHP and executing on the FOG server.
> 
> When provided with the MAC address of a machine as a GET parameter, it 
> searches for a pxelinux.cfg file specific to that MAC, and outputs an iPXE 
> script that causes iPXE to start FOG the same way with the same parameters.

Why not skip all this complexity, and simply use PXECHAIN.COM to
chain-boot a new copy of PXELINUX from the FOG server?  Then it can
manage the TFTP directory however it wants, provide whatever PXELINUX it
wants to run, associated com32 modules, etc., and the rest of your
system doesn't need to know anything about it.



This approach also has the advantage that PXECHAIN can pass control to
_any_ PXE NBP, not just PXELINUX, so you can hand off to pretty much
anything that thinks it ought to be running or installed on a PXE
server.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA