> Rick Miller wrote: > > This is not OpenSolaris specific, but relates to > Solaris 10 10/09 JumpStart over the network. We are > not using a traditional environment. We are > installing Solaris from a Linux OS. The end result > is that the client's are installed via the JumpStart > mechanism. However, the PXE modules and boot loaders > are written in-house > > > I'm curious why you needed to write anything > 'in-house'? Just because > the pxegrub, included on the Solaris CD was written > by sun, doesn't mean > it requires a Solaris machine to serve it.
We don't need to write anything in-house :) I know that, you know that and others know that. Unfortunately, many of those involved, directly and indirectly, have had little say in the development and deployment of this provisioning application. Despite everyone's misgivings with regards to the application, it's in it's final stages of deployment after having been in development for 2+ years. If I had had my druthers, something far less complex would have been developed and deployed, but alas, no such luck. > It's true that running 'setup-install-server' might > be tough on a Linux > server, but this is what I have done: > > 1. Mounted the Solaris 10 DVD iso on the Linux > machine, and shared it > via NFS > 2. Loop-back mounted the bootin sub dir (I don't have > the exact path in > front of me right now.) - the one with the kernel, > miniroot, and pxegrub > in it. > 3. Create the pxegrub menu.lst file to find the root > NFS fs, install dvd > NFS share, custom jumpstart area, sysidcfg file if > needed. > 4. Configure DHCP to assign an address to the > clients, and respond with > the GRUB site DHCP option set to the path to the > menu.lst for this client. Our application does a large portion of this as well. There is a web based front end ( and a command line API ) to the application, which writes the sysidcfg, $SI_PROFILE, start/finish scripts, configures the DHCP server and all. The process for this application currently is intended that the end-user will boot the system via PXE and it will download and execute custom boot loader that gathers various specs about the chassis and directs the end-user to a web application where they then configure the OS, software, and various other items. When the end-user clicks a button in their web interface, the application writes out all necessary files (sysidcfg, $SI_PROFILE), configures DHCP, copies any necessary miniroots into /tftpboot, etc. The act of clicking this button also sends a packet to the client with it's boot command (which I think it loosely based on Syslinux...I think) which then loads the Solaris kernel and from there the Solaris environment/miniroot where the install proceeds as if it were JumpStarted in a normal fashion. It has worked before (and numerous times), but I am at a loss as to why it is failing now other than the symptoms I described earlier. I'm pretty sure I am on the right track and thought process, just unsure where to actually go from here. > > This is from memory, so there might be one or two > small things I missed, > but the point is you can (if you want to) server all > the binaries that a > Solaris server would serve from a Linux server. > > If you prefer, I beleive you might even be able to > subsitute pxelinux > for pxegrub, but I've never seen a reason to. > > I actually Net-boot and install all flavors of Linux > using the Sun > Solaris supplied pxegrub, and ignore pxelinux > altogether. > > If this sounds like it will help you out. I can get > you more info. > > -Kyle > We have found recently that when we attempt to boot > and install the Solaris 10 x86 OS onto a client, that > the client exits install-discovery citing the > inability to configure the interfaces. Through > poking around, I have found that bootmac, hostip, > netmask, and def_route are not set in the /devices > tree and this is why install-discovery quits. > > > > If I run /sbin/netstrategy, it returns "ufs none > none" after install-discovery has errored out. > Executing the same from a working environment after > ctrl-C'ing install-discovery returns "ufs $int dhcp" > (where $int is the primary interface in the > chassis). > > > In analysing packet captures in a working and > non-working environment, we have found that in the > working environment, the observed behavior is 2 DHCP > discovers (one from PXE; the second from Solaris when > loading the Solaris environment) while in our > non-working environment we observe only the first > DHCP discover from PXE. > > > > I am trying to identify at what point our failure > is occurring, but am unsure how the variables > identified above are populated in the /devices tree. > I am hoping that someone here might be able to guide > me in the right direction to identify the point and > cause of failure. > > _____________________________________________ > install-discuss mailing list > install-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/install-d > iscuss -- This message posted from opensolaris.org
