Ext3 users - Oct 2005 - Recover original superblock on corrupted filesystem?

I've been trying to use fsck to recover a corrupted filesystem.

It appears the original superblock is corrupted too, as it has an inode
count of 0.  When I start fsck with -b 32760, it uses the alternate
superblock and proceeds.  However, it restarts from the beginning a
couple of times and after the second restart it doesn't use the
alternate superblock, stopping instead as it can't find the original
one.

Is there a way around this, such as using one of the alternate
superblocks to replace the broken one, or a way of forcing fsck to keep
on using the alternate one?  The checking process is taking several
hours in each case, as it's quite a large filesystem.

Thanks for any suggestions.

Adam

You could try using using mkfs -S , to just recreate the SuperBlock,
check man mkfs before u do that.......

take a data backup too

then after superblock is recreated ...mount file system readonly..and
then run fsck...once fsck has fixed the bugs....u can remount
read/write..and ur fs is up and running

Digz


On Fri, 2005-10-21 at 15:51 +0100, bloch at verdurin.com
wrote:
> I've been trying to use fsck to recover a corrupted filesystem.
> 
> It appears the original superblock is corrupted too, as it has an inode
> count of 0.  When I start fsck with -b 32760, it uses the alternate
> superblock and proceeds.  However, it restarts from the beginning a
> couple of times and after the second restart it doesn't use the
> alternate superblock, stopping instead as it can't find the original
> one.
> 
> Is there a way around this, such as using one of the alternate
> superblocks to replace the broken one, or a way of forcing fsck to keep
> on using the alternate one?  The checking process is taking several
> hours in each case, as it's quite a large filesystem.
> 
> Thanks for any suggestions.
> 
> Adam
> 
> _______________________________________________
> Ext3-users mailing list
> Ext3-users at redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for
the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are
not to copy, disclose, or distribute this e-mail or its contents to any other
person and any such actions are unlawful. This e-mail may contain viruses.
Infosys has taken every reasonable precaution to minimize this risk, but is not
liable for any damage you may sustain as a result of any virus in this e-mail.
You should carry out your own virus checks before opening the e-mail or
attachment. Infosys reserves the right to monitor and review the content of all
messages sent to or from this e-mail address. Messages sent to or from this
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

Hi,

On Fri, 2005-10-21 at 15:51 +0100, bloch at verdurin.com wrote:
> It appears the original superblock is corrupted too, as it has an inode
> count of 0.  When I start fsck with -b 32760, it uses the alternate
> superblock and proceeds.  However, it restarts from the beginning a
> couple of times and after the second restart it doesn't use the
> alternate superblock, stopping instead as it can't find the original
> one.
Do you have a log of the fsck output, and which e2fsprogs version is
this?  Sounds like it may be an e2fsck bug if we don't honour the backup
superblock flag on subsequent passes.
> Is there a way around this, such as using one of the alternate
> superblocks to replace the broken one
Yes, "dd" of the appropriate block should work... but do this with
extreme care, as getting it slightly wrong will cause major havoc.

"debugfs" may be a better bet.  

	# debugfs -w -b$BLOCKSIZE -s$SUPERBLOCK /dev/$DEV

will tell debugfs to read the specified superblock.  If you dirty the
superblock (eg. with the "dirty" command) then quit, it will write
back
the backup superblock to the home location too.

--Steph