linux-ext4 - Re: [Bugme-new] [Bug 11873] New: unable to mount ext3 root filesystem due to htree_dirblock_to

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-prev] [day] [month] [year] [list]

Message-ID: <20081029015329.GB8295@mit.edu>
Date:	Tue, 28 Oct 2008 21:53:29 -0400
From:	Theodore Tso <tytso@....edu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-ext4@...r.kernel.org, bugme-daemon@...zilla.kernel.org,
	Jimmy.Jazz@....net
Subject: Re: [Bugme-new] [Bug 11873] New: unable to mount ext3 root
	filesystem due to htree_dirblock_to_tree

On Tue, Oct 28, 2008 at 10:31:22AM -0700, Andrew Morton wrote:
> > 
> > Since 2.6.28 mount command (busybox) is unable to mount the root file system.
> > The error returned is,
> > 
> > EXT3-fs error (device md_d0p2): htree_dirblock_to_tree: bad entry in directory
> > #2: rec_len % 4 != 0 - offset=0, inode=2109536318, rec_len=16058, name_len=111
> > 

That error means the ext3 filesystem detected an error when responding
to a readdir() request from user space.  So it seems rather strange
that this came from a mount command.  It looks like the mount
succeeded, and then something in userspace did the equivalent of "ls
/*" or "echo /*", and the first part of the directory was totally
garbaled.  (It should have been inode=2, rec_len=12, name_len=1 for
the '.' entry in the root directory.)

> > IMHO, it is a problem in mbcache or jbd.

Why do you think it is a problem with mbcache or jbd?  mbcache is only
used for extended attributes, and jbd would only get invoked once the
filesystem was getting modified.  If there was corruption in the
journal that was corrupting the filesystem when journal was recovered,
the directory corruption would be permanent, and not something that
would magically disappear when you mount the filesystem as ext2
read-only, and then remount as ext3.

This smells like ext3 is getting garbage when first reading in the
filesystem from the md device.  And then when you report that you're
also having mysterious md failures:

> > Also, there is an other problem with that kernel. After creating
> > the /dev node, loading md_mod and raid1, mdassemble start as usual
> > the md device, but the mount command doesn't recognize the /dev
> > node as valid and abort.  I need to stop the md device that has
> > been created earlier and reapply mdassemble or mdadm --assemble
> > --scan from initramfs file system. Afterwards mount command is
> > able to mount the file system but... like an ext2 file system.
> > I'm on step 2 again.
> > 

That smells like a problem with the md device, or the md setup code.

I suspect if you were to arrange to include dumpe2fs or debugfs in
your initrd, you would find that you are reading garbage from the md
device, and dumpe2fs and debugfs would be reporting, "huh?  there's no
ext3 filesystem image here".  I don't think this is a ext3 problem at
all.

							- Ted
--
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