Syslinux - Aug 2008 - Recursive pxelinux.0 and pxelinux.cfg directories.

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

 

Below is what I am shooting for

 

Maybe something like 

 

kernel  RHEL-Install/pxelinux.0 -cfg_dir RHEL-Install/pxelinux.cfg

 

/tftpboot/pxelinux.0

/tftpboot/pxelinux.cfg/default

/tftpboot/menu.msg-------------------? /tftpboot/RHEL-Install/pxelinux.0

--------------------------------------------?
/tftpboot/RHEL-Install/pxelinux.cfg/default

Vance Turner wrote:
> 
> Is there a way to call pxelinux.0 and point it at a different pxelinux.cfg
directory?
> 
Not directly.  It's on the to do list but it's not supported yet.

	-hpa

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>

On Mon, 18 Aug 2008, Vance Turner wrote:
> Is there a way to call pxelinux.0 and point it at a different pxelinux.cfg
directory?
Hello Vance,

If I understand you correctly, this might be of interest. I wanted to setup 
different pxelinux.cfg/default files since I wanted the default for one 
set of machines to be different from another set so I could use the 
"timeout" option and a "default" boot option in order to
perform
operatorless installs.

I used the "pxelinux.pathprefix" and dhcp "option space"
options.
http://syslinux.zytor.com/wiki/index.php/PXELINUX#Can_I_send_information_to_PXELINUX_via_special_options_in_the_DHCP_response.3F

eg: snippets of dhcpd.conf
# systemimager imageserver option-140 -> option 8c in hex
# systemimager log_server_port option-141 -> option 8d in hex
# pxelinux magic option-208 -> option d0 in hex
# pxelinux pathprefix option-210 -> option d2 in hex
option space foo;
option foo.imageserver      code 140 = text;
option foo.log_server_port code 141 = string;
option foo.magic      code 208 = string;
option foo.pathprefix code 210 = text;

# define all the options to what we want for foo machines
option foo.imageserver "10.32.1.3";
option foo.magic f1:00:74:7e;
option foo.pathprefix "foo-dir/";

site-option-space "foo";
if exists dhcp-parameter-request-list {
    # Always send the foo options (specified in hexadecimal)
    option dhcp-parameter-request-list = concat(option
dhcp-parameter-request-list,8c,8d,d0,d2);
}

So the option foo.pathprefix "foo-dir/"; is the important one. Now
when
these foo group of machines booted they would check for 
"/tftpboot/foo-dir/pxelinux.cfg/default"

The machines not defined in the "foo option space" would just check
the
normal location "/tftpboot/pxelinux.cfg/default"

Hope this helps.
-k

What I am setting up is an automatic install environment at Datadomain.
So that the X86 class machines will be loaded unattended from any number
of OS types or revisions. I will have all of the systems enabled with
LOM (Lights Out Management ) capabilities. For now I am going to use
network booting, but ultimately I will set up a Solaris system with a
directory structure and be able to link the directory structure to iSCSI
targets. This way I can take the systems down via LOM, have the master
system reset the iSCSI target to the proper OS, Applications, and
Patches, then reboot the system for the automated test to be run. I want
to cut my current 45min period between OS loads down to 5 at the max.

I also want to hand off the network boot server to corporate to handle
interactive and non-interactive loads of all supported OS
configurations.

I can do this with one convoluted /tftpboot directory, but I would like
to have a uniform entry point to pick the OS type, then go to a menu of
releases for that type, then had it of to the default menus and splash
screens the vendors provide.

I am willing to publish this to the net later as an example.

--On Monday, August 18, 2008 07:11:43 PM -0700 Vance Turner 
<Vance.Turner at datadomain.com> 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.
This is exactly what pxechain.asm was written for:


<http://syslinux.zytor.com/archives/2008-April/009795.html>

-- Jeff

Jeffrey Hutzelman wrote:
> 
> This is exactly what pxechain.asm was written for:
> 
> <http://syslinux.zytor.com/archives/2008-April/009795.html>
> 
Indeed, thanks for the reminder.  I should really pull this into the 
standard sources.

	-hpa