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

RE: Seriously corrupt ext3 root filesystem - help?



...and if this doesn't do it, isn't the next step to fix corruption in
the inode group (or something to do with groups).  

I was installing vmware ESX and kept screwing up one of the ext3 file
systems because I told vmware to convert it to vmfs (proprietary vmware
file system).  And it did, sort of.  Until the next boot when that
partition couldn't be mounted and fsck couldn't fix it.  I didn't fix it
since it was empty but I ran across a reference to bad inode group or
something similar leading me to believe that it might have been fixable.



Dana Bourgeois


> -----Original Message-----
> From: ext3-users-admin redhat com 
> [mailto:ext3-users-admin redhat com] On Behalf Of Andreas Dilger
> Sent: Sunday, July 20, 2003 2:31 PM
> To: Eddy
> Cc: ext3-users redhat com
> Subject: Re: Seriously corrupt ext3 root filesystem - help?
> 
> 
> On Jul 20, 2003  14:57 -0500, Eddy wrote:
> > On Sun, 20 Jul 2003 09:45:09 -0700, "Andreas Dilger" 
> > <adilger clusterfs com> said:
> > > > 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. :-(
> > > >
> > > > # 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 
> > > > ...
> > >
> > > Try gpart to see if it is your partition table that is corrupt.
> > 
> > Thanks for the suggestion. The partition table seems to be 
> intact and
> > correct.
> > 
> > Any other ideas on how to try and recover the data on this 
> filesystem? 
> > (The other filesystems on the drive are fine. Unfortunately 
> they don't 
> > contain the bulk of the data that I need.)
> 
> If gpart showed that the partition tables are OK, then this 
> also means that your ext3 backup superblocks are available.  
> You should force e2fsck to use one of the backups with -b 
> 32768 (or whatever a backup superblock location is).
> 
> Cheers, Andreas
> --
> Andreas Dilger
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
> 
> 
> _______________________________________________
> Ext3-users mailing list
> Ext3-users redhat com 
> https://www.redhat.com/mailman/listinfo/ext3-> users
> 




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