I found the exact symptoms on SunSolve under bug id 4678605. The idea is
when you use patchadd -M on an extended list of patches (like a whole
cluster), patchadd uses a random number generating function to create a
working directory (ie /tmp/1533011919). The pool if numbers is can tap
into to create that random number is 32768. They article says if you are
installing a couple hundred patches you have a 50/50 chance of the
random number being used twice. When the system sees a duplicate tmp
directory number it aborts the remainder of the patch installs. I've not
tried the fix, but Sun suggests modifying the patchadd function
"patch_quit" so that it removes files when the exit code is 2 (already
applied).
Thanks for everyones replies.
-Mark
Solaris wrote:
I decided to rejumpstart but this time left the console attached so I
could see any errors. It looks like the cluster install is aborting
part way thru (probably before kernel patch is applied) and is giving
me the following error:
/
unable to use /tmp/patchadd-1533011919 due to possible security issues/
I'm googling now but haven't had much luck. Thanks for any ideas you
might have.
Regards,
Mark
[EMAIL PROTECTED] wrote:
I had a similar problem in the past.
The way how it was solved was to move patch cluster to /tmp and install
from there.
---------------------------------------------------------------------------------------------
Any comments or statements made in this transmission reflect the views of
the sender and are not necessarily the views of the Federal Reserve Bank
of New York.
Simon Annear <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
12/15/2005 05:51 PM
Please respond to
Solaris-Users mailing list <[email protected]>
To
Solaris-Users mailing list <[email protected]>
cc
Subject
Re: [Solaris-Users] Cluster patch inconsistancies.
My guesses
One of the servers didn't reboot ? The uname -v just shows the kernel
patch level, so it indicates that the kernal patch hasn't applied (or
taken effect)
Try just running "showrev" to check out what kernel patch is applied to
each.
Solaris wrote:
Hello all,
I've got a jumpstart server that recently jumpstarted 3 separate,
brand new Sun Fire V210 systems. All three used the same jumpstart
profile, which installed the same version of Solaris 8, the same OS
install level (SUNWcall), partitioned the disks the same and all three
called the same finish script. In that finish script I automatically
install the Feb 2005 recommended patch cluster. When these V210s were
finished jumpstarting and they rebooted after the patch cluster
install, I looked at their kernel patch versions with "uname -v", and
2 are the same version and 1 is not. It is imperative that these be
the same as they are getting shipped to customers. A few questions:
-Any idea why these "uname -v" values would be different?
-Any idea how to tell what cluster patch the OS thinks is installed? I
don't think there is an equivalent, but something similar to
/etc/release, but for the patch cluster.
-Any way to insure 2 systems are at the same patch level without
having to do a manual comparison of a showrev -p output?
-Could the "uname -v" be different if there was a hidden hardware
difference such as a motherboard rev?
It seems the cluster patch area is a bit of a mystery on Solaris any
hints on how to ensure 2 systems are the same from a patching
perspective, would be greatly appreciated.
Thanks in advance and happy holidays.
-Mark
_______________________________________________
Solaris-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/solaris-users
_______________________________________________
Solaris-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/solaris-users
_______________________________________________
Solaris-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/solaris-users
_______________________________________________
Solaris-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/solaris-users
