SUMMARY: Patchadd woes - solaris 2.6 [horribly overdue..]

Alas, it seems that the exceptionally low number of replies I got on
this, coupled with a lot of busy-stuff distracting me (moved buildings),
I managed to forget to post a summary to this issue.

Basic problem overview: Couldn't apply recommended patch cluster
(june-01 rev) against an E450 running 2.6 and patched already to dec-00
level with recommended patch cluster.  Persistent errors cause the
entire process to tank consistently.

The solution:

-> Downloaded the Sept-01 recommened patch cluster and gave that a go. 
Worked like a charm - NO hint of errors at any point.

[Side implications in my case: Permissions within /var/sadm were OK ;
the use of a soft link for /var/sadm -> /opt/VAR/sadm isn't a problem ;
and in my case, the umask worked fine, despite the paranoid value of
137]
 
It isn't quite clear to me precisely why the july cluster failed to
apply, when then sept. cluster went just fine.  I do gather, however,
that contrary to my initial posting, this sort of problem is neither
trivial nor straightforward to diagnose. In cases where patch clusters
do not apply persistently, I'm told that debugging the situation can be
a really tricky task. So - I'm happy that such a straightforward
solution worked, even if it fails to resolve the underlying question of
"why did this happen in the first place?!?"

I hope this summary helps other folks trawling the archive in the future
resolve similar problems :-)


--Tim Chipman




ORIGINAL POSTING:
Wed, 26 Sep 2001 20:09:59 -0400



This is almost certainly a terribly obvious question, but alas I'm
unable to get it sorted out. Any pointers are greatly appreciated.

I'm working on a e450 sparc solaris 2.6 system (4 cpu, 2 gigs ram,
currently at Dec-2000 jumbo-patch level).

I attempted to apply the june-2001 jumbo patch cluster a few months
back, and ran into a few bumps. At the time, I thought patches were not
going in because my /var slice was not terribly spacious for inherited /
legacy reasons (192 megs total size, ~ 95% full with most used by
/var/sadm stuff).  I attempted to be "sneaky" and moved /var/sadm to
/opt/VAR/sadm and soft-linked one to the other. Note that the /opt slice
has ~1.3 gigs free currently - plenty I believe?).  However -- clearly
it is now important to "mountall" while booting single-user before
attempting patches :-)

Anyhow. I had hoped this jury-rigging madness was the end of my grief.

Only just got scheduled downtime tonight and had a go at patching.  It
consistently tanks with "verifying sufficient filesystem capacity...".
If I <break> and examine the
/var/sadm/install_data/Solaris_2.6_Recommended_log, I can see stuff like
this:

Checking installed patches...
Re-installing patch 105356-18...
/usr/sbin/patchadd[49]: /var/sadm/patch/105356-18/log: cannot create
Verifying sufficient filesystem capacity (dry run method)...

however, the directory /var/sadm/patch/105356-18/ didn't exist.

I've already confirmed that the full path to /var/sadm/patch/ is
accessible by user "nobody", as is the full path to my location from
which I'm installing the patch (/opt/patch/jumbo). I've also added a
user on the system as follows:

install:x:0:1:installpatch braindamage:/:/bin/true

since a quick "google" search revealed that a fallback measure for user
"nobody" is user "install" for installpatch related braindead behaviour.

All to no avail. The *$&@#$ system will still not patch.

I noted that the default umask for the root user in /.cshrc was set
rather super-paranoid, ie, 
umask 137 , and it seemed concievable that maybe the last time (a few
months ago) I tried this business, a file ?somewhere? in the
/var/sadm/patch ... tree got its permissions hammered such that I can't
touch it anymore to do patches.  Alas, I'm not keen to chmod -R 777 the
whole thing (to say the least) - especially since I'm not even sure this
is the problem.

Enough ranting. I will stop. If you can all stop laughing now and give
me a pointer in the right direction, it will be massively appreciated.

<as always, a summary will follow>

Thanks,


Tim Chipman