The following is now published as Infodoc 208057:
To whom it may concern,
Over time, customers may experience space issues in /var as patch "undo" and "obsolete" data, which is stored for use during patch backout, builds up as more patches are applied to the system.
It is best to plan for this expansion of /var in advance, and allocate plenty of free space to this partition.
How much space to allocate to /var depends on a number of variables, such as how many patches are likely to be applied to the system, which is dependent on frequency of patching, strategy of which patches will be applied (all, sun alert, security only, etc.), products patched; whether the system has zones which implies 'pspool' space requirements, etc. A figure of 10Gb to 20Gb or even more is not unreasonable. In my Patch System Test lab, we currently have Solaris 10 systems with >7GB used in /var and this will continue to grow over the lifetime of Solaris 10.
If you have insufficient space in /var of an existing system, the recommended solution is to extend the size of the /var partition. This can be accomplished by backing up /var, creating a bigger /var partition on another disk, restoring the /var backup onto that partition and then updating the /var entry in the /etc/vfstab file. If /var is part of the "/" (root) partition, then relocating /var to a separate partition would be a good solution. The relocation process is documented in Infodoc 215988.
Sun strongly discourages manual modifications to the /var/sadm/pkg directory and its file structure. That directory structure should only be modified by the Solaris[TM] patching and packaging utilities. Corruption in this directory structure will prevent any future packaging or patching operations.
Below is information on how to free up space in /var by deleting
certain patch related files. This should only be used when there are
no other ways of gaining space in
/var.
Having a full and current backup of the OS is highly recommended before deleting files from /var.
On behalf of Sun Microsystems, I hereby confirm that unneeded "obsolete" and "undo" files may be removed from the /var/sadm/pkg/<pkgname>/save/<PatchID> and "undo" files from the /var/sadm/pkg/<pkgname>/save/pspool/<pkgname>/save/<PatchID> directories in order to free up space in /var.
This will not invalidate support contracts.
The "undo" files are used during the patch removal process. Removing the "undo" files associated with a patch means that it will no longer be possible to uninstall the patch.
Once a later revision of a patch is applied, or a patch which obsoletes a patch is applied, the "undo" files in /var/sadm/pkg/<pkgname>/save/<PatchID> are renamed "obsolete". These "obsolete" files may also be removed.
It is strongly recommended to only remove the
"obsolete" and "undo" files for patches which the
customer is confident will not need to be backed out - for example
rejuvenated Kernel patches associated with Solaris 10 Update releases
such as 118833-36 (SPARC) / 118855-36 (x86), 120011-14 (SPARC) /
120012-14 (x86), etc. and other older Kernel patch revisions. See the sequence of Solaris 10 Kernel PatchIDs listed on http://blogs.sun.com/patch/date/20080416
As patches containing subsequent fixes to the objects contained in these rejuvenated patches will have a SUNW_REQUIRES dependency on the these rejuvenated patches, it's extremely unlikely that older versions of these rejuventated Kernel patches will ever be backed out. Therefore, their "undo" files are prime candidates for removal to free up space in /var if required and it's not possible to extend /var.
All the "undo" or "obsolete" files for a particular patch should be removed from the /var/sadm/pkg/<pkgname>/save/<PatchID> directories. For example:
rm /var/sadm/pkg/*/save/118833-36/undo*
The system also keeps a copy of "undo" files for use during creation of new non-global zones. These may also be removed if the customer is confident that the patches will not need to be backed out. For example:
rm /var/sadm/pkg/*/save/pspool/*/save/118833-36/undo*
The "undo" files in the pspool directory are not renamed to "obsolete" when a later revision is installed.
Further Information:
-
The "undo" files are specific to the zone of the system on which they were created during application of a patch by patchadd. Therefore, do not copy the "undo" file from one zone to another or from one system to another.
-
One could potentially archive the "undo" files for each zone of a system and restore it to that zone if desired.
Best Wishes,
Gerry Haskins
Director, Software Patch Services