linux-ext4 - Kernel panic from corrupt journal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120830092212.GB12981@nsrc.org>
Date:	Thu, 30 Aug 2012 10:22:12 +0100
From:	Brian Candler <B.Candler@...ox.com>
To:	linux-ext4@...r.kernel.org
Subject: Kernel panic from corrupt journal

I have a system where just replaying the journal causes a kernel panic. If I
boot into recovery mode and then type

    # fsck /dev/sda8

it says it's recovering the journal, then a second or two later I get a
panic traceback.  I have a screenshot; unfortunately even with a modeset
console it scrolls off the top, and I couldn't scroll back using the various
pgup/pgdown and scroll-lock  combinations I tried.

With "debugfs /dev/sda8", then:

    logdump /tmp/sda8.dmp      -> this works OK, writes out a list of blocks
    logdump -ac /tmp/sda8.dmp  -> this also causes a kernel panic!

Background info: this system is a Dell Zino HD running Ubuntu 12.04 (fully
patched as of 29 Aug 2012, standard 3.2.0-xx kernel).  My wife accidentally
chose "suspend" rather than "shutdown" to turn it off yesterday, and it
failed to boot fully this morning.

Anyway:

(1) I think the fact that I can cause a kernel panic is still a bug, and if
I can help fix it I will.  However I'm not sure how I can pass on any useful
information given that even dumping the journal causes a kernel panic.  Can
I get the journal by dd'ing at a specific offset?

(2) I'd also like to be able to recover this filesystem, e.g. by clearing
the journal, but I haven't been able to find out how to do this.

The best I could find by googling is to try mounting with ro,noload. That
works, but then accessing some of the files on the filesystem causes
application crashes (but not kernel panics). For example:

    find /u -type f -print0 | xargs -0 ls -l >/dev/null

gives me a traceback for ls on stderr.

I guess the Dell's "suspend" might simply have written across a whole area
of the disk where the filesystem was :-(

Regards,

Brian.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html