Error installing patch stating not enough space in root

[TWBSupport]

I need a way around this error. I must install the Gold patch for an oracle upgrade. When I try installing the Gold patch, it fails the pre-test due to not enough space in root. We are at 90% in root, but have been there for the last 2 1/2 years, so it really is not a big problem for operating, just installing this darn patch. Is there any way to install this patch whereas it doesn't need more space in root? This server runs 24/7 w/no maintenance time, so I'm allowed a bounce every once in a while, but that is about it.
OS = 11i

[Pete Randall]

The question to me is: why is / at 90%? What is really taking all that room? Run "du -sk /* |sort -n" to get a listing of the biggest consumers. You'll need to weed out the FS mount points and then take a look at where all your / space is being consumed. Are there core files in there? Regular files in /dev? Big files in /root or wherever root's home directory is?


Pete

[Luk Vandenbussche]

Look for bigfiles in / with the command

find / -size +100000 -xdev

[Geoff Wild · Accepted solution]

Or, if possible, increase /

Here's how to do it live:

Not for the faint of heart.

No outage required , if you have online jfs.
If you do not have online jfs , do all the following in LVM maintenance mode.
Note: this will only work if SWAP is NOT the next lvol after /

a. Login as root.
b. Find out a free disk or un mirror the rootvg and make that disk free.
c. find out the next logical volume after lvol3(assumed lvol3 is root)
d. pvmove that logical volume onto the newly added disk
[ pvmove -n /dev/vg00/lvol4 /dev/dsk/CURRENT /dev/dsk/NEW]
e. now you should be able to increase root filesystem to an additional `size_of_the_lvol4`.
f. pvmove the lvol4 back to root vg ( vg00)

boot,swap and root are the only lvols that needs a contegeous policy. so , it does not matter where lvol4 is.

Example, move lvol4 away from lvol3 , thus creating a contegeous space right after lvol3. If you need more space on "/" you will be able to move lvol5 ...6 to the next disk and do the stuff. Do remember to migrate them back to the original disk.

Now, if you have mirrored root vg, then break the mirror before you do this.


Practical Example (actual test)

# bdf |grep vg00
/dev/vg00/lvol3 204800 151616 53184 74% /
/dev/vg00/lvol1 125808 49064 64160 43% /stand
/dev/vg00/lvol7 4194304 2501208 1680472 60% /var
/dev/vg00/lvol6 3145728 1856304 1279456 59% /usr
/dev/vg00/lvol5 524288 160992 361104 31% /tmp
/dev/vg00/lvol4 2097152 1833496 261656 88% /opt
/dev/vg00/lvol8 1048576 622656 422632 60% /home
/dev/vg00/lvol10 2097152 1270980 774595 62% /app


Find a spare disk:

strings /etc/lvmtab |grep c7t0d6
pvcreate -f /dev/rdsk/c7t0d6
vgextend /dev/vg00 /dev/dsk/c7t0d6
lvdisplay -v /dev/vg00/lvol4 |more
lvreduce -m 0 /dev/vg00/lvol4
lvdisplay -v /dev/vg00/lvol4 |more
pvmove -n /dev/vg00/lvol4 /dev/dsk/c0t6d0 /dev/dsk/c7t0d6


lvreduce -m 0 /dev/vg00/lvol3
lvextend -L 1024 /dev/vg00/lvol3
fsadm -b 1024M /

pvmove -n /dev/vg00/lvol4 /dev/dsk/c7t0d6 /dev/dsk/c0t6d0
vgreduce /dev/vg00 /dev/dsk/c7t0d6


lvextend -m 1 /dev/vg00/lvol3
lvextend -m 1 /dev/vg00/lvol4


# bdf |grep vg00
/dev/vg00/lvol3 1048576 151640 890456 15% /
/dev/vg00/lvol1 125808 49064 64160 43% /stand
/dev/vg00/lvol7 4194304 2506048 1675672 60% /var
/dev/vg00/lvol6 3145728 1856304 1279456 59% /usr
/dev/vg00/lvol5 524288 160992 361104 31% /tmp
/dev/vg00/lvol4 2097152 1833552 261600 88% /opt
/dev/vg00/lvol8 1048576 622656 422632 60% /home
/dev/vg00/lvol10 2097152 1270980 774595 62% /app


Rgds...Geoff

[TWBSupport]

There are no big files in root, already checked that. After just installation 5 years ago, root was at 86% (accepted default 200mb, when I shouldn't have. lesson learned now).

[TWBSupport]

Thanks for the info Geoff, but in order to extend root, I would need considerable amount of downtime. This is a production server and I am not allowed downtime. Yes, I know crappy environment, but it's the reality of the exec's decisions. They would rather play the dice than be safe.

[TWBSupport]

I forgot to add Geoff, we don't have onlineJFS. Asked for it 3 years ago and was laughed at because of the cost.

[TWBSupport]

I'm sorry Geoff, I just reread your suggestion. I have to admit, I don't have a warm and fuzzy feeling about doing it live. What exactly is LVM maintenance mode? Maybe that is a stupid question, but I usually just type the commands or use SAM to perform the tasks. Is there a specific mode that I can put the system in to be a tad safer in doing this?

[Geoff Wild]

Ah - without onlinejfs - you are hosed.

You will need an outage - a perfect example of why the cost for onlinejfs is worth it - any server that is required to be 24/7 should have OnlineJFS - else they are kidding themselves.

lvm maintenace mode is an outage - basically, you boot, interact with IPL, and enter
hpux -lm

The you can use extendfs, etc to change your lvol sizes...

The other way without onlinjfs is to use ignite - and resize your space - again - another rather long outage....

If I were you, I would take this as an opportunity to justify the cost of OnlineJFS.

Rgds...Geoff

[Sp4admin]

The only way to complete your task is like Geoff said. I think you will need to use the ignite approach to achive this. This may be a good time to justify why online jfs is needed.

sp,

[Dennis Handly]

You might be able to move large directories off them put them back. Or have a symlink to another filesystem.

The big directories in /var/adm/sw/save?
(I have 1.5 Gb in one system.)