A few weeks ago I ran updatemanager to patch a Sun X4500 'Thumper' running Solaris 10/x86. I got an error -- there was not enough space in /var for all the relevant patches.

When I started working on Solaris 8, SOP was to make /var 2gb. When I installed Solaris 10 here, I made /var 4gb, thinking this would be plenty. Unfortunately it was inadequate -- 4gb is not enough for a "Solaris 10 10/08 s10x_u6wos_07b X86" system which hasn't been patched recently. Yowch! I had 3gb in /var/sadm/pkg (patch residue) and the system wanted to fetch an additional 3gb of patches to install in /var/sadm/spool. So clearly /var needs to be larger than 6gb, but how large should it be?

I asked at least 4 different Sun reps how large /var ought to be, and none of them had an answer -- a few told me that, as far as they are able to determine, Sun does not have any guidance on how large /var should be. I asked some friends what they do, and was surprised to discover that they make /var 10gb. Solaris 10 needs 10gb for patch residue & temp space? That's insane! Not that they are wrong -- I eventually repartitioned the server to make /var 16gb (I do not want to go through this again), and /var/sadm currently occupies 5.7gb!

The Solaris installer has some built-in minima for partitioning, but the /var requirement is an absurd 204mb -- presumably for systems which will never be patched. I'll add it to the S10 installer buglist

Solaris 10 installer: /var


Under Solaris 8, when /var ran out of space, we either repartitioned the system (always a bit risky), or made /var/sadm a symlink to space on another partition with adequate free space -- which must, of course, be available in single-user mode for single-user patches to install successfully. In Solaris 10, though, patches refuse to install if /var/sadm/pkg is a symlink.

# smpatch update
141529-01 has been validated.
141559-01 has been validated.
141883-01 has been validated.
142435-01 has been validated.
141877-05 has been validated.
Installing patches from /var/sadm/spool...
Failed to install patch 141529-01.

Utility used to install the update failed  with exit code 5.
Checking installed patches...Patch 141529-01 failed to install due to a failure produced by pkgadd.See /var/sadm/patch/141529-01/log for detailsPatchadd is terminating.
Transition old-style patching.Directory is expected, found link - //var/sadm/pkg.Cannot open input /
Failed to install patch 141529-01.
Dec  7 09:51:00 thumper root: [ID 702911 user.alert]  => com.sun.patchpro.util.PatchBundleInstaller@11d2572 <=Failed to install patch 141529-01.
ALERT: Failed to install patch 141529-01.
Failed to install patch 121264-01.

Utility used to install the update failed  with exit code 5.
Checking installed patches...Patch 121264-01 failed to install due to a failure produced by pkgadd.See /var/sadm/patch/121264-01/log for detailsPatchadd is terminating.
Transition old-style patching.Directory is expected, found link - //var/sadm/pkg.Cannot open input /
Dec  7 09:51:01 thumper root: [ID 702911 user.alert]  => com.sun.patchpro.util.PatchBundleInstaller@11d2572 <=Failed to install patch 121264-01.

One rep recommended I work around the lack of space in /var by using smpatch set to move the pkg & spool directories to another filesystem with free space. Unfortunately, with these settings, both smpatch and updatemanager suddenly claimed there were no patches to install. I used:

smpatch set patchpro.backout.directory=/export/home/sadm/pkg
smpatch set patchpro.download.directory=/export/home/sadm/spool
smpatch set patchpro.baseline.directory=/export/home/sadm/spool

I have been asking about this bug in smpatch for a couple weeks, but haven't gotten any response.

Sun's other suggestion was to remove patch 'undo' or 'backout' information, but this forecloses future options, so I didn't pursue it. The details (which require an active contract/warranty to see) are at http://sunsolve.sun.com/search/document.do?assetkey=1-61-208057-1.


So, kiddies, if you are making /var its own filesystem in Solaris 10, it had better be at least 10gb. Unfortunately, Sun hasn't figured this out yet, and in fact doesn't appear to understand the problem.

Every Sun rep I speak to says "Just repartition the server." as if that was no big deal. I shouldn't have to repartition the server. Sun should be warning users about this. The Solaris installer should warn users if /var isn't large enough (the current minimum is a poor joke). If /var is too small, it should be easy to work around! Why is Solaris so hung up on where it reads patches from?

A Solaris developer actually wrote code to detect symlinks and refuse to run with the old workaround, so is it too much to expect the official workaround (smpatch set) to actually work?