PHKL_21595 Patch Corrupt

[TrustNo1]

Happy Monday!
OS 10.20 , Problems incurred while patching HSC 100BT with PHNE_22216 and it?s prereq?s.
I downloaded the required bundle and created a depot with the ?create_depot_hpux_10 script?.
The analysis phase went smooth, but on install I got errors that pointed to write permissions. I attempted to ?abort? but got a message that I might not be able to boot if I did so, I went to the ?depot? directory and changed the permissions with chmod ?R 770.

I went back and finished the installation.
After booting, I ran ?swlist -l fileset -a state | grep -ie corr -ie install -ie trans?
I got back ?PHKL_21595.PHKL_21595 corrupt?
PHKL_21595 does NOT show in swremove.
PHKL_21595 DOES show in swlist ?l product.

PHKL_16751 lists as ?PHKL_16751 B.10.00.00.AA SIG_IGN + SIGCLD still got some sticking zombies?

Attached is the swinstall log.

Thanks for your assistance! ~jdk

[Steven E. Protter]

You will almost certainly need to boot your system.

/sbin/init.d/swagentd stop
/sbin/init.d/swagentd start

Its usually not a good idea to abort patche installs while they are running. Hence the warning. It will run to complettion and if it has errors, it simply won't install the patch.

Before you do anything, have an ignite make_tape_recovery tape present, because you might have an unbootable system.

make sure there is a good vmunix.prev kernel in the /stand filesystem, just in case you have to boot off of it.

Try the swagent stuff above and see if you can swremove the patch.

If that doesn't work, boot and try again.

If that doesn't work, it might be time to get some help.

SEP

[TrustNo1]

Steven,
Thanks for the quick response!

The box HAS been booted (twice)it and the NIC seem to be fine.

NOTES: PHKL_16751 has been in a while;
drwxr-xr-x 3 root sys 1024 Nov 1 1998 PHKL_16751

I tried a forced reinstall but was told to remove it first!

Any thoughts?

~jdk

[TrustNo1]

Steven,
I think I missed the obvious....
I can boot from the vmunix.prev kernel and the patches won't be installed right?

Then if I'm feeling lucky I can reinstallthe package again.

At that point would I neeed to change the swinstall options to reinstall all files and filesets?

Thanks, ~jdk

[Robert-Jan Goossens]

JDK,

The patches are installed, even if you boot from your prev kernel, the drivers will not be installed.

Only solution is to restore from backup and start all over again.

Not a plesent message.

Sincerly,

Robert-Jan.

[Pete Randall]

jdk,

Have you tried the swremove? If you can get that to work, then you can try to reinstall. Otherwise, it looks like time to restore from backup and then try the reinstall.


Pete

[Steven E. Protter · Accepted solution]

If the patches messed up your kernel which seems possible based the warning message, booting off the previous kernel will at least let you boot.

Then stand a better chance of having swremove work.

Booting off the prior kernel only removes the kernel portion of the patches. It does not remove them from the SD-UX database.

SEP

[TrustNo1]

Pete,
"swremove" does NOT even show the patch as removable. "swlist -l product" does.

Steve, I think you have the winning idea, or at least the one I think I'll go with.

~jdk

[TrustNo1]

Robert, sorry I missed your response until I reviewed all.

A "ignite-ux" restore is NOT totally out of the question, but it sure is not the way I hoped it might go.

Thank you for the response!
and may God have mercy on my kernel....
~joe

[TrustNo1]

Thought you guys might like to know that after a thorough review of swremove's inventory I have located the missing PHKL_21595 and it's associates.
They currently reside as a subset of the listing "BUNDLE" found amoung the "Products" listings.
If I understand it correctly, if ALL 5 of the patches would have installed correctly, the listing "BUNDLE" would have been "parsed" out, each patch to it's own respective sw/patch/ directory. Does this sound reasonable?

This Sunday I plan to swremove "BUNDLE" , then with r-w permissions set correctly from the begining, the install should work.

any thoughts are much appreciated!
~jdk

[TrustNo1]

Well no replies.... so I'll refigure... it's because I selected the "BUNDLE" rather than the individual patches, as I have been normally apt to do for the past whatever years....

~jdk

[Steven E. Protter]

Please report final results.

This is a most interesting situation.

I think going after the Bundle is the only way to go.

A quick run on the check_patches command might give you more insight in to what went wrong.

SEP

[TrustNo1]

Thanks Steven,
I will report back on the BUNDLE removal.
Meanwhile from Ross Martin (HP Response Center)on "check_patches";
"There is no 'check_patches' for 10.20. It has been requested often, but 10.20 is at the end of its life cycle, so there are no plans to ever provide a version for 10.20."

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x937c1cc6003bd6118fff0090279cd0f9,00.html

I'm not sure his script fits the bill, but I might give it a shot anyway.

~jdk

[TrustNo1]

First the system was backed-up to the hilt.

The swremove of the "BUNDLE" was successful.
After reboot, three patches showed as unconfigured, PHCO_16591, PHKL_20483 & PHNE_18924. An " swconfig \* " fixed that.

Another reboot and ALL patches were configured this time. Then as before, I created the depot with the "create_depot_hp-ux_10" script.

This time I chown'd -R owner to root, chgrp'd -R group to sys, and did a chmod -R 770 on the depot.
The "BUNDLE", selected at the "patch subset level" then went in fine!

(This was a K460, now I have to de-ATM a T520)
Thanks for the assist!
~jdk