Bug 176172 - e2fsck unable to check lvm: Corruption found in superblock
e2fsck unable to check lvm: Corruption found in superblock
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: e2fsprogs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2005-12-19 15:12 EST by Rex Dieter
Modified: 2015-01-07 19:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-05 09:32:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2005-12-19 15:12:10 EST
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 09:32:48 EST
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.