[help]can I remove the *.prev from the /stand ?[help]

[zhangr_2]

I need to add some patch to the server,but the system said,not enough space in /stand. so I just check the /stand and found some file like *.prev . can I remove this kind of file to release some disk space? thanks .

[Denver Osborn · Accepted solution]

yes you can move aside the vmunix.prev to make enough room for this patch install to build a new kernel. As long as everything goes well you shouldn't have anything to worry about. After the install and once the box is back up you'll notice the previous kernel will now be vmunix.prev.

Hope this helps,
-denver

[Con O'Kelly]

I'm presuming you mean vmunix.prev.
The patch probably requires a kernel rebuild so will generate a new vmunix.prev, hence you can remove it.
I'd be a little concerned if your /stand is this full and you need to do this.
What does bdf /stand show??

Cheers
Con

[zhangr_2]

thank you very much. 8-)

[T G Manikandan]

*.prev files are used when the system has a problem of booting through the existing kernel.

you can boot through the old kernel using .prev files

Just do a
#du -k /stand|sort -nr|more

Finding any large files there

Just would suggest to increase /stand.
YOu can do that using IGNITE.

Thanks

[twang]

yes, you can remove it, but I would suggest you to extend /stand, you can make a ignite tape for vg00 and resize /stand by using the tape to boot your system.

[Steven E. Protter]

I would not recommend it.

If you remove vmunux.prev and something goes wrong, even corruption(not likely but who knows) you have no way to boot the system back to the previous kernel.

If space is REALLY short, you can store the kernel on a vxfs filesystem, but you can't boot off a vxfs filesystem. To reocvery off the alternate kernel,you'd first need to boot off the install cd and move the vmunix.prev into /stand

Your best be in these circumstances is to do this:

make_tape_recovery make a backup of vg00

Boot the box

Interupt at the 10 second prompt

sea

bo p#

replace # with the number of the sequential(tape) device.

N Do not interact.

Ignite will boot and then give you a chance to intervene manually. Do so, and add space to the /stand filesystem. If /var and /tmp have been short of space, make them bigger. root should have a bit of room too to handle mistakes.

If you have more then two copes of vmunix, then some removal should be possible. Check the dates and proceed with caution.
SEP

[zhangr_2]

oh! thank you all very.
for my poor English,I can't express my appreciate . anyway ,all your reply make me got more understanding in this issue.
thank you all again. 8-)

[Con O'Kelly]

Actually Stephen makes a good point.Under normal circumstances you should not remove vmunix.prev.
However if a new kernel is being generated through swinstall after a patch install, then this will create a new vmunix.prev.
Not exactly sure how it works but I'm assuming the analysis stage has checked the size of /stand & see's that it doesn't have enough space to create a vmunix.prev. It probably doesn't have the intelligence (or does it?) to realise that a vmunix.prev already exists in /stand. Hence it will have enough space to create vmunix.prev as it will overwrite the old one (usually the size difference is minimal).

That was my assumption in this instance, hence why I see no problem in removing vmunix.prev.
The other issue of course is that space shouldn't be that tight in /stand.

If I'm missing something, pleaee let me know.

Cheers
Con