Well I had several good responses that described when to patch the
autoclients depending on if the patches included files in /usr. Below
are the responses that explain that. If a patch has files that
go in /usr then that patch doesn't have to be applied to the autoclients
because /usr is backinstore filesystem for the autoclients. Someone
said though that the autoclient has to be the same hardware architecture
for it to recoginze it. I guess if it's a different architecture then
I'd have to apply it to the autoclient as well?????
My question about why the autoclients did not boot after patching
the server wasn't answered. My original post is
at the end of this email. I treid a boot -f on several of the
autoclients and this did not help. I also tried deleting and adding
back the autoclient in solstice and this did not help.
Finally I removed all 2.7 cluster patches with patchrm and now
the autoclients boot back up. So I"m wondering if this is going
to happen again when I try it.
From: Richard Smith <rc.smith@ibm.net>
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Martini <martini@mrpeabody.llnl.gov>
Subject: Re: Has anybody successfully Patched Autoclients?
Content-Transfer-Encoding: 7bit
Patches ordinarily affect files in both / and /usr, both of which are backingstore filesystems
on the autoclient server. When /usr is patched on the server, the autoclients are taken care of
automatically for those clients with the same arch as the server because server:/usr is the
backingstore for client:/usr . The root fs is different. Patching the / on server does not
affect
the clients because server:/export/root/<client> is the backingstore for client:/
soooo... both server and client should be up and running during patching. If the patch only
affects
/ and not /usr, the server need not be patched; just spool the patch, then use admclientpatch to
apply
to all the clients. Usually, the patch does affect /usr so patch the server first, then spool and
patch
the clients.
Problem is, client patching is slow, and verry difficult to backout. Try one innocuous patch
first to
see the effect before applying a cluster.
Since your clients are unable to boot now, and you mention you did indeed apply the client patches
on the server, try booting your autoclients with "boot -f" which forces it to replenish its local
cache
with the backingstore (/export/root/<client>) from the server. This should clear the problem. If
not,
you may need to re-install the client again via solstice host manager.
From: Barry Gamblin <bgamblin@hao.ucar.edu>
Subject: Re: Has anybody successfully Patched Autoclients?
To: martini@mrpeabody.llnl.gov
MIME-Version: 1.0
Content-MD5: vg38t9HbhmdFPIoh47TN8A==
yes, only the patches that have files that go in directories other that /usr
have to be applied to your autoclient root areas. I don't know of any automated
was to do this however. If you have a lot of autoclients, this is going to be
a real pain. Several NCAR admins had a meeting with the developers of the
autoclient product a few months ago, and patching was the main thing we
discussed, since it is such a royal pain in the butt. They are working on
improvements, but they are not in this release, and no promises were made for
the next one. But they are at least aware of the problem. They have heard the
same thing over and over from other users of the product.
Good luck, Barry
Hi All we took a stab at patching the autoclients using the sunsolve
procedure in infodoc 15677.
After I installed the Solaris 2.7 Cluster to the autoclient server
first and rebooted the server (here is list of patches I installed)
106541-05 106934-03 106960-01 107038-01 107171-02 107259-01 107456-01
106725-01 106944-02 106978-06 107115-02 107200-06 107337-01 107684-01
106793-01 106952-01 107022-02 107117-04 107219-02 107451-01
The autoclients would not boot up. I didn't even start the procedure to install
the patches to the autoclients I just patched the autocleint server machine
first.
THe errors I got when trying to boot the autocleints using boot net at the ok prompt
were
FATAL could not mount cache device /dev/dsk/c0t3d0s0 Program Terminated.
I also got this message on some autoclients
/usr/kernel/drv//sparcv8/tnf: undefined symbol tnf_changed_probe_list.
Patching the autoclient server with the above 2.7 cluster broke the autoclients
has anybody else experienced this and how can I get the autoclients to boot up
after patching the autoclient server? After the autocleints would not boot I went
through the procedure of synchronizing the autoclients to the spool area where
the patches were and still the autoclients would not boot up and produced the
above errors.
Do the autoclients have to be powered up when doing the synchronize?? We had
powered them down before starting the procedure.
Since the autocleint server was not patched I patched that first and rebooted and
then patched the autoclients was this the correct order?
Any tips or pointers to fix this would be appreciated.
Thank you.
Dave Martini
LLNL
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:24 CDT