[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: signal 11 on fsck

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]