Sean Alderman wrote: > I appreciate your assistance... > > I am currently working with Solaris 10 U6. > > We have used jumpstart successfully in the past using a different approach, > but this process has never been easy as pie. As I stated, we boot to a Linux > based tftp server which initially loads pxe.linux, then chain loads to > pxe.grub. So until my current testing we have never used the scripts > included with the DVD..it was all hand edited. We used to build a tar file > for every server, and the grub entry looks like: > > title sandbox04 > kernel /solaris/multiboot kernel/unix -v -m verbose install > http://172.18.99.22/jumpstart/amd64/sandbox04.tar -B > install_media=172.18.12.248:/jumpstart/amd64/ > module /solaris/x86.miniroot > > Hmm. I've never tried a tar file over HTTP. That's interesteing. > TBH it has not worked since I upgraded our install repository and grub > kernels from U4 to U5, luckily for me we have not had to build any new Sun > Servers for production use in over a year. > I think it was U5 introduced some form of the 'newboot' project for X86.
It's what broke the '- install dhcp' (getting all the jumpstart paramters through dhcp options) and forced the use of -B. I don't know if thats part of the problem in your u4-u5 upgrade or not. 'newboot' (I think did away with the use of 'multiboot' to load the kernel, though it still might be there. It's been so long since I network booted S10, Mostly I boot Nevada these days. I know Nevada loads the kernel directly, as you can see in the menu.lst I sent. > Now that U6 is out, I decided to eliminate any issues with our everyday > architecture. So I started from scratch following the methods in the big > admin article I referenced in my OP - > http://www.sun.com/bigadmin/features/articles/jumpstart_x86_x64.jsp After > reading this article, a lightbulb appeared over my head because we should no > longer need to have a complete tar of the config dir for each server in order > to have unique sysidcfg files, instead we could have a common config dir and > unique sysidcfgs for each server and let the rules figure out which machine > profile to use. That concept is golden, and what I hope to get working. > Yes. If you absolutely need different sysidcfg files, then you do need separate menu.lst files since that's how you point Solaris at the correct sysidcfg files. I've managed to get away with not only just one sysidcfg file for all machines, but so far only 1 sysidcfg file for both a10 and sNV, and it might even work for s9 too thought I'm not going to try it. My rules are simple all hosts get the same begin and finish scripts, and the begin script makes the profile on the fly. > I make a sysidcfg for each system, the goal is to do the small pieces of work > up front that will make the system as close to 100% ready to go when the > install is done. I did not include it but you should see the ~200 line > finish script we have built. It includes hardening, user additions, ssh key > distribution, custom ntp sshd and other service configurations, additional > filesystems or pools as hardware profiles or application profiles require, > etc. I leave all the work for my modular JS framework. It's probably more than 200 lines of scripting, but the input files are tiny, and they dictate what happens on each host. The key for me was not keeping the same config info in more than one config file, and leaving the possibility that I might miss making an update it in some of them. It doesn't do any thing zone specifc these days, but it could. > We try and build as much into the install profile as possible to reduce both > the amount of post install config and knowledge required to rebuild. If/when > we have to rebuild or refresh hardware, it's quite useful to have the history > of the installation profile, it stands as sort of automatic configuration > documentation...though perhaps cryptic to the untrained eye. > I agree, my install leaves the machines ready to use. Not 1 thing more needs to be done. And I generally don't modify a machine after install either... my philosophy is to modify the install, and re-install the machine if possible. That way I know that if the machine is trashed, I can always reproduce what was there. Anyway, back to your problem... Did you try removing the 'dhcp'? and leaving just 'install'? -Kyle
