extending /stand

[Steven E. Protter]

Shalom,

Yes it will work.

But lets cut to the question? Why do you need to extend /stand ?

All that is supposed to be kept there is the kernel and the files needed to built it.

I've not once in 11 years needed more space for that file system than the default.

Are you sure you don't have stuff that does not belong?

SEP

[Chris Fadrowski]

it's an older system running 11.23 v2 and need to install the latest patch set from HP. When trying to install, it says /stand will be out of room to build the kernel.

[Ganesan R]

Hi,

What is the current size of /stand file system?

Use the below command to find which dir consumes more space.

#du -xk /stand |sort -nr |head -20

look into the top space consuming directories and try to clean if any unwanted files.

To list the top 10 large files in /stand filesystem,

# find /stand -xdev -type f -print | xargs ls -an | sort -nr -k 5 | head -10

[Jeff Schussele]

Yep - I've seen that.
vmunix has become a pig as well as its support files.
Like I said - You'll need to do a make_recovery style backup & rebuild the root/boot disk & this time double the /stand size...Lord knows what HP will do to /stand *next* time.

Rgds,
Jeff

[Chris Fadrowski]

root@host1:/var/opt/ignite/recovery>du -xk /stand |sort -nr |head -20
239360 /stand
68624 /stand/crashconfig
64256 /stand/current
64256 /stand/backup
42136 /stand/last_install
5456 /stand/crashconfig/mod
552 /stand/current/mod
552 /stand/backup/mod
272 /stand/last_install/mod
240 /stand/crashconfig/krs
224 /stand/current/krs
224 /stand/backup/krs
80 /stand/last_install/krs
16 /stand/krs
8 /stand/current/bootfs/stand/current/mod
8 /stand/current/bootfs/stand/current
8 /stand/current/bootfs/stand
8 /stand/current/bootfs
8 /stand/crashconfig/bootfs/stand/current/mod
8 /stand/crashconfig/bootfs/stand/current

[TTr]

Take a look at http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=&threadId=1290089 regarding /stand/crashconfig. You could get away with deleting its contents. But /stand is kind of small, if you can afford the downtime you should go through the make_recovery and re-ignite the server.

[Pete Randall]

Chris,

It looks to me like you have 3 or 4 different versions of your kernel configurations saved via the kconfig command. Try running "kconfig -v" to see all the information about these versions. This may help you identify, and maybe eliminate one or more of them. Also do a man on kconfig for further info on the concept and use.


Pete

[Chris Fadrowski]

i have 3 versions. i think i could get rid of one of these

root@host1:/var/opt/ignite/recovery>kconfig -v
Configuration backup
Title Automatic Backup
Save Time Fri Jan 23 09:25:05 2009
Modify Time Fri Jan 23 09:25:05 2009
Kernel Path /stand/backup/vmunix

Configuration crashconfig
Title booted from 'import.config'
Save Time Tue May 15 06:30:15 2007
Modify Time Mon Jun 18 08:02:44 2007
Kernel Path /stand/crashconfig/vmunix

Configuration last_install
Title Created by last OS install
Save Time Wed Sep 8 11:38:43 2004
Modify Time Wed Sep 8 11:38:43 2004
Kernel Path /stand/last_install/vmunix



what do you suggest?

[Avinash20]

Please execute # kconfig to check is we have any backup kernels in /stand which can be deleted

[Chris Fadrowski]

root@host1:/var/opt/ignite/recovery>kconfig
Configuration Title
backup Automatic Backup
crashconfig booted from 'import.config'
last_install Created by last OS install