Original Posting:
I ran fsirand on one of our Sun (OS 4.1.4) and when I tried to
reboot, fsck failed. I had to run fsck with the alternate super
block (-b 32) in order for fsck to run clean.
However, we still seems to be having problem with fsck; it is
claiming that the superblock is wrong.
Has anyone else experience this? Does anyone know what is wrong
or how to fix this?
Please send all response to monawong@ucsd.edu and I will post a
summary.
>From David Moline <drm@gcs.oz.au>:
I don't know if this is the case, but I have seen similar
problems when partitions overlap.
>From Kevin.Sheehan@uniq.com.au (Kevin Sheehan):
fsirand has to be run with the FS unmounted.
>From tybse2!cbarker@postman.eglin.af.mil (Craig Barker):
After you performed your initial fsck with the alternate
superblock (-b 32), you needed to do a "boot -n". If you
were to perform a standard reboot, or boot, then the original
corrupted superblock table is rewritten to boot prom and the
system will try to come up as before. When you perform a
"boot -n" or "reboot -n", then this tells the system not to
sync and re-write the new superblock/bootblock to the prom.
Then the system will come up using the new tables and you
should be fine!
>From pallan@clare.risley.aeat.co.uk (peter.allan@aeat.co.uk):
Before receiving your first fsirand question I had only ever run
the thing as part of newfs.
Now I have also run it on an unmounted filesystem (4.1.1 RevB +
patch 100343-06)there is no detectable problem. I have fsck'ed it
twice.
I'd expect newfs to fix it if you are happy with your backup.
>From carlo@hub.eng.wayne.edu (Carlo Musante):
You can get alternate super blocks by using the newfs -vN /dev/rsdxx.
I have found that if super block 32 is corrupt that the partition is
usually corrupt. That is you may be able to retrieve some of the
data but not all of it. You can use the alternate super blocks to
fix as much of the damage as possible, then recover any data which
may not be backed up. Eventually you will need to newfs the
partition and restore the rest of the data from a backup.
>From Al.Venz@seag.fingerhut.com (Al Venz):
If you do a "newfs -Nv <device>" it will give you a list of the
superblocks without actually doing anything to the device. This
will allow you to see what superblocks are available.
>From dan@bellcore.com (Daniel Strick):
I am not familiar with your particular problem, but I have seen fsck
consistently fail to rewrite superblocks on occasion. My workaround
has been to dump/restore the file system.
>From mdavis@lcsgold.litton.com (Mark A. Davis-LCS):
You should not need to run fsirand manually. When installing a new
disk, use the newfs command, this will run the fsirand for you. You
can see that newfs does the fsirand if you monitor running processes
while running the newfs.
Thanks to all those who responded!
Mona Wong
UCSD
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:34 CDT