On Sat, Jan 05, 2002 at 06:33:27AM -0800, Seo Ng wrote: > Hi, > I'm on kernel 2.14.13-ac8 running Redhat 7.1. I've > successfully converted all my file system to ext3 and > is working fine for a couple of weeks. However, I did > a silly thing when I e2fsck (version 1.23) an ext3 > /home partiction without umounting it. Now, I believe > my partiton super-block is corrupted and the system > wasn't able to mount /home. I tried as suggested to do > a e2fsck -b 8193 /dev/hdaX but returned with the "bad > magic numer in super-block while trying to open > /dev/hdaX". I've also tried debugfs and have the same > error. Use "e2fsck -b 32768 /dev/hdaX" for filesystems with 4k block sizes. The new e2fsck that's about to be releaed (you can get a preview release in the latest 1.26-WIP -- Work In Progress snapshot release) will automatically search for the backup superblocks when the primary superblock is trashed, instead of always printing the number for 1k blocksizes, which is 8193. Sorry for the inconvenience, but just simply specifying -b 32768 should fix things for you. If that doesn't work, the failsafe thing which you can try is to run "mke2fs -S /dev/hdaXX", followed by an immediate "e2fsck -f /dev/hdaXX". Mke2fs -S rewrites the superblock and block group descriptors, but leaves the inode table alone. Be warned though that this can seriously screw up your filesystem if mke2fs isn't run with exactly the same parameters that were used when the filesystem is made. As a result, I strongly recommend that you make an image backup (using dd) of the filesystem, and try running mke2fs -S and e2fsck -f on the image backup copy of the filesystem. That way, if the mke2fs -S step doesn't work, you won't have made things any worse. (Granted, if "e2fsck -b 32768" doesn't work and "mke2fs -S" doesn't work, any other recovery steps will likely require a filesystem data recovery expert, but if there's important data on the filesystem, I always like to adhere to the the Hippocrattic Oath of "First, Do No Harm". :-) - Ted
