My original post highlighted 2 problems I was experiencing with
Custom Jumpstarts and finish scripts. They were:
Installing Patch Cluster-
Patch cluster install script for Solaris 2.5.1 Recommended
The nosave option was used. Objects will not be saved.
Installing patches located in /patches
Using patch_order file for patch installation sequence
Installing 103630-09...
Installation of 103630-09 failed. Return code 18.
Adding Packages-
/a/mnt/SUNWcpr.u/install/request: test: argument expected
pkgadd: ERROR: request script did not complete successfully
The following suggestions were received and the consensus seems to be
to use /etc/rcx.d scripts to do the work that I thought Jumpstart was
to be doing.
Maybe Jumpstart 2.0 will have the expected functionality?!
Thanks to the following for their help:
*********************************************************
From: davem@fdgroup.co.uk (David Mitchell)
I dont have direct answers to your queries, but a general comment is that
a lot of potential hazards can be avoided by having a minimal finish
script that does whatever absolutely has to be done right now, then
touches a file say /a/.newinstall, then reboots.
You also add an appropriate boot script which checks for /.newinstall,
and if so, does most of the things you'd normally be tempted to
do in a finish script such as patch installs; only this time, the root
directory is / not /a, and fewer things are likely to break.
The last action of the script would of course be to remove /.newinstall
and reboot.
Dave.
*********************************************************
*********************************************************
From: Jason Marshall <jasonm@vsl.com>
Hi Craig, when I first set up our Jumpstart environment at my old job, I
tried to make the finish script take care of everything imaginable. It
was a pain in the arse, though, having the machine's disk filesystems
mounted in /a. So, I decided to change my finish script so that all it
did was configure the machine minimally, *and* create a whack of
self-destructing /etc/rc2.d scripts. All the patches were installed in
these scripts, various files were modified to suit our environment, all
after the first reboot. The last rc2.d script re-rebooted the machine,
and it would come up quite normally, with all the logs and files in the
right place from all the rc-scripts. The biggest reason for doing this
was the "special configuration" most of our machines had; lots of siesmic
and petro/geophysical apps whose support scripts were quite
jumpstart-unaware.
Other people thought this was a hideous way to use Jumpstart, but I
figured to hell with them, it works too well for me NOT to do it.
Of course, none of this is an answer to your actual questions, but it may
still be of some help in the long run.
Jason
*********************************************************
*********************************************************
From: Jim Harmon <jharmon@telecnnct.com>
A discussion similar to this occured a few months ago...
turns out that when you're using the installation system (system build)
the /tmp dir is actually in the microroot dir, not the /swap dir.
Therefore, you fill up /tmp very quickly when doing message-intensive
stuff, like patch installs.
The two ways around it that I recall were to install less on the first
pass, or to flush the /tmp file after EACH operation.
Hope this helps....
Jim Harmon The Telephone Connection
*********************************************************
*********************************************************
From: gibian@stars1.hanscom.af.mil (Marc S. Gibian)
The patches are trying to install into the RAM resident OS booted off the CD,
not the OS being installed onto the system... thus your out of space problem.
This can be resolved by doing the actual patching in the /etc/rc*.d/S* file
during reboot rather than in the jumpstart itself. WE do it by using a second
jumpstart and a second custom jumpstart finish script. Its not the way I'd like
to do it, but we just didn't have time to use the boot time solution. And, we
will not need to do the OS install ourselves soon, so we will never have the
justification to spend the time to "get it right."
The second case I believe is resolved with a response file. See the pkgadd
documentation on how you do that. Some packages, though, appear not to properly
process a supplied response file.
-Marc
Director- Computing Services Division
UNIX Systems Support
College of Health and Human Development
Penn State University, 106 Henderson Building, University Park, PA 16802-6500
Voice: 814-863-9951 FAX: 814-863-9950 EMAIL: clg@csph.psu.edu
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:00 CDT