On Thu, Oct 24, 2002 at 10:00:54AM -0600, Marius Zydyk wrote: > The problem: > ------------ > [root@angel root]# fsck -V -t ext3 /dev/hdg1 > fsck 1.26 (3-Feb-2002) > [/sbin/fsck.ext3 (1) -- /dev/hdg1] fsck.ext3 /dev/hdg1 > e2fsck 1.26 (3-Feb-2002) > Warning... fsck.ext3 for device /dev/hdg1 exited with signal 11. > > [root@angel root]# fsck.ext3 -V > e2fsck 1.26 (3-Feb-2002) > Using EXT2FS Library version 1.26, 3-Feb-2002 > > [root@angel root]# fsck.ext3 /dev/hdg1 > e2fsck 1.26 (3-Feb-2002) > Segmentation fault > > Trying to mount the file system: > -------------------------------- > [root@angel root]# mount /dev/hdg1 > mount: wrong fs type, bad option, bad superblock on /dev/hdg1, > or too many mounted file systems > > tune2fs is able to get the partition info, and it LOOKS correct to me (at > least it matches the other, working, drives). If the details from tune2fs > would help I can forward them as well. Hmm... what does dumpe2fs report? One other thing that might be wrong is that the e2fsck binary or the ext2fs shared libraries itself might have gotten corrupted. > Anything I can do to get the data back and recover the partition? In a > pinch I could stitch together some disk space to copy the partition > contents somewhere and blow it away, then put it back, would that help > anything? (a relative newbie here, sorry if that's a dumb question...) It really depends on why e2fsck is faulting. It's happening very early --- even before the pass 1 header is printing. So that could be because e2fsck or one of its dependent shared libraries is corrupted. It's also vaguely possible that a completely broken ext2/3 superblock is causing e2fsck to core dump. But e2fsck is pretty paranoid about checking data values before depending on them, and I've never seen a report like this before. So while it's possible, it doesn't seem likely... If it *is* due to a really broken superblock, "e2fsck -b 32768 -B 4096 /dev/hdg1" (assuming a filesystem using a 4k block size) or "e2fsck -b 8193 -B 1024 /dev/hdg1" (assuming a filesystem using a 1k block size). Before you do that, though, can you run the command: dd if=/dev/hdg1 bs=1k count=128k | gzip -9 > /tmp/hdg1.sb.gz And send me the resulting file (either uuencoded or as a MIME attachent)? That way, if it *is* due to a bogus superblock, I can figure out why e2fsck might be core-dumping. Thanks!! - Ted _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users
