Re: Kernel panic from corrupt journal

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

 



On Thu, Aug 30, 2012 at 10:22:12AM +0100, Brian Candler wrote:
> I have a system where just replaying the journal causes a kernel panic. If I
> boot into recovery mode and then type
> 
> 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!

I'm going to guess that there is some kind of hardware failure which
is returning an I/O error that the device driver can't handle, and so
you're getting a kernel panic.  That's because if you get it while
accessing the data blocks on the disk which contains the journal from
a userspace program such as debugfs, there is no ext4 kernel code
which is involved.

Taking a screen shot with the scratch information is useful, but it
will almost certainly (especially when you are running the journal via
e2fsck or debugfs) show a kernel strack trace that doesn't involve the
ext4 code paths at all.

> (1) the fact that I can cause a kernel panic is 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.

What kind of device is /dev/sda?  You might want to try removing the
disk and connecting it to another computer, and then copying the
entire disk image to a new disk using dd_rescue (which will create a
block-by-block copy of the disk image).  You could try copying the
disk using dd_rescue on your current computer. but it will almost
certainly crash as well.  It seems likely that the mere act of trying
to read the data block in question is causing an I/O error which is
causing the device driver to crash.

Regards,

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


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux