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