Those other patches may have been superceded or obsoleted by newer
patches, and perhaps the superceded patches are already installed. Try
searching the patchdiag.xref file for the various patch numbers (without
revisions), eg
egrep '108528|117000|128624' /var/tmp/patchdiag.xref
regards,
-glenn
Could we approach this a different way by first getting a list of missing
patches relevant to a patchdiag slightly *newer* than the CPU, then filter that
list with the list of patches on the CPU?
e.g.,
pca missing patches.missing.full
for patch in `cat cpu_patches.lst | cut -d- -f1`; do
Ateeq Altaf wrote:
Could we approach this a different way by first getting a list of missing
patches relevant to a patchdiag slightly *newer* than the CPU, then filter
that list with the list of patches on the CPU?
Should get you close. It also depends whether you succeed in finding the
Martin,
I kind of disagree on using CPU for couple of reasons.
1. CPU tends to change within the given release, hence the different
revisions (Am I wrong in this assessment?)
2. CPU tends to install on the minimum patch revision which will get the OS
off the vulnerability. I like to patch my
Rajiv,
I kind of disagree on using CPU for couple of reasons.
Maybe you got me wrong - it's not that I use the CPU myself - I agree with what
you say. Personally, I don't see much sense in installing an outdated revision
of a patch. Why not get *all* available fixes, when I'm installing a
little help wrote:
Glenn,
That seems to provide a bit more detail, which seems to make sense had I
not seen the patchinfo file. I ran the pca command against the patch
without a revision (see below) and then ran the same command against the
dependencies to see if they had any pre-requisites
