Bug 176172 - e2fsck unable to check lvm: Corruption found in superblock
Summary: e2fsck unable to check lvm: Corruption found in superblock
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: e2fsprogs
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Thomas Woerner
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-12-19 20:12 UTC by Rex Dieter
Modified: 2015-01-08 00:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-01-05 14:32:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Rex Dieter 2005-12-19 20:12:10 UTC
Just got done creating a lvm ext3 filesystem (~800GB), mke2fs'd it, checked for
badblocks, copied ~300GB data to it.  On server reboot, boot process stops on error:

Corruption found in superblock (r_blocks_count=97677300)
The superblock could not be read or does not describe a correct ext2 filesystem.

If I skip the fsck on boot, I can still mount it, and do anything I want (it
seems to work fine).

I'm about to start worrying, but on a whim, I noticed on e2fsprogs.sf.net, that
the latest version is 1.38 (vs rhel4's 1.35).  Grabbed development's
e2fsprogs-1.38-2.1.1 rebuilt it on my el4 box.  Tried it out.  Woah!  It
actually worked (or at least started to work before I interrupted it, and it
didn't complain about a corrupted superblock).

On the surface, it appears to the "Corruption found in superblock" (bogus?)
error is rooted in some e2fsprogs bug that was fixed somewhere between rhel4's
e2fsprogs-1.35-12.2.EL4 and developments' e2fsprogs-1.38-2.1.1

Comment 1 Rex Dieter 2006-01-05 14:32:48 UTC
From e2fsprogs' 1.36 Releaes Notes:
-----------------
The tune2fs program will not allow the user from setting a ridiculous
number of reserved blocks which would cause e2fsck to assume the
superblock was corrupt.  E2fsck's standards for what is a ridiculous
number of reserved block has also been relaxed to 50% of the blocks in
the filesystem.
-----------------

Turns out in this case, we *had* set the reserved block % to 50%, so it's
(probably) NOTABUG, though an upgrade to handle this situation would still be nice.


Note You need to log in before you can comment on or make changes to this bug.