Hello again!
Thanks to all responders !
This problem (see below) turned out to be a bit tricky to solve:
Tom Webster pointed me to the way dupatch is supposed to work:
-----------------------------------------------------------------
Try starting dupatch, this part can be done in multi-user mode, and
select "Patch Baseline Analysis/Adjustment" this should do what you are
looking for. It will look for any files that are in the patch's
dependency list that are not as expected and ask you if you want to
allow the patches to proceed.
Then try running the patch install dependency check and make sure
everything is fine. If so apply the patches.
-----------------------------------------------------------------
But, although it complained during baseline analysis, it did not
ask me (a bug?).
Gary Phipps (yes, you were right...) warned me about /genvmunix:
-----------------------------------------------------------------
I think you may have made a major mistake.
You shouldn't rebuild /genvmunix !
/genvmunix is the generic version of the kernel that you boot from
to build drivers etc. Once you have booted genvmunix, this is where
you build /vmunix. Oops.
If you have another system, I'd copy genvmunix if I were you......
-----------------------------------------------------------------
I refused to believe this, since the rebuild was a regular action
described in the patch instruction for the earlier cdfs ECO kit.
But then "The Doctor" Tom Blinn (thanks a lot !) gave me (as always)
a deeper insight into what's actually going on there:
-----------------------------------------------------------------
There are options in dupatch to force it to trust your /genvmunix.
The /genvmunix checksum and size are recorded in an inventory (.inv)
file in /usr/.smdb. and if you fix them to match your copy, then it
will work. You should have saved the original file and put it back
before the patching, but you could restore the original file from a
V5.1 media kit. dupatch checks both the size and the checksum, and
since the build date is embedded in the file, you've changed the sum
on the file.
We never rely on customers to regenerate genvmunix -- it is NOT a
file that can be easily regenerated with its original contents, as
you have just proven, and it if it's broken (because someone replaced
part of the .mod files with ones that don't work), the system may be
totally unserviceable.
-----------------------------------------------------------------
This made me a bit scary, because we already applied earlier patchkits,
so I had to track down all subsequent changes of /genvmunix to find the
most recent inventory to fake:
cd /usr/.smdb. ; grep genvmunix *.inv
Luckily, this showed that only patch 167 (OSFPAT00016700510.inv) touched
genvmunix after the initial install (OSFHWBASE510.inv). So a
ls -l /genvmunix ; sum /genvmunix ; strings /genvmunix|grep 2001
gave me size, checksum (1.parameter) and modification date of /genvmunix,
which I entered in the 2., 3. and 7. position, resp., of the patch inventory
file, and dupatch worked as expected !
This operation is only safe because the patches are the whole files, not
"real patches" like in Linux. As I noticed, my rebuilded genvmunix was about
18 MB larger than the one the patch gave me back. The /usr/sys/conf/GENERIC
seems to have many unnecessary entries (like different CPU drivers)
which are
not activated in the patched file or the one from the media kit. So
rebuilding
genvmunix at least wastes space and prevents regular patchkits from doing
their job.
As a resume I would recommend to stay away from those "in between" ECO kits
if they are not absolutely essential for you.
========================= ORIGINAL QUESTION
=================================
>> I've an annoying problem with patchkit 3 Tru 5.1 on
>> an ES40 (still no cluster):
>> We applied the cdfs ECO which appeared last year. It was a
>> hand-installable patch (exchanging /sys/BINARY/cdfs.mod and
>> regenerating /genvmunix). Patchkit 3 now complains about
>> /genvmunix beeing of unknown origin, so it refuses to install
>> patch 399 and all its dependants. So I exchanged cdfs.mod again
>> (to the old one) and regenerated /genvmunix. Now it successfully
>> applies the cdfs patch (which is included in patchkit 3), but
>> still refuses to apply 399. I also played with faking the date
>> of /genvmunix, but no success.
>> How to get out of this situation ? I really don't understand why
>> /genvmunix has to be patched because this is a file which can be
>> easily regenerated, so it makes no sense to check this one for
>> patch applicability.
=============================================================================>
--
Dr. Udo Grabowski email: udo.grabowski_at_imk.fzk.de
Institut f. Meteorologie und Klimaforschung II, Forschungszentrum Karslruhe
Postfach 3640, D-76021 Karlsruhe, Germany Tel: (+49) 7247 82-6026
http://www.fzk.de/imk/imk2/ame/grabowski/ Fax: " -6141
Received on Thu Apr 26 2001 - 09:07:54 NZST