swlist "Incomplete definition for the product" errors

[Carl Houseman]

I have a system that is exhibiting about 25 or so of these warnings (all for different patches) when using swlist:

WARNING: Incomplete definition for the product "PHSS_22535", beginning
at line 42119. The following attributes are not defined:
filesets the filesets contained in the product

After the warnings, the swlist output is produced and does not list any of the individual patches previously warned about.

The same list of warnings occurs following a successful make_net_recovery copy of the entire vg00.

It didn't used to do this. In the time since I may have done a cleanup -c. Could this be a side-effect of that?

There are no other system problems that I'm aware of - it boots and everything is working well.

[Carl Houseman]

OBTW, HP-UX 11.11 if anyone cares.

[Steven E. Protter]

Shalom,

swverify \* | grep PHSS_22535

It would appear something has gone wrong and cleanup -c does not cause this error.

SEP

[Coolmar]

Check out the following technical article. Hopefully it can help you out.

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&admit=-682735245+1168274113723+28353475&docId=200000080035994

[Carl Houseman]

You guys are quick!

Coolmar, the article talks about removing patch definitions from a system upgraded from 10.20. This system has been HP-UX 11.11 from the beginning. I attempted the procedure anyway, and got these results:

swlist result:

PHSS_22535 1.0 ld(1) and linker tools cumulative patch

and then I tried:

swmodify -u PHSS_22535,r="ld(1) and linker tools cumulative patch"

and it failed with:

ERROR: Could not select the software "PHSS_22535,r=ld(1) and linker
tools cumulative patch". This software does not exist in the
target. You must specify either the correct target, or the
correct software selections.

[Carl Houseman]

Steven, when running swverify I get the same set of 25 warnings again, followed by a set of 25 errors similar to this:

ERROR: Could not apply the software selection "PHSS_22535:/" because
there are no product variations that are compatible with the
destination host(s).

That is followed by this:

WARNING: "hpr2:/": 2 check scripts had warnings.
ERROR: "hpr2:/": The software dependencies for 1 products or
filesets cannot be resolved.
ERROR: "hpr2:/": 9 files had errors during this operation.
WARNING: "hpr2:/": 34 files had warnings during this operation.

There is apparently nothing returned for the grep results for PHSS_22535.

[Wouter Jagers]

Check out this thread as well:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=428627

Might be useful..
Cheers

[Carl Houseman]

I checked out that thread. My symptoms don't quite match - I have no zero byte INDEX in the PHSS_22535 directory.

I'll need to lookup what "rebuilt the IPD" entails. Or you guys can just tell me here... :)

I also tried re-installing PHSS_22535 and the logfile indicated that all 32 components of that patch had been superceded by another patch that is installed.

[Carl Houseman]

Retraction - there is a 0 byte INDEX for PHSS_22535. My first search was incomplete.

[Carl Houseman]

OK, I've read up on rebuilding the IPD and I've found two not-quite-matching set of instructions for doing that. I've also found that rebuilding the IPD is the solution of last resort. Is there no way I can make swmodify -u work for this?

In any event, the two IPD rebuild methods I've found both use a void.pst file containing:
------
product
tag void
fileset
tag void
------
Then (method 1)

# swpackage -s /tmp/void.psf
# swinstall void
# swremove void
# swremove -d void

or (method 2)

# cd /var/adm/sw/products
# mv INDEX INDEX.old
# swpackage -s /tmp/void.psf
# swinstall void

Any comments on the merits of first removing the old old INDEX in /var/adm/sw/products?

I would think swremove of "void" product is a good idea in any event.

Thanks all.

[Carl Houseman]

Well... I forged ahead. Moved the supereceded patch directories out of /var/adm/sw/products, and rebuilt the IPD using a combination of both procedures.

I now have a clean swlist result, and check_patches, which was OK before, is still OK.

The only question that remains is "what caused this" and "is it avoidable" ? I'll leave the topic open in case anyone cares to comment.

[Bill Hassell]

One of the causes for these types of errors is a root admin who just removes big files 'because /var is full'. /var/adm/sw is a critical directory for HP-UX and once corrupt, you can't install or remove software for patches. That's why looking for big files isn't the right way to manage disk space. If /var is getting full, you can make a lot of extra space by creating separate mount points for /var/ad//sw (and perhaps /var/adm/crash, /var/tmp, etc). Then move the contents of those directories to the new location and add the new mount point(s) to fstab and test them.

[Carl Houseman]

I worked some on /var/tmp at one point, but not anywhere else on /var except through use of the cleanup command.

It's no small coincidence that only older, superceded patches, were being reported in error.