Mike Gerdts wrote: > On Nov 28, 2007 10:47 AM, Kyle McDonald <KMcDonald at egenera.com> wrote: >> I haven't been able to get my x86 clients to pay any attention to these >> options though. Another poster on this list mentioned that he had this >> working late last yer/early this year but it broke when 'newboot' was >> integrated? >> >> Why is it broken. When booted to the miniroot dhcpinfo can look up all >> these options, so it's not that it's not available. >> >> Is this considered a bug? Is there an ID? >> >> Where would I look to fix it? Is /sbin/install-discovery the right place? > > I think that I am the other poster you refer to. I first raised this > issue when a discussion of the new installation strategy was pretty > young. Look where I talk about Page 11. > > http://mail.opensolaris.org/pipermail/install-discuss/2006-March/002459.html > > There was a little bit of follow-up saying that it was going to break > on SPARC too. I have a starting point for getting dhcp to work again, > but I am not sure that the instructions I gave there are complete. I > think there is a step missing, but I forget what it is. It is easier > to modify my jumpstart environment to generate the proper grub > configuration than it is to customize the root file system images from > time to time. > Yes I see the reply here: >>/ / >>/ Page 11 - DHCP, PXE, etc. In Update 1, vendor DHCP options for x86/ >>/ became unsupported in favor of maintaining those in menu.lst files. / >>/ Note that there was no EOF announcement to help customers prepare for/ >>/ this change and that all of the required functionality is still in the/ >>/ miniroot that is TFTP'd. Turning /sbin/dhcpinfo into a wrapper that/ >>/ does "if [ some_condition] ; then ifconfig bge0 dhcp primary ; fi ;/ >>/ exec /sbin/dhcpinfo.orig" brings this feature back. This change seems/ >>/ completely unnecessary and only serves to fragement x86 and SPARC/ >>/ jumpstart environments. Did I mention there was no EOF announcement/ >>/ and only one off-handed mention in the release notes?/ >>/ / > > I expect we'll fix the fragmentation between x86 and SPARC by going to > GRUB on SPARC as well. Long term, I think the model is better for most > people, but the transition could have been handled better, I agree. >
First, Mike mentions that there was no EOF announcement for this removal on x86?. Was there an ARC case? is it public? Second, I have to ask 'Why?' Why take this step backwards? Even if it is doable in the grub menu.lst file, why put it there if you don't have to? It doesn't really make sense there. It makes that file very unreadable and unwieldy. Why give up the more flexible and better design you've already put work into? Was there a technical reason that this had to be done? This change then requires a menu.lst file for every client you want install, unless you go and implement the Grub site option 150 (which isn't documented anywhere for Solaris) which is still a kludge, because it still requires a file for every version of Solaris I want to be able to install. This is the same problem that the sysidcfg files have! Information can't be shared between files. If something that is repeated in different files needs to be changed, I need to edit every file. Instead of editing a DHCP Macro that is included by all the macros that need it. I thought DHCP was an improvement over the old method because it pulled the configuration info from /etc/ethers, and /etc/bootparams into one location where I could manage it together. I thought it was so great I was going to suggest that everything from the sysidcfg file be moved to DHCP also for the same reasons: That everything is maintained on one place, and that common info can be shared and updated easily. U've very disheartened to learn that the opposite is true. As Mike mentioned in the post he linked to, a single pntadm command to add or update any client to the DHCP server, and I can specify in that command a macro that will specfy all the options needed for installing that client, though at least today that is only for SPARC. That would look like: pntadm -A GateKeeper -c "GateKeeper" -f "MANUAL" -h GateKeeper -i 01yyyyyyyyyyyy -m INST_Sol-sNV76-I86pc xx.xx.xx.0 Where the Macro INST_Sol-sNV76-I86pc would resolve to: :SrootIP=xx.xx.xx.xx:SrootNM="KeyMaster":Sterm="xterm":SbootRS=8192:SrootOpt="rsize=8192":SbootFIL="/platform/i86pc/kernel/unix":SinstIP=xx.xx.xx.xx:SinstNM="KeyMaster":SsysidCF="KeyMaster:/export/Install/Config/SysIDCfg/Default":SjumpsCF="KeyMaster:/export/Install":SrootPTH="/export/Solaris/sNV/b76_x/Solaris_11/Tools/Boot":SinstPTH="/export/Solaris/sNV/b76_x": The PXE Macro would already reference the Boot Server, and the BootFile of 'pxegrub' which would be a softlink to the latest pxegrub available. That's not exactly the way I hoped to use it, just the net effect. My plan used nested Macros and would have been like this: With these Macro's: HOST_GateKeeper = :Include=INST_Sol-sNV76-I86pc:JShostCF="Server": INST_Sol-sNV76-I86pc = :Include=INST_Sol-Common-I86pc:SrootPTH="/export/Solaris/sNV/b76_x/Solaris_11/Tools/Boot":SinstPTH="/export/Solaris/sNV/b76_x": INST_Sol-Common-I86pc = :Include=BOOT_Sol-Common-I86pc:Include=INST_Sol-Common: BOOT_Sol-Common-I86pc = :Include=BOOT_Sol-Common:SbootFIL="/platform/i86pc/kernel/unix": BOOT_Sol-Common = :SrootIP=xx.xx.xx.xx:SrootNM="KeyMaster":Sterm="xterm":SbootRS=8192:SrootOpt="rsize=8192": INST_Sol-Common = :SinstIP=xx.xx.xx.xx:SinstNM="KeyMaster":Include=INST_Sol-Common-SysID:Include=INST_Sol-Common-JumpS: INST_Sol-Common-SysID = :SsysidCF="KeyMaster:/export/Install/Config/SysIDCfg/Default": INST_Sol-Common-JumpS = :SjumpsCF="KeyMaster:/export/Install": When a client was configured to Install over the network I had planned to run: (Here 'JShostCF' is a Site option that my begin and Finish scripts would use when installing the machine.) dhtadm -A -m HOST_GateKeeper -d ':Include=INST_Sol-sNV76-I86pc:JShostCF="Server":' pntadm -A GateKeeper -c "GateKeeper" -f "MANUAL" -h GateKeeper -i 0100145E2BA6BD -m HOST_GateKeeper xx.xx.xx.0 which would give a final DHCP option list of: :SrootIP=xx.xx.xx.xx:SrootNM="KeyMaster":Sterm="xterm":SbootRS=8192:SrootOpt="rsize=8192":SbootFIL="/platform/i86pc/kernel/unix":SinstIP=xx.xx.xx.xx:SinstNM="KeyMaster":SsysidCF="KeyMaster:/export/Install/Config/SysIDCfg/Default":SjumpsCF="KeyMaster:/export/Install":SrootPTH="/export/Solaris/sNV/b76_x/Solaris_11/Tools/Boot":SinstPTH="/export/Solaris/sNV/b76_x":GRUBmenu="(nd)/menu.lst":JShostCF="Server": As you can see the Host has it's own macro ( I could have used the MAC address too) which specifies the Macro for the OS to install, and provides info to the Jumpstart scripts to customize that host. To change the OS or configuration and reinstall only the dhtadm command needs to be repeated. This is really convenient. If I could specify the 'network_interface', 'nfs4_domain', and 'security_policy' parameters of the sysidcfg here also, I'd have everything in one place and shared whenever possible. Independent of this, when adding new NV builds, or updates of S10, I only have to create one Macro for each: INST_Sol-sNV77-I86pc = :Include=INST_Sol-Common-I86pc:SrootPTH="/export/Solaris/sNV/b77_x/Solaris_11/Tools/Boot":SinstPTH="/export/Solaris/sNV/b77_x": INST_Sol-sNV78-I86pc = :Include=INST_Sol-Common-I86pc:SrootPTH="/export/Solaris/sNV/b78_x/Solaris_11/Tools/Boot":SinstPTH="/export/Solaris/sNV/b78_x": INST_Sol-s10u5-I86pc = :Include=INST_Sol-Common-I86pc:SrootPTH="/export/Solaris/s10/u5_x/Solaris_11/Tools/Boot":SinstPTH="/export/Solaris/s10/u5_x": and then update the clients that i want to use it, and reinstall. This design scales very well for numbers of clients, and numbers of builds of Solaris to install. I even have suspicions that I'll be able to do something similiar to boot and install linux. Doing it this way I don't even need add_install_client, but since this method is flexible, and scales well, there's no reason that add_install_client, (and maybe setup_install_server) couldn't be updated to actually set this stuff up in DHCP for you. As Mike's post, and another one I wrote, the setup process in the documentation for DHCP in Jumpstart is very complicated, and what add_install_client does today (and more importantly doesn't do) for you make little if any sense, basically leaving you with an unscalable mess to maintain. -Kyle
