Patch rollback and commitment

Patch rollback

You might occasionally want to remove a patch and restore the system to its prepatched state. This process is known as patch rollback. For example, if you installed a patch that resulted in unacceptable system behavior, you might choose to roll back this patch. However, rollback is possible only if certain files were saved as part of the patch installation process. During patch installation, the default behavior is to save copies of all files that are replaced by the new patch before the new versions of these files are loaded. These saved files are called rollback files and are the key to making patch rollback possible. When you roll back a patch, these rollback files are restored to the system. You should override the default behavior only if you have a complete understanding of the patch rollback process.

You cannot roll back a patch unless one of the following is true:

•Rollback files corresponding to the patch are available for reinstallation.

•Base software and the patch that modifies the software are removed at the same time (removing the base software also removes the patches associated with that software).

•For superseded patches, you must first roll back the superseding patch.

You can use the swremove command to roll back a patch (if no dependencies exist for the patch). Use the following command to roll back the patch patch_id:

swremove patch_id

As is true for many SD-UX commands, you can add the -poption to execute the command in preview-only mode. This mode allows you to view output from the command without actual changes occurring. You should initially execute the command in preview mode:

swremove -p patch_id

Advanced topic: patch installation and rollback files

When installing patches, you can explicitly specify that rollback files not be saved. To do this, you add the -x patch_save_files=false option to the swinstall command:

$ swinstall -s /tmp/temporary_depot/depot -x autoreboot=true \ -x patch_match_target=true x patch_save_files=false

Only use the false option if you will never remove a patch under any circumstances.

Patch commitment

Allowing for patch rollback does come at a cost, because the files required for patch rollback consume disk space. If disk space is an issue on a system, you can commit the patches; a process that deletes the associated rollback files, thereby freeing disk space. If disk space is not an issue on a system, you should avoid committing the patches, and leave rollback files in place. If any patch in a supersession chain is committed, all prior patches in the chain lose the ability to be restored, and the save area disk space for those patches will also be reclaimed.

Do not undertake patch commitment without serious consideration of the consequences. When you commit a patch, simple rollback of the patch is no longer possible. Because of this, you should carefully select which patches should be committed. Good candidates include patches that were thoroughly tested in the environment prior to installation, and patches that have been installed on the system for a significant period of time and have not resulted in unwarranted conditions. Other good candidates are patches that have been superseded multiple times. You should also consider a patch's warning status and its HP rating before committing the patch.

To commit an individual patch, execute the swmodify command on the patch with the patch_commit=true option. To commit the patch patch_id, enter this command:

swmodify -x patch_commit=true patch_id

You can add the -poption to this command so it will be executed in preview-only mode.

Patch rollback and commitment 33