Adding Patches - /var fills up and the patch process fails

[Jane F Lewicke]

In adding the patches required to move to Oracle 9i we need to add some patches to HP-UX 11 to be ready for the Oracle upgrade.

Bundled the patches and downloaded the tar. Since there wsn't enough room in the /tmp/patches directory we created another directory and linke to the /var/patches directory to create the required depot.

When running:
create_depot_hp-ux_11 -d/tmp/patches/depot
the /var directory fills up and the create _depot starts sending errros.

Thanks,
Jane Lewicke

[Tim Adamson_1 · Accepted solution]

Hi Jane,

You can download all the patches into a single directory, unshar them, swcopy them to a single depot and then install them.

You can use any directory you like. Have a look at the attached document and make any adjustments necessary (such as location of patches and resultant depot).


Tim

[Jeff Schussele]

Hi Jane,

This is a common patching problem even when the depot is remote. You'll need to either trim /var or extend it.

Trim:
1) cd /var
du -akx | sort -nr | more
This will show you the largest space hogs in /var. Find the culprits..logs..old superseded patches, etc. You can commit earlier patches superseded twice with
cleanup -c -2 #add a -p for preview
Look for PerfData logs to be trimmed in /var/opt/perf/datafiles, look in /var/opt/stm for the same reasons. And don't neglect /var/tmp - *anything* in a *tmp dir is fair game.

Extend:
Do a
vgdisplay /vg00
If you have free space AND you have OnLine JFS, you can grow /var on-the-fly using
lvextend -L XXXX /dev/vg_name/lv_name # where XXXX=the NEW size in MB
and
fsadm -F vxfs -B XXXXM /var # where XXXX=New MB size
If you don't have free space you'll have to be much more aggressive in trimming or wait until you can *physically* add space.

Biggest piece of advice I can give you is:
"Don't use /var to store patches to load".

HTH,
Jeff

[twang]

You could check to see if you can remove superseded patches.

# cleanup -p -c 1

And if you do not want have your 'crash' files analyzed, then, you can remove them(/var/adm/crash).

[Charles Holland]

Jane,
As the first person indicated. It doesn't have to be in /var. It doesn't even have to be in the vg00 volume group. In vg01 we have a directory called "hp_patches" with 5GB of space. We get put our tar file in it and follow the procedures outlined in the README file. Works fine.
To install
swinstall -s /hp_patches/bundle.depot.

[doug mielke]

As Jeff mentioned, a cleanup might be enough to get out of this, and if Online JFS, you can extend /var.

If not, /var may be difficult to extend while system is up. Many products put themselves there, and files are in use after boot, preventing unmounting when you try to extend.

You may need to go to single user to extend, and use command line LVM.

[GK_5]

Jane,

Run cleanup to remove superseded patches. This will make room in /var

[Bill Hassell]

/var is a very critical directory that virtually every process may use. It should be very large (several Gb if necessary) so there will be plenty of room for patches, logfiles, email, spooling, etc. Always have hundreds of megs of free space available before starting a patch session:

bdf /var

[Jane F Lewicke]

Thank you all,

We cleaned the system and found sufficient space to apply the patches.

Now if you have a method to get the users off the system to allow application of the patches during somewhat normal hours -- that would be great -- -Power outages don't count -- ups doesn't have enough capacity to last through them all!