Clear bad blocks list??

Help
2006-12-24
2012-11-28
  • Ivan Adzhubey
    Ivan Adzhubey
    2006-12-24

    I am attempting data recovery on a disk image dumped from a 200GB ext3-formatted partition. The hard drive was failing so there are many errors in the dump (obtained with dd_rescue). Now, I have removed ext3 journal and trying to run e2fsck on the dump file. However, when I try:

    # e2fsck -b 32768 -y hde2dump.img

    it produces a lot of messages about errors, e.g.:

    Missing '..' in directory inode 13697025.
    Fix? yes

    Entry '..' in ... (13697025) points to inode (2) located in a bad block.
    Clear? yes

    Missing '..' in directory inode 14057473.
    Fix? yes

    Entry '..' in ... (14057473) points to inode (2) located in a bad block.
    Clear? yes

    Missing '..' in directory inode 14139393.

    and finally aborts with the following:

    Pass 3: Checking directory connectivity
    Root inode is not a directory; aborting.
    e2fsck: aborted

    Possibly, an indication that bad blocks list prevents it from recreating a new root inode. But I am not able to clear bad blocks list for the dump file either:

    # e2fsck -b 32768 -c -y hde2test.img
    e2fsck 1.38 (30-Jun-2005)
    ext2fs_block_iterate: Ext2 file too big while sanity checking the bad blocks inode

    So I'm stuck: I know there are recoverable data in the image but I can't get to it ;-(.

    Is there any way to clear bad blocks inode directly (debugfs)?

    Thanks!

    Ivan

     
    • Theodore Ts'o
      Theodore Ts'o
      2006-12-24

      The bad blocks inode is inode #1, so you can clear it by using the debugfs command:

      debugfs: clri <1>

      Of course, you'll need to run debugfs with the -w option so the filesystem is opened read/write.

       
    • Ivan Adzhubey
      Ivan Adzhubey
      2006-12-25

      Thanks Theodore, this sort of worked but unfortunately, now it crashes with segmentation fault:

      # e2fsck -b 32768 -y hde2test.img
      e2fsck 1.38 (30-Jun-2005)
      / was not cleanly unmounted, check forced.
      Pass 1: Checking inodes, blocks, and sizes
      Pass 2: Checking directory structure
      Pass 3: Checking directory connectivity
      Pass 3A: Optimizing directories
      Pass 4: Checking reference counts
      i_file_acl for inode 3981 (...) is 1685217635, should be zero.
      Clear? yes

      Inode 3981 (...) has invalid mode (071537).
      Clear? yes

      i_file_acl for inode 3982 (...) is 1684890368, should be zero.
      Clear? yes

      Inode 3982 (...) is an illegal block device.
      Clear? yes

      i_file_acl for inode 3983 (...) is 1668505460, should be zero.
      Clear? yes

      i_faddr for inode 3983 (...) is 1600614252, should be zero.
      Clear? yes

      i_frag for inode 3983 (...) is 98, should be zero.
      Clear? yes

      i_fsize for inode 3983 (...) is 117, should be zero.
      Clear? yes

      Segmentation fault

      Anything else I can try?

      Thanks,
      Ivan

       
      • Theodore Ts'o
        Theodore Ts'o
        2006-12-25

        Yeah, upgrade to a newer version of e2fsprogs.  It was fixed in e2fsprogs 1.39.  To quote from the release notes:

        Fix e2fsck from segfaulting on disconnected inodes that contain one or
        more extended attributes.  (Addresses Debian Bug: #316736, #318463)

         
    • Ivan Adzhubey
      Ivan Adzhubey
      2006-12-26

      Man you are great! This did the trick and I had most of my data recovered already. Thanks a lot! Any ideas why e2fsprogs has not been yet updated to v1.39 for Fedora Core 5? I have had to use another computer with v1.39 installed and export dump image over the NFS. FC6 has it, but too flaky to be useful in anything close to production environment, IMHO...

      Cheers,
      Ivan