On Thu, Nov 30, 2000 at 03:55:42AM -0800, D. W. Piper <[EMAIL PROTECTED]> wrote:
| We had to reboot the system last night, and on restart fsck failed for
| the RAID device with the error message:
| Block bitmap for group 256 is not in group
| followed by
| /dev/rd/c0d2p1: Unexpected inconsistency, run fsck manually
| Running fsck manually produced the error message:
| e2fsck: bad magic number in superblock while trying to open
| /dev/rd/c0d2p1
| Trying again using e2fsck -B and varying block sizes of 1024, 2048, etc
| got:
| Group descriptor look bad... trying backup blocks
| e2fsck: bad magic number in superblock while trying to open
| /dev/rd/c0d2p1
Well...
I'd not fiddle with the -B option - the default blocksize should be
right (unless you've done something unusual) and lying may well confuse
things very badly.
The magic number warning means something trashed your superblock,
treading (at least) on the magic number used as a sanity check that
you're really fscking a filesystem and not random data.
Firstly, ensure your partition table is as you expect - if it's damaged
then /dev/rd/c0d1p1 may be pointing at the wrong area of the disc. If
the partition table is ok, you can proceed with more confidence.
Next thing is to try the alternate superblocks, kept as backup for just
this kind of trouble. Man e2fsck says these are at blocks 8193, 16385,
etc (8192*n+1). Try the -b (small "b"!) option with these numbers.
If this brings no joy your options start getting more dodgy.
WARNING: from here on the possibilities for irretrievable trashing your
data get much bigger.
CAVEAT: I have never used debugfs myself (just similar tools on other
filesystems, years ago). Try to find someone with experience who can
perhaps attend when you start playing with things. Always helps to have
a second pair of eyes to watch for typos and brainos with this kind of
thing.
THEREFORE:
take a complete backup of the filesystem in its damaged state, by dd'ing
the partition to a tape (or some other spare partition of sufficient
size if available - got a spare disc drive you can insert?):
dd if=/dev/rd/c0d2p1 of=/dev/your-tape-drive bs=32768
Afterwards, compare the tape against the filesystem before proceeding
(i.e. be sure you can undo things!)
Whip out the debugfs command (see "man debugfs") in read-only mode (the
default).
Make printouts of the e2fsck and debugfs manual entries and have them sitting
on the desk beside you.
See what debugfs makes of the filesystem. Try the
show_super_stats -h
command from inside debugfs. If things look awful:
- copy the superblock
dd if=/dev/rd/c0d2p1 bs=512 seek=1 count=1
of=backup-superblock-filename
That "bs=" _must_ match your fielsystem's blocksize.
If unsure, copy maybe the first meg of the fs:
dd if=/dev/rd/c0d2p1 bs=1024 count=1024 of=backup-of-1st-meg
- having copied things, you can then try the "initialize"
command from within debugfs. This sets up a superblock and block
descriptors. You give it a device (/dev/rd/c0d2p1) and a size.
WARNING: you're into serious damage area here - I do not know what
state your filesystem will be in after this: I've not done this. I
infer from the manual's terse description that this might get you a
semi-sane superblock from which fsck can do things.
So, having done that, try fsck on the filesystem (with the -n flag of
course) and see what it thinks.
| However, the DAC controller's consistency check completed at 100% with
| no errors, and the driver reported no problems during boot.
I'd take this to means merely that the drive is physically ok, which says
nothing about the consistency of the data on it.
How are your backups? (I presume missing or too out of date).
Cheers,
--
Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/
What's a pencil? Is that like a PDA stylus?
- [EMAIL PROTECTED] (Elizabeth Schwartz)
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
