Red Hat Bugzilla – Bug 176172
e2fsck unable to check lvm: Corruption found in superblock
Last modified: 2015-01-07 19:11:22 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
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
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.