Removing a committed patch

[Mike Keys]

I updated our Ignite software to the latest version of C.7.2.94. Before I did this, I installed the latest cumulative pax patch (PHCO_35998). I had the pax patch PHCO_32438 onthe system previously. I went in via 'swremove' after upgrading the pax patch and can see both versions now. I assume I should only see 1.

I ran cleanup -c 1 to see if this would help. Nada.

I ran check_patches as well but nothing was reported against this patch.

I want to ensure that the system is correct and that I am using the correct version of the pax program.

Ignite installed fine after doing an swremove of it first and then installing with swinstall. I am running Ignite at the moment so I know it works.

Thanks.

[James R. Ferguson · Accepted solution]

Hi Mike:

If you wish to assuage your fears, do:

# swlist -a state PHCO_35998

You will see "configured" if everything is well.

Installing a more recent version of a patch does not remove the previous version. That allows you to remove the newer and return to the older one.

Regards!

...JRF...

[Fabian Briseño]

Hello mike.
did you check

/var/adm/sw/swagent.log and
/var/adm/sw/swagentd.log

to see if there is any warning or error ?

[James R. Ferguson]

Mike:

You could also do:

# swlist -l fileset -a patch_state PHCO_35998

Unless you specifically commited the patch (e.g. with 'swmodiify') or installed it without saving rollback files, you should see the patch_state as "applied".

# swlist -a patch_state -x show_superseded_patches=true PHCO_35998

...will reveal the superseded ancestors of PHCO_35998 that exist on your system.

Regards!

...JRF...

[Dennis Handly]

It appears your question wasn't about "Removing a committed patch"?

But if you do, you'll end up back to the OS base release. (At least I think you'll have something left.) If want to re-install a previous patch, you'll have to download it again.

[Mike Keys]

Thanks for the suggestions.

I ran this command:
swlist -a patch_state -x show_superseded_patches=true PHCO_35998

and it returned nothing. Yes, the patch I applied is committed, so tha is o.k. My REAL question I guess (should have worded it better)is why I am now seeing both pax patches when I do a "swlist -i". Shouldn't I see only one pax cumulative patch in this list if what I applied superceded the previous version? If I do a "show_patches" the older pax patch does not show up in this.

[James R. Ferguson]

Hi (again) Mike:

> My REAL question I guess (should have worded it better)is why I am now seeing both pax patches when I do a "swlist -i". Shouldn't I see only one pax cumulative patch in this list if what I applied superceded the previous version? If I do a "show_patches" the older pax patch does not show up in this.

OK, I looked at one of my 11.11 systems on which my latest 'pax' patch is PHCO_32438 --- the immediate predecessor of PHCO_35998.

This is what I see on my server:

# show_patches|grep -i pax
PHCO_32438 pax(1) cumulative patch

# show_patches -a -s|grep -i pax
PHCO_32438 pax(1) cumulative patch
PHCO_28414 pax(1M) cumulative patch
PHCO_30420 pax(1M) cumulative patch

swlist -l patch|grep -i pax
# PHCO_32438 1.0 pax(1) cumulative patch

# swlist -l patch -x show_superseded_patches=true|grep -i pax
# PHCO_28414 1.0 pax(1M) cumulative patch
# PHCO_30420 1.0 pax(1M) cumulative patch
# PHCO_32438 1.0 pax(1) cumulative patch

So, using 'show_patches' without options yielded only the "active" patches just like the default 'swlist'. Adding the options to 'show_patches' to see both active and superseded patches yielded what I would expect too, just as adding that option to 'swlist' did.

Check your '/var/adm/sw/defaults' and/or your '${HOME}/.sw/defaults' [if present] for any 'swlist' option settings. This may be the reason for your observations.

To tie this to our earlier dialog, on my server I can also see:

# swlist -a date -a patch_state -x show_superseded_patches=true PHCO_32438
# PHCO_32438 Fri Aug 26 10:56:13 EDT 2005
PHCO_32438.UX-CORE Fri Aug 26 10:56:13 EDT 2005 committed

...which shows me that I installed this patch on August 26, 2005. I recently *forced* a commit of a patch baseline in preparation for application of the June 2007 QPK, hence this patch state is now "committed".

The predecessor patch, PHCO_30420 shows:

# PHCO_30420 Wed Feb 23 13:36:28 EST 2005
PHCO_30420.UX-CORE Wed Feb 23 13:36:28 EST 2005 committed/superseded

...which clearly has been superseded.

Another view can be obtained thusly:

# swlist -l fileset -a supersedes PHCO_32438
# PHCO_32438
PHCO_32438.UX-CORE PHCO_25393.UX-CORE,fr=* PHCO_26422.UX-CO
RE,fr=* PHCO_28414.UX-CORE,fr=* PHCO_30420.UX-CORE,fr=*

...which shows me the entire 'pax' patch chain. It so happens that PHCO_28414 is the *earliest* version on *my* server:

# swlist -a date -a patch_state -x show_superseded_patches=true PHCO_28414
# PHCO_28414 Thu Jan 29 13:08:56 EST 2004
PHCO_28414.UX-CORE Thu Jan 29 13:08:56 EST 2004 committed/superseded

...I know this because neither PHCO_26422 nor its predecessor PHCO_25393 are available. Also, I know from my manual server logs, that this server was originally cold-installed by me in January 2004.

Lastly, if a patch is "commited", it means that its rollback files (the previous patch's state) have been removed from the system, or as I noted, that the patch was installed *without* saving rollback information [ using '-x patch_save_files=false' --- which is not a good way to patch ].

The 'cleanup' utility allows you to commit patches that have been superseded a specified number of times. This leaves some level of rollback.

An alternative is if you have a stable system that has been running a baseline of patches for a reasonable time without problems (I like ~ 6-months). In that case, you may wish to commit all patches before applying a QPK bundle. This has some benefits and can be done with:

# swmodify -x patch_commit=true \*

This can also be done for *individual* patches (for example):

# swmodify -x patch_commit=true PHCO_32438

Regards!

...JRF...

[Steven E. Protter]

Shalom,

Simple answer is just because its a pax patch does not mean one supersedes the other.

There can be two different pax patchs that deal with different problems.

SEP

[James R. Ferguson]

Hi (again):

> Steven: Simple answer is just because its a pax patch does not mean one supersedes the other. There can be two different pax patchs that deal with different problems.

Well, no cigar for that. Mike was very clear in his opening post that he installed PHCO_35998 and had PHCO_32438 previously installed and now "can see both versions".

Consult the ITRC patch database and you see that PHCO_35998 is immediately superceded by PHCO_32438 or search the patch database for 11.11 patches matching "pax" and you will *only* find PHCO_35998 returned as a recommended/most recent entity. That makes it clear to me that were dealing with evolving versions of one "patch".

Regards!

...JRF...

[Dennis Handly]

>SEP: Simple answer is just because its a pax patch does not mean one supersedes the other. There can be two different pax patches that deal with different problems.

No, the simple answer is that if they are pax(1) patches they are related. The patch policies don't allow patches that aren't cumulative and since PHCO_25393 has all of the pax files, there can't be any divergent patch trees for that OS version. Any other way would be confusing to customers.

>JRF: Well, no cigar for that.

Well, yes but not because of what Mike said.

>Consult the ITRC patch database and you see...
>That makes it clear to me that were dealing with evolving versions of one "patch".

Right, this shows the whole patch tree:
http://www1.itrc.hp.com/service/patch/patchTree.do?patchid=PHCO_25393