Bug 997972

The bug is also present on Fedora 18:

e2fsprogs-1.42.5-1.fc18.x86_64

fsck from util-linux 2.22.2
/dev/loop0: recovering journal
fsck.ext4: Bad magic number in super-block while trying to re-open /dev/loop0
Signal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0x61
fsck.ext4[0x426f20]
/lib64/libc.so.6[0x35e5035cd0]
/lib64/libext2fs.so.2(ext2fs_mmp_stop+0x1c)[0x35e60237cc]
fsck.ext4(fatal_error+0x42)[0x41dc92]
fsck.ext4(e2fsck_run_ext3_journal+0x2d3)[0x41d1d3]
fsck.ext4(main+0x71e)[0x409a3e]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x35e5021a05]
fsck.ext4[0x40bc6d]

persists upstream too

Program received signal SIGSEGV, Segmentation fault.
ext2fs_mmp_stop (fs=0x67c3b0) at mmp.c:374
374		if (!(fs->super->s_feature_incompat & EXT4_FEATURE_INCOMPAT_MMP) ||
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.x86_64
(gdb) bt
#0  ext2fs_mmp_stop (fs=0x67c3b0) at mmp.c:374
#1  0x00000000004249ce in fatal_error (ctx=0x67c000, msg=<value optimized out>) at util.c:59
#2  0x0000000000423183 in e2fsck_run_ext3_journal (ctx=0x67c000) at journal.c:973
#3  0x0000000000410574 in main (argc=<value optimized out>, argv=<value optimized out>) at unix.c:1500
(gdb) p fs->super
$1 = (struct ext2_super_block *) 0x0

It's trying to stop the multiple mount protection crud, but there's no super set up (because of the bad magic number failure).

This avoids it, at least:

diff --git a/e2fsck/util.c b/e2fsck/util.c
index 9eaf557..18005f4 100644
--- a/e2fsck/util.c
+++ b/e2fsck/util.c
@@ -55,7 +55,7 @@ void fatal_error(e2fsck_t ctx, const char *msg)
 		fprintf (stderr, "e2fsck: %s\n", msg);
 	if (!fs)
 		goto out;
-	if (fs->io) {
+	if (fs->io && fs->super) {
 		ext2fs_mmp_stop(ctx->fs);
 		if (ctx->fs->io->magic == EXT2_ET_MAGIC_IO_CHANNEL)
 			io_channel_flush(ctx->fs->io);


but then you just get:

# e2fsck/e2fsck.static -fy test.img 
e2fsck 1.43-WIP (20-Jun-2013)
test.img: recovering journal
e2fsck/e2fsck.static: Bad magic number in super-block while trying to re-open test.img

test.img: ********** WARNING: Filesystem still has errors **********

and looking for a backup superblock doesn't work; replaying the journal seems to wipe them all out.

What the heck happened to this filesystem? :)  (mounting -o norecovery,ro yields a filesystem with no files in it)

Are you fuzz-testing here?

patch sent upstream:

http://marc.info/?l=linux-ext4&m=137667276009490&w=2

(In reply to Eric Sandeen from comment #4)
> 
> What the heck happened to this filesystem? :)  (mounting -o norecovery,ro
> yields a filesystem with no files in it)
> 
> Are you fuzz-testing here?

more-or-less, I'm working on a file system checker that records all the writes that go the the file system and then replays them one by one (or sector by sector), possibly with errors. In the end I want to have a tool that can simulate any imaginable HDD (or SSD) failure mode.

In this specific case, it was truncating all writes that go to the file system to 256 bytes, so "a bit" of information was lost

So the answer to "What the heck happened to this filesystem?" would be:
It fell into a Bl**Tec blender :)

Oof.

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

Fixed in e2fsprogs-1.42.9