1833323 Members
3265 Online
110051 Solutions
New Discussion

vmunix.prev question

 
SOLVED
Go to solution
Chris Fadrowski
Super Advisor

vmunix.prev question

my / directory is at 100%. i am looking for things to delete until i have time to extend it (using MR). Can i get rid of vmunix.prev? i know it's the previous kernel, but i have few good make_recovery tapes. What is the harm in deleting this for space in this instance. This is a b180 running 11.0 controlling a v class (2500)
9 REPLIES 9
A. Clay Stephenson
Acclaimed Contributor

Re: vmunix.prev question

vmunix.prev should be in /stand so it's not going to help. If this is /stand, you can delete vmunix.prev - yoou seem to know the risks.
If this is /, I would look under /dev for regular files - especially in /dev/rmt.
If it ain't broke, I can fix that.
Pete Randall
Outstanding Contributor

Re: vmunix.prev question

Chris,

If you're comfortable with your current kernel, that is you've booted successfully off it at least once, and have it backed up. I don't see any problem at all.

One question though - what is MR and how are you going to expand / with it?

Pete

Pete
Jeff Schussele
Honored Contributor
Solution

Re: vmunix.prev question

Hi Chris,

This wouldn't help you.
vmunix.prev is in the /stand FS. It's separate from /

Do this:

cd /
du -akx | sort -nr | more

This will list all files/dirs in / (only) & list them in descending order. This way you can tell where it's being used up easily. Probably have some junk in there that can be cleaned up.

HTH,
Jeff
PERSEVERANCE -- Remember, whatever does not kill you only makes you stronger!
Pete Randall
Outstanding Contributor

Re: vmunix.prev question

Chris,

Your best bet, other than finding some space to free up,
is to make an ignite backup tape (with make_tape_recovery) and using that to restore your system, enlarging in the process.

Pete

Pete
Steven E. Protter
Exalted Contributor

Re: vmunix.prev question

If you are feeling lucky, vmunix.prev can be temporarily stored on a vxfs fs.

But, you can't boot off of it until you put it back.

P
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Chris Fadrowski
Super Advisor

Re: vmunix.prev question

i'm sorry it's actually in /stand. 100% . i have booted off of this kernel a few times.

MR = Make_recovery

you can extend / by doing a make_recovery -A -p (preview)

then edit the config.recover file. (you change the size of the lvol) and then start up make_recovery -r (resume). Then you can boot from this MR tape and it will install your lvol's to the size you edited.
Pete Randall
Outstanding Contributor

Re: vmunix.prev question

Chris,

Gotcha - it's in /stand. And you've booted off the current. Blow it away. That should get you by until your expansion.

(after I asked about MR, I finally figured out you probably meant make_recover - there's a newer version of ignite that uses the command make_tape_recovery - you'd be well off to get hold of the latest).

Good luck,
Pete

Pete
Chris Fadrowski
Super Advisor

Re: vmunix.prev question

actually, i am running the latest versions of MR and it is make_tape_recovery. I have been using it for so long that i always revert to make_recovery. sorry about that.
Bill Hassell
Honored Contributor

Re: vmunix.prev question

So vmunix.prev is found with: ll /vmunix.prev? Then it is a useless file in the / directory unless (and it can be done but NEVER recommended) /stand is part of the / filesystem. To test this, just type:

bdf /stand

and if it does NOT report /stand in the right column but says /, then you do not have /stand and have a non-standard system. I would look to a maintenance window where you can reinstall from your latest make_tape_recovery tapes and create the /stand directory.

If vmunix.prev is indeed in / and /stand is a separately mounted filesystem, remove vmunix.prev. However, I doubt that will make a lot of difference. / fills up due to mistakes and should only need 35 to 55 megs of space occupied. Run this command:

du -kx / | sort -rn | head

You will see the largest directories. If /dev is at the top, you've got a big mistake in /dev, probably /dev/rmt, a file called om that is very large. Or you have (bad) applications that insist on installing in the / directory. Move them to /opt where they belong.


Bill Hassell, sysadmin