e2fsck errors after lvextend when trying to resize2fs

[Theodore Ts'o]

On Sun, Feb 06, 2005 at 08:08:22PM -0500, Douglas E. Warner wrote:
> I found a thread that has almost the exact same symptoms as me, but didn't 
> seem to come to a resolution:
> https://listman.redhat.com/archives/ext3-users/2004-December/msg00018.html
> 
> I have an LVM(2) array that I've just lvextend'd and want to resize2fs, but I 
> can't get through the e2fsck.  I get these errors when fsck-ing:
> 
> Group 3125's inode table at 102400545 conflicts with some other fs block.
> Relocate? yes

This is cuased by a bug in Fedora Core 3's e2fsprogs.  It had patches
to support the new on-line resizing, but those patches were
incomplete, and off-line resize (i.e., resize2fs) was broken.  The
fixes have been out for a while, and e2fsprogs 1.36 has the fixes that
will resolve this problem.  Please see the RELEASE-NOTES file in
e2fsprogs 1.36 for more details:

    All of the patches that were applied to Fedore Core 3's
    e2fsprogs-1.35-11.2 have been integrated, although sometimes with a
    lot of bug fixes first.  Users of Fedora Core 3 are strongly
    encouraged to upgrade to e2fsprogs 1.36 as soon as possible.

    Add support for filesystem with the online resizing via resize inode
    feature.  Fixed numerous bugs from the Fedora patches.  The Fedora
    patches also didn't bother to do any consistency checking on the
    resize inode, or add any tests to the regression test suite.  The "-R
    resize=4g" option to mke2fs was a no-op in the Fedora patches, despite
    being listed in mke2fs's usage message.  All of these shortcomings
    have been corrected.

    E2fsck can also also fix filesystems trashed by Fedora's resize2fs
    program.  In order to do this, the user must run the commands:

    	debugfs -w /dev/hdXXX -R "features ^resize_inode
            e2fsck -f /dev/hdXXX

    Optionally, the ext2prepare command can be used to re-enable online
    resizing after the filesystem has been fixed.

							- Ted