All of the replies I received on this were of the form of "yeah, I'd
like to know that too". So I called the Sun tech line for a more
in-depth explanation of their viewpoint on handling patch upgrades.
I've now spoken to 4 different Sun engineers about the behavior and
effects of installpatch and backoutpatch. What I can say definitely is
that if you're confused you have good reason to be because so are they.
I can also say that while there are some general preferred guidelines,
there is no absolute answer for the approach you take, because how you
got to where you're at in your patch history will help determine what
steps you take for a given patch installation and upgrade. Still, if
you start using these steps outlined here from now on, you'll probably
be better off.
Here's a summary of the main points (including some obvious ones just
for completeness since there may be novice sys admins out there)-
1. Always use the installpatch and backoutpatch scripts that come
with a given patch. Although they always have the same name, they
are customized for each patch, and even for a single patch number
can change from rev to rev. Also, installing files that come with
a patch without using installpatch will work, but you will not have
any log of what changed that the system knows about. See item #5
for why this will become more and more critical.
2. Always look carefully at everything in the README file. This
is completely obvious, but you can get numb to this when things
start getting as automated as they are with the new patch scripts.
I realized that in my own case, while I was reading for details of
what the patch did, I was not carefully examining the READMEs for
requirements to back out of previous patches prior to installation.
I frankly got lazy because installpatch seems to do such a good job
of warning about any potential problems.
3. Installing new revs on top of older ones is the preferred
procedure, and you should really not backout any patches except
for special circumstances. An example of this is the kernel jumbo
patch -34 (or -33), which when installed created problems with Sybase
installations. It was eventually fixed around -42, but in the
meantime your only option was to back out of the buggy versions.
Another case would be where the README specifically requires you
to backout of some other patch (I have yet to come across this
circumstance since I've been using Solaris 2.4 and installpatch).
Installing one patch after another without backing out allows
you to review a complete patch rev history using showrev -p.
If you backout, any history info is lost I believe because showrev
looks at /var/sadm/patch to see what's there when displaying patch
revs and backoutpatch deletes info in /var/sadm/patch.
4. Always invoke installpatch with the necessary option to save
what it changes. When installing patches without backing out
previous revs first, installpatch can be told make a cpio archive
of all updated files in unique directories named
/var/sadm/patch/<patchnumber-rev>/save. This save feature is the
default installpatch behavior in Solaris 2.4; previous verions
required you to use a special flag to invoke the save option. The
*big* reason for doing this is for times when you discover that the
new rev of the patch breaks something and you need to run
backoutpatch. If the previous version has been saved, backoutpatch
will reload the previous rev's changes as it backs out the latest
version. If you've run backoutpatch unnecessarily in the past, these
changes will be lost and you'll have to re-run the previous
patch installation by hand (assuming you've kept that patch around)
to get to the rev you need.
**** I'd like some firsthand corroboration from this list about
**** the behavior of backoutpatch automatically reloading a previous
**** version of a patch. Can anyone confirm this really works without
**** problems?
5. Starting with the Solaris 2.5 versions of installpatch, changes
will not only be made in /var/sadm/patch, but also in /var/sadm/pkg.
The pkg directory is where information is kept about what filesets
are loaded. This makes it imperative to use patching tools in such
a way that you allow the system to retain the most information it
can about what system modifications are made. Otherwise, you might
hose any opportunity you have to do future OS or package upgrades
rather than full installations.
Hope this clears up some things.
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<*>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
Jim Napier jnapier@soe.ucsd.edu
Systems Administration (619)534-5212
School of Engineering
UC San Diego
"Man is nature's way of demonstrating that a little knowledge can
be dangerous."
<-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<*>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=->
My original post:
> Peter Watkins (peter@jrc.nl) recently posted the very useful summary
> below regarding backing out of earlier revs of patches when you don't have
> the complete installation history of an earlier patch.
> The one thing mentioned here that I've wondered about for quite awhile
> is whether an earlier rev patch *should* be backed out before a new one
> is installed. This was almost always true in the old days before things
> like installpatch came along, but is that still true? In our case on our
> S1000 and S5's we've always just installed new rev patches without ever
> backing out of old ones, under the assumption that a new rev will do all
> the right things as far as determining what an old rev did previously.
> In addition, it's never been completely clear to me that one rev of a
> patch will always deal with the identical set of files that an earlier
> rev will. So there's a danger that backing out from one rev may
> "unpatch" a part of your system that does not get updated on a later
> rev. In fact, a Sun engineer recently told me that she considered it a
> bad idea to back out of old patches because she'd seen instances where
> it appeared that approach caused problems when the new patch was
> applied.
> Is there any indication that one way or another is always going to
> be right? I have to believe that despite the nice way patches can be
> handled via the installpatch and backoutpatch programs, that this doesn't
> mean there's 100% consistency in how patch revs are constructed.
>
> Just for clarity my questions assume the following-
> 1. You always use installpatch
> 2. Your /var/sadm directory is intact and consistent throughout your
> patch history
> 3. You never install a patch that clearly states a conflict with some
> other patch or previous patch rev
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:02 CDT