All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dâniel Fraga" <fragabr@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Kernel 3.7.0: bad header/extent
Date: Sun, 16 Dec 2012 03:39:35 -0200	[thread overview]
Message-ID: <50cd5e9b.0839650a.221f.ffffc460@mx.google.com> (raw)
In-Reply-To: <20121216035150.GA6104@thunk.org>

On Sat, 15 Dec 2012 22:51:50 -0500
Theodore Ts'o <tytso@mit.edu> wrote:

> Um, really?  **Exactly** the same error message?  That doesn't make
> any sense.  The error message you quoted happens when the kernel
> complains that the block numbers in the inode in question are invalid
> (i.e., are too big for the inode in question, or point at file system
> metadata).

	Yes. The exact same message before and after:

EXT4-fs error (device sda2): ext4_ext_check_inode:462: inode #9311628:
comm less: bad header/extent: invalid extent entries - magic f30a,
entries 1, max 4(4), depth 0(0)

> However, debugfs is not showing any extents --- which would be the
> case after e2fsck repaired the file system (it would have zapped the
> extent tree for the inode).
> 
> So (a) you did run e2fsck on an unmounted file system right?

	Yes, unmounted.

> (b) Can you send me the output of:
> 
> 	debugfs -R "extents <9311628>" /dev/sda2
> 
> just to be sure we aren't missing anything.

	Here it is:

debugfs 1.41.12 (17-May-2010)
Level Entries       Logical              Physical Length Flags
 0/ 0   1/  1     0 - 4294967295  37333026 - 4332300321      0 

> Also, if you are using a really new kernel such as 3.6.x or 3.7.x, you
> ***really*** shouldn't be using an ancient version of e2fsprogs such
> as 1.41.12.  You really should be using e2fsprogs 1.42.x, preferably
> the latest e2fsprogs 1.42.6.  I wonder if you are seeing a similar
> message indicating that the file system had previously found an error,
> and which wasn't cleared because you are using an ancient version of
> e2fsprogs....

	Ok. The problem is that I'm trapped. I need to compile the most
recent version (1.42.6) but the needed file to
compile (/usr/include/dlfcn.h) isn't available (Input/output error)
because of this problem. 

	But no problem, because I used e2fsck from "Recovery is
possible 13.7" cd which uses e2fsck 1.42 version (so you can be sure I
used e2fsck 1.42 version).

	Any more suggestions? Thanks!

-- 
Linux 3.7.0: Terrified Chipmunk
http://www.youtube.com/DanielFragaBR
http://www.libertarios.org.br

  reply	other threads:[~2012-12-16  5:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-15 20:44 Kernel 3.7.0: bad header/extent Dâniel Fraga
2012-12-16  2:27 ` Theodore Ts'o
2012-12-16  3:00   ` Dâniel Fraga
2012-12-16  3:51     ` Theodore Ts'o
2012-12-16  5:39       ` Dâniel Fraga [this message]
2012-12-16  6:08         ` Andreas Dilger
2012-12-16 14:50           ` Theodore Ts'o
2012-12-16 23:52             ` Dâniel Fraga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50cd5e9b.0839650a.221f.ffffc460@mx.google.com \
    --to=fragabr@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.