...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@redhat.com > https://www.redhat.com/mailman/listinfo/ext3-> users > _______________________________________________ Ext3-users@redhat.com https://www.redhat.com/mailman/listinfo/ext3-users
