Operating System - HP-UX
1835894 Members
2945 Online
110086 Solutions
New Discussion

Re: make_recovery failure

 
SOLVED
Go to solution
Cliff Peters
Occasional Advisor

make_recovery failure

All,

I amended a scripted make_recovery command by making it a no-rewind device. The command subsequently failed as it added an extra n to the device.
I have now discovered that / has filled up to 100% used.
What , besides a lot of /dev tun* devices , do I need to delete to get back to the normal 76% ??
The error was:
make_recover(472):/usr/bin/dd failed,res-512,errno=9


Thanks
Cliff

6 REPLIES 6
Robert-Jan Goossens
Honored Contributor
Solution

Re: make_recovery failure

Hi,

# cd /dev/
# find . -type file -size +1000
# ls -la file
# rm file

Robert-Jan.
Steven E. Protter
Exalted Contributor

Re: make_recovery failure

If post 1 doesn not help you could have steal file(s).

What this is are files hidden by a mounted filesystem.

Lets say you store a 50 Meg download on a folder called /download, which is part of the root fs.

You decide later to have a mounted filesystem called /download and you mount /download

That 50 Megabyte download is still there but it doesn't show up on an ls -la

Its takeing up 50 Meg on root and its invisible.
In order to clean this out, you have to umount /download and delete it.

I had a system that failed to mount the /var filesystem at boot one day. Some logs continued to get written in the root fs.

The machine was booted again and sucessfully mounted /var

I kept wondering why root was so full, until I went into single user mode and ran the command in post 1.

Just a little extra to think about.

Good Luck,

SEP
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
john korterman
Honored Contributor

Re: make_recovery failure

Hi Cliff,
you could start looking for the non-existing device file, the one with the extra "n" appended; this file probably exists now and holds a lot of useless data.
Just a guess....

regards,
John K.
it would be nice if you always got a second chance
Steven E. Protter
Exalted Contributor

Re: make_recovery failure

Correction to reply 1's find command.

find . -type f -size +1000

file isn't a valid type on 11.00 f means file.

SEP
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
john korterman
Honored Contributor

Re: make_recovery failure

Hi,
if you can remember when the ignite session ran, then try searching for files that have changed since - not that this will pin-point only a few "guilty" files, as many files have been written in the meantime, but you could give it a try.
Example:
If the backup was created May 11, 2003 at 12:15 hours, create this file:
# touch -t 0305111215 /tmp/fupfile

Then search for files in the root directory changed after that time and display their sizes:
# find / -xdev -newer /tmp/fupfile -exec ls -l {} \;

As mentioned, you will see a lot of files, but some of them must be relevant.

regards,
John K.


it would be nice if you always got a second chance
Cliff Peters
Occasional Advisor

Re: make_recovery failure

Thanks everyone. A lot of useful info. Problem solved by deleting huge invalid device files from /dev.

Thanks again
Cliff