2

I am using Linux on my notebook. My notebook recently fall on ground and now I am trying to save as much data from my damaged hdd as possible. I can boot notebook from Linux live CD.

Long story short: one ext4 partition is not mountable, but I can try to repair it by fsck.ext4. I also can try to first try to recover bad blocks on hdd (probably by SpinRite). What sould I do first?

In full details:

Here is my drive:

# fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000080

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        3824    30716248+   7  HPFS/NTFS
/dev/sda2            3825       19449   125507812+  83  Linux
/dev/sda3           19450       19457       64260   83  Linux

Let' forget /dev/sda1 NTFS partition, not that important. Third partition /dev/sda3 is just /boot, not important either. Second /dev/sda2 is physical space for LVM (see bellow).

Logical group /dev/group1/arch is encrypted by dm-crypt LUKS, I am unable to open it and data there are probably lost. Logical groups /dev/group1/data and /dev/group1/data2 are ext4 volumes. I can mount /dev/group1/data2 (mount -t ext4 -o ro,noload /dev/group1/data2 /mnt/data2) and backup data on external drive. But I can not mount /dev/group1/data:

# mount -t ext4 -o ro,noload /dev/group1/data /x/data
mount: wrong fs type, bad option, bad superblock on /dev/mapper/group1-data,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

fsck does not work:

# fsck.ext4 -n /dev/group1/data
e2fsck 1.41.11 (14-Mar-2010)
fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/group1/data
Could this be a zero-length partition?

dumpe2fs does not finds superblock either:

# dumpe2fs /dev/group1/data
dumpe2fs 1.41.11 (14-Mar-2010)
dumpe2fs: Attempt to read block from filesystem resulted in short read while trying to open /dev/group1/data
Couldn't find valid filesystem superblock.

Only thing I can do is try to find where superblock usually is:

# mkfs.ext4 -n /dev/group1/data
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
5242880 inodes, 20971520 blocks
1048576 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
640 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000

...and start fsck using one of this superblocks:

# fsck.ext4 -n -b 229376 /dev/group1/data
e2fsck 1.41.11 (14-Mar-2010)
One or more block group descriptor checksums are invalid.  Fix? no

Group descriptor 0 checksum is invalid.  IGNORED.
Group descriptor 1 checksum is invalid.  IGNORED.
Group descriptor 2 checksum is invalid.  IGNORED.
Group descriptor 3 checksum is invalid.  IGNORED.
Group descriptor 4 checksum is invalid.  IGNORED.
Group descriptor 5 checksum is invalid.  IGNORED.
...
Group descriptor 637 checksum is invalid.  IGNORED.
Group descriptor 638 checksum is invalid.  IGNORED.
Group descriptor 639 checksum is invalid.  IGNORED.
/dev/group1/data contains a file system with errors, check forced.
Resize inode not valid.  Recreate? no

Pass 1: Checking inodes, blocks, and sizes
...here I pressed Ctrl-C...

So - it displays a lots of errors, but it seems it will try to repair (if I use fsck.ext4 -y instead fsck.ext4 -n of course).

Other options - frind of mine has SpinRite 6 boot CD, which is told to be on of the best programs to repair bad blocks.

So my QUESTION is - should I

  1. try first SpinRite to repair bad blocks and then fsck.ext4 -y (or even better dump whole raw partitition to one big file on external hdd, make copy, mount copy as loopback and then try fckk.ext4 -y)
  2. try firt fsck.ext4 -y with hope than afterwards ome data will be readable, backup this data on external hdd (and then try eventually SpinRite) ?
  3. or do something else?

Thanks a lot for any hint.

LVM structure:

# pvdisplay 
  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               group1
  PV Size               119.69 GiB / not usable 2.22 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              30641
  Free PE               0
  Allocated PE          30641
  PV UUID               0k3Zl5-Q7BD-rb8J-9jTZ-2uii-GSGd-B339JB

# vgdisplay 
  --- Volume group ---
  VG Name               group1
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  10
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                4
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               119.69 GiB
  PE Size               4.00 MiB
  Total PE              30641
  Alloc PE / Size       30641 / 119.69 GiB
  Free  PE / Size       0 / 0   
  VG UUID               kKhvri-OVpL-uhCP-T4an-qXIJ-4XL0-kn9Ifi



# lvdisplay 
  --- Logical volume ---
  LV Name                /dev/group1/swap
  VG Name                group1
  LV UUID                wpDink-01q0-peLc-29at-5kgP-YO3a-8bNrb7
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                1.50 GiB
  Current LE             384
  Segments               1
  Allocation             contiguous
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

  --- Logical volume ---
  LV Name                /dev/group1/arch
  VG Name                group1
  LV UUID                S1TZkr-y62z-dOuc-D38G-nuCH-1ilc-y2jqMa
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                15.00 GiB
  Current LE             3840
  Segments               1
  Allocation             contiguous
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1

  --- Logical volume ---
  LV Name                /dev/group1/data
  VG Name                group1
  LV UUID                2R4LNv-sHPh-E7ES-goIF-5nUz-tQyj-GOiwvC
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                80.00 GiB
  Current LE             20480
  Segments               1
  Allocation             contiguous
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:2

  --- Logical volume ---
  LV Name                /dev/group1/data2
  VG Name                group1
  LV UUID                4VqpZj-uOBi-OAIZ-1IXA-G6mj-Qgfb-c6RYqw
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                23.19 GiB
  Current LE             5937
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:3

1 Answer 1

5

The first thing I would do is use ddrescue from a liveCD to make a backup image of the drive. If there's physical damage to the drive, there's a chance that there's a finite amount of time until it fails completely. Then, make a copy of that image to work on.

From there, I have no suggestions that you haven't tried. Others smarter than me will have to help you there.

3
  • Yes, please, make a backup image first and do all your repair work on the backup.
    – mtinberg
    Aug 4, 2010 at 16:10
  • Thanks for advice. Only ddrescue works in my case really slow - my 80GB partition will take about 40 days (etimated by progress after two hours). And recued vs. error ratio is 2:1 so, result will be probably unusable. But it was good advice to tray it anyway.
    – Stepan
    Aug 4, 2010 at 18:22
  • This probably means that your drive is damaged and ddrescue is trying to re-read portions in order to ensure success. Was the error number in ddrescue increasing? Something else to try: Flip the drive upside down. It sounds crazy, but I've seen it work many times. This doesn't exactly sound like the type of problem that helps with, but it's worth a try.
    – dpflug
    Aug 5, 2010 at 4:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.