[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Seriously corrupt ext3 root filesystem - help?

On Sun, Jul 20, 2003 at 08:15:52AM -0500, Eddy wrote:
> I just came back after being out for a while. Apparently there was 
> a power failure long enough to discharge the UPS completely on my Linux
> box.
> After powering back up, I received notice that the / filesystem needed
> "manual fsck"ing.
> I booted off CD and attempted to fsck. Unfortunately, everything I've
> tried has proved futile and I'm _desperate_ for some help. I've google'd
> for just about everything I can think of and am out of ideas. :-(
> # fsck.ext3 /dev/hda1
> e2fsck 1.28 (31-Aug-2002)
> Group descriptors look bad... trying backup blocks...
> fsck.ext3: Invalid argument while checking ext3 journal for /dev/hda1
> # debugfs -w /dev/hda1
> debugfs 1.28 (31-Aug-2002)
> /dev/hda1: Can't read an inode bitmap while reading inode bitmap
> debugfs: open -c /dev/hda1
> /dev/hda1: catastrophic mode - not reading inode or group bitmaps
> debugfs: stat <8>
> stat: Invalid argument while reading inode 8
> debugfs: stats
> ...
> Filesystem features:    has_journal filetype sparse_super
> Filesystem state:       clean with errors
> ...
> Directories:            1122431
>  Group  0: block bitmap at 33188, inode bitmap at 19132, inode table at
>  1027802808
>            6794 free blocks, 15870 free inodes, 1720 used directories
>  Group  1: block bitmap at 0, inode bitmap at 0, inode table at 3016944
>            2289 free blocks, 46 free inodes, 2290 used directories
> ...

Hi Eddy,

My apologies for not responding sooner.  You have the bad misfortune
of having your disk go south the day before the Kernel Summit and
Ottawa Linux Symposium started, so many of the ext2/3 hackers have
been rather busy and distracted for this past week.

It looks like your block group descriptors have gotten totally
trashed.  You mentioned that your backup superblock didn't seem to
have anything useful; did you try any of the other backup superblocks?
You can find their locations by using "mke2fs -n /dev/hda1".  The -n
option cause mke2fs to not actually *do* anything, but just display
what it would have displayed when it ran, which includes printing out
the backup superblock blocks.  Something that might be worth doing is
to use dumpe2fs, specifying the block size and backup superblock
location, and see if any of the backup locations look sane.  Checking
to see if the backup group descriptors are showing the same or
different information from the primary would also be of interest in
trying to determine what actually happened.  

If you can't find any good backup group descriptors, something to try
is the -S option to mke2fs.  You didn't specify how big this
filesystem was, but if you can manage to do a disk-to-disk image
backup, it would be a good idea to do this before you try mke2fs -S,
since this will overwrite the superblock and block group descriptors
with newly initialized versions.  This has the potential of completely
trashing your filesystem if you don't specify *exactly* the same
arguments to mke2fs as you used when you first created the filesystem
(i.e., the blocksize, number of blocks, filesystem type if you
specified it, etc., all have to be exactly the same).  Read the man
pages for more details, but as a last resort, it's certainly worth a

Good luck!  I hope this is helpful.

						- Ted

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]