[syslinux] Recursive pxelinux.0 and pxelinux.cfg directories.

Tobias Offermann to at hosteurope.de
Tue Aug 19 01:03:04 PDT 2008


Vance Turner wrote:
> I am trying to set a uniform PXE environment to load multiple distros. 
> 
> RHEL 5.1 and 4.7
> SUSE 10.2 and 11
> Solaris 10 X86
> Window Multiple server versions.... - Why? Because I am in hell.
> 
>  
> What I want is to have an upper level pxelinux.0 call the
> default menu directories that come with the releases.
> 
> Is there a way to call pxelinux.0 and point it at a
> different pxelinux.cfg directory?
> 
> Currently I can have pxelinux.0 call another pxelinux.0,
> but the second pxelinux.0 defaults to the default tftpserver
> root for pxelinux.cfg

I've got a similar problem here:

 - need to install different linux dists and windows
 - different teams maintain different dists on different servers
   (the shared-server approach simply... "failed")
 - we do not know previously which machine gets which os installed

My (hacky) solution was the following (a note: the solution is
running for one year now, before the gpxe/pxelinux integration
but now the networking install of windows is an added requirement
which does not yet work with the system described below):

  At first a generic pxelinux with a menu where you can chose the
os to install (or boot a rescue grml or an acronis netboot...) is
booted via pxe.
  Depending on the selection in the menu a gpxe is chainloaded.
There are some (magnitude of dists available) different gpxe binaries
which are all differently patched - they all send different
"vendor-class-identifier" when starting up a fresh pxe request.
  The DHCP server recognizes the different vendor-ids and - depending
on that - serves the "next-server" and "filename" that directs to
the appropriate server for that dist to install.
  The GPXE tries a "fresh" bootstrap and (nearly) transparently
boots pxelinuxes from the dist-servers where those teams can maintain
their own "dist-sub-menu".

This has just been an idea, but for all our linux installations this
is working perfectly! I know this is quite dirty, but a year ago I
saw no different choice.

Today with the merge of gpxe and pxelinux this seems a little bit
different as pxelinux can now load (sub)menus and kernels from
different servers.
but one question remains: in my hacky solution above the 'next-server'
is (finally, in the last step) set to the server actually providing
the installation kernel and loader. if i would do this with a
centralized menu which includes submenu from different servers, the
"next-server" would still be set to the "central" server - would it?
I think this is where the windows installation breaks, since there
is no way to tell the pxe windows installer where to draw the loader
from...

any ideas for a cleaner solution with the means of todays pxelinux?
(i hope i've described the situation, the solution and the problem
understandingly...)

greetings from cologne,
tobi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://www.zytor.com/pipermail/syslinux/attachments/20080819/6253d021/attachment.sig>


More information about the Syslinux mailing list