From: Shaun.Racine@intier.com
Date: Tue Jun 08 2004 - 06:15:46 EDT
Dear All,
Thank you very much for the extremely quick replies from;
Danielle Georgette
B L Venkatesh
Danielle was kind enough to send me numerous emails detailing how to
resolve .inv differences (rolled into one below), but I found Danielle's
initial suggestion of setld -d to work fine. I did not attempt the
Baselining option offered by B L Venkatesh, so I do not know if this would
work also.
Best regards,
Shaun
Solution
========
root> setld -i|grep SYSCHECK
SYSCHECK132 installed Syscheck utility
root> setld -d SYSCHECK132
Deleting "Syscheck utility" (SYSCHECK132).
/usr/sbin/sys_check updated to use sys_check version 124.
Version 124 is now the system default version.
I ran dupatch pre-installation check again, this time no problems (161
patches to apply).
Original question
=================
Alphaserver 4100, single CPU, 512Mb RAM
T64 5.1A
Current patch kit 4.
I am having trouble applying patch kit 6. The verification fails with
(output trimmed here, all lines end with "..origin...");
Problem installing:
- Tru64_UNIX_V5.1A / Security Related Patches:
Patch 02084.00 - Security (SSRT2191)
./usr/lbin/adm_lk:
./usr/lbin/binex:
./usr/lbin/cliscript5:
./usr/lbin/getswxcrrev:
./usr/lbin/nchstats:
./usr/lbin/ra200info5:
./usr/lbin/sysconf:
./usr/lbin/vmstats:
./usr/sbin/sys_check:
its origin can not be identified.
I suspect this may be because the version of sys_check has been upgraded to
v132.0 independently.
Is this the problem?
How can I bypass / revert to the correct version of sys_check for this
patch? (What should the correct version be (114?)?)
RESPONSE FROM
DANIELLE GEORGETTE
==================
We had the same problem, either setld -d that version of syscheck or
edit the .inv files to match what you have installed.
The inv files are found in /usr/.smdb./ and provide a list of what setld
thinks is installed on the system including checksums of the files it
expects are installed. These are used to check patch dependences and
inconsistencies in these records are the cause of patch 2048 failing to
install. You need to change the most recent .inv record for each problem
file to match the name, checksum, owner and permissions that are the
actual state of your system. Your problem files are all for syscheck and
likely to be all listed in the one file, lucky for you that's easy to
fix.
For example, one of your problem files is /usr/lbin/adm_lk.
Find the .inv records for that file:
tststb3:># grep /usr/lbin/adm_lk /usr/.smdb./*.inv
/usr/.smdb./OSFPAT00080700520.inv:0 16640 53219 3 4
100755 5/13/02 520 f ./usr/lbin/adm_lk none
OSFPAT00080700520
/usr/.smdb./OSFPAT00183000520.inv:0 16640 53219 3 4
100755 5/13/02 520 f ./usr/lbin/adm_lk none
OSFPAT00183000520
/usr/.smdb./OSFPAT00208400520.inv:0 16640 53219 3 4
100755 5/13/02 520 f ./usr/lbin/adm_lk none
OSFPAT00208400520
/usr/.smdb./OSFSERVICETOOLS520.inv:0 16640 65338 3 4
100755 8/1/01 520 f ./usr/lbin/adm_lk none
OSFSERVICETOOLS520
Most recent version is from 5/13/02 and expects to find the file with
owner 3 (bin) group 4 (bin) size 16640 and checksum 53219.
This matches my system state:
tststb3:># ls -al /usr/lbin/adm_lk
-rwxr-xr-x 1 bin bin 16640 May 13 2002
/usr/lbin/adm_lk
tststb3:># sum /usr/lbin/adm_lk
53219 17 /usr/lbin/adm_lk
If it didn't I would either find a version of the binary that matched
the inv record and put that in place over the non-matching version, or
as a workaround edit the inv file to make it match what my system had
installed. In this case I would edit the
/usr/.smdb./OSFPAT00080700520.inv file.
You need to edit the most recent entry line for the problem file in the
most recently installed *.inv file returned by the grep to
match the files you have installed on the system, if there are different
checksums and filesizes listed it's the latest one the system takes as
current. Make sure you take a copy of each .inv file before you change
it so you can put it back after the patch, even though it's broken it's
best to leave it standardly broken (ie HPs problem) rather than leave
your own changes in and perhaps cause a support nightmare later on ;)
Sorry this is so long, I'd rather overexplain than underexplain and
leave you caught with some gotcha I didn't alert you to.
One very last thing,
If you copy the original version of the .inv file back after the patch
you may need to add any details the patch updated your hacked .inv file
with back into the old file you're replacing it with, or else that file
will still be inconsistent when you try to load the next patchkit
somewhere down the track.
Just do the:
grep /usr/lbin/adm_lk /usr/.smdb./*.inv
again after the patch is installed and make sure you only get the same
lines returned as last time. If there is another line added for
something the new patch has installed you'll need to add that line into
the old .inv before you copy it back.
Danille
RESPONSE FROM
B L Venkatesh
=============
I am not sure about the cause for this problem. But, a workaround is to
use the 'Baselining' option available in dupatch menu.
blv
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:50:00 EDT