swverify issues. How serious?

[Steven E. Protter]

Wait!

Let me guess.

PHCO_27671

swverify is screwed right?

[Paul Sperry · Accepted solution]

you beat me to it
I was going to suggest PHCO_27671

[Christopher Caldwell]

We get swverify issues all of the time, especially after we tighten down loose permissions.

Most swverify errors seem okay (I wish I could make them go away). You'll even get patches that conflict on permissions. I suppose if you're a wiz with SD-UX, you could figure out how to poke the control files to prevent the errors.

I'll look into
-checksum problems (someone may have tampered with a binary)
-size problems
-date problems

Ignore permission problems, use another tool to track permissions.

If I get an error in an area of concern, I disposition the error - sometimes it's a patch problem. If you can't disposition the error - worry about having been compromised (security).

[Steven E. Protter]

I'll tell you this.

The Ignite error is a mystery.

The check_patches thing, we had a problem with that and had to punch in a patch.

q4, there was a crash pach, so we put that in too.

I guess I'm going to have to live with this, but however pulled my support case is currently stumped.

One thing I won't tolerate is check_patches errors. Any patch that shows up bad on that is history. I think thats how I learned about the swverify command as a matter of fact.

Steve

[Steven E. Protter]

[1593#] check_patches
Obtaining information on installed patches
Checking installed version of /usr/sbin/swconfig
Checking for invalid patches
Checking object module checksums for active patch fileset 457 of 457
Checking patch filesets for active patch 225 of 225
Checking state for patch fileset 738 of 738
Checking patch_state for patch fileset 738 of 738
Running swverify on all patch filesets, this may take several minutes
RESULT: No problems found, review /tmp/check_patches.report for details.
tzfat:/root


hmmm....

Very interesting professor. Very interesting....

[Matt Williamson]

The mtime error should never pose a problem....but the size errors can be a little more scary. Are you able to create a good kernel? I had a similar problem and it took 5 months(no joke), of working with the the crisis mgt. team, to get all of the swverify errors cleaned up. I get a nearly clean swverify with the exception of a few patches that had errors due to the packaging. Good luck!

[Steven E. Protter]

Yeah, we can do a new kernel. Most of the checksum errors involve utilities that HP hosed with patches. q4 check_patches for example.

I just generated a new one to be safe, on your suggestion and appreciate it.