From: Iain Barker (ibarker@aastra.com)
Date: Tue Jun 15 2004 - 11:26:32 EDT
No idea why the two tools see different patch databases, but the quick way
to fix the corruption is to restore the individual patch files from the
backup copy in /var/adm/patch/backup then remove the setld references from
/usr/.smdb. and finbally reinstall the patch using dupatch.
See below for details from Jenny Butler (thanks) how to delete the patch
manually, and restore the original configuration more carefully than I did!
For some reason dupatch couldn't install using patch ID C409.01, but when
I tried to reinstall it as 'all patches in a kit' rather than as a single
patch it worked successfully.
./dupatch -install -kit . -name x -note x -patch all
Now both setld and dupatch can see the patch and ssh is operating correctly.
> setld -i | grep OSFPATC0040901540
OSFPATC0040901540 installed Patch: Fix for SSRT3629B, ssh (Security Related Patches)
>>> Email from Jenny Butler:
First, have a good backup and second, do this with caution! If this
is a production system, try it first on a test system.
Look in /usr/.smdb. for files names OSFPATC0040901540.* and
in the .inv file, it will list the files that were changed by the patch kit.
If you used the setld option to make this patch reversable, the previous
files should be saved in /var/adm/patch/backup under the name
OSFPATC0040901540.tar.gz. You could retrieve the previous
version of files from that backup file.
Carefully, verify whether the files listed in the .inv file were replaced
by the patch or not. If so, unzip/untar the backup file into a temporary
or non-system space (maybe /usr/local/src). Check the sizes, dates,
and you can check the checksums of these files versus those in
the "production" location. If you have everything you need, you can
remove the files in /usr/.smdb. named OSFPATC0040901540.*
and then go to /usr/cluster/members/member0/.smdb. and remove
the OSFPATC0040901540.sts (this is where setld get the status)
and this will make setld -i not list this patch. Oh, you didn't say
you were on a TruCluster, but if you were, you would need to also
check and clean out /usr/cluster/members/member1/.smdb., member2,
and so on for as many members as there are - only the OSFPATC0040901540
files.
Finally, put back the pre-patch files from the .tar.gz backup carefully,
being sure about protections, ownership, links, and any other things.
Do a ls -l before and after - maybe even saving the files before you put
the old ones back - take as many precautions as you can.
-----Original Message-----
From: tru64-unix-managers-owner@ornl.gov
[mailto:tru64-unix-managers-owner@ornl.gov]On Behalf Of Iain Barker
Sent: Tuesday, 15 June, 2004 10:41
To: tru64-unix-managers@ornl.gov
Subject: Removing a corrupt patch
I've got a system on which the ssh patch partially applied, and now ssh doesn't work.
(T64KIT0020964-V51BB24-ES-20031204.tar, patch OSFPATC0040901540 number C409.01 on Tru64_UNIX_V5.1B)
Using setld I can see the patch is present, but is not in the correct "installed" state:
> setld -i | grep OSFPATC0040901540
OSFPATC0040901540 load completed Patch: Fix for SSRT3629B, ssh (Security Related Patches)
I booted single user to use dupatch to delete the patch, but now dupatch doesn't think it's installed:
# dupatch -delete -name x -note x -patch C409.01
Patch "C409.01" for Tru64_UNIX_V5.1B is not installed on your system.
There are no deletable patches as specified on the command line.
Also, if I do a "dupatch -track -type patch" it doesn't show this patch in the installed list.
Somehow dupatch and setld seem to have a different list of patches that are applied.
Any ideas?
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:50:01 EDT