64

Recently, my external hard drive enclosure failed (the hard drive itself powers up in another enclosure). However, as a result, it appears its EXT4 file system is corrupt.

The drive has a single partition and uses a GPT partition table (with the label ears).

fdisk -l /dev/sdb shows:

 Device Boot Start End Blocks Id System /dev/sdb1 1 1953525167 976762583+ ee GPT

testdisk shows the partition is intact:

1 P MS Data 2049 1953524952 1953522904 [ears]

... but the partition fails to mount:

$ sudo mount /dev/sdb1 a mount: you must specify the filesystem type $ sudo mount -t ext4 /dev/sdb1 a mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

fsck reports an invalid superblock:

$ sudo fsck.ext4 /dev/sdb1 e2fsck 1.42 (29-Nov-2011) fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb1

and e2fsck reports a similar error:

$ sudo e2fsck /dev/sdb1 Password: e2fsck 1.42 (29-Nov-2011) e2fsck: Superblock invalid, trying backup blocks... e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

dumpe2fs also:

$ sudo dumpe2fs /dev/sdb1 dumpe2fs 1.42 (29-Nov-2011) dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1

mke2fs -n (note, -n) returns the superblocks:

$ sudo mke2fs -n /dev/sdb1 mke2fs 1.42 (29-Nov-2011) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 61054976 inodes, 244190363 blocks 12209518 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 7453 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, 23887872, 71663616, 78675968, 102400000, 214990848

... but trying "e2fsck -b [block]" for each block fails:

$ sudo e2fsck -b 71663616 /dev/sdb1 e2fsck 1.42 (29-Nov-2011) e2fsck: Invalid argument while trying to open /dev/sdb1

However as I understand, these are where the superblocks were when the filesystem was created, which does not necessarily mean they are still intact.

I've also ran a testdisk deep search if anyone can decypher the log. It mentions many entry like:

recover_EXT2: s_block_group_nr=1/7452, s_mnt_count=6/20, s_blocks_per_group=32768, s_inodes_per_group=8192 recover_EXT2: s_blocksize=4096 recover_EXT2: s_blocks_count 244190363 recover_EXT2: part_size 1953522904 recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed

Running e2fsck with those values gives:

e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

I tried that with all superblocks in the testdisk.log

for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4); do sudo e2fsck -b $i -B 4096 /dev/sdb1 done

... all with the same e2fsck error message.

In my last attempt, I tried different filesystem offsets. For each offset i, where i is one of 31744, 32768, 1048064, 1049088:

$ sudo losetup -v -o $i /dev/loop0 /dev/sdb

... and running testdisk /dev/loop0, I didn't find anything interesting.

I've been fairly exhaustive, but is there any way to recover the file system without resorting to low-level file recovery tools (foremost/photorec)?

Improve this question
5
  • What does sudo fdisk -l /dev/sdb show? Commented Mar 2, 2012 at 21:49
  • 6
    I can't make myself believe that you were unlucky enough to have all copies of the superblock wiped. So there must be something wrong with the partition table, which in turn is throwing off the logical block offsets in the filesystem causing fsck to not be able to find the alternate superblocks. Commented Mar 3, 2012 at 7:51
  • Didn't you have on this disk LVM? Do you have a external enclosure the same type as previous (same block size, etc.)? Commented Mar 3, 2012 at 8:07
  • 1
    @KyleJones Following advice from the author of testdisk, as mentioned above, I tried different offsets using losetup (i * 512 where i is one of 62, 64, 2047 or 2049). Commented Mar 3, 2012 at 11:09
  • @JanMarek No, no LVM unfortunately. The enclosure is one that houses any standard 3.5" disk, but I don't have another, nor a second 1TB disk. Commented Mar 3, 2012 at 11:10

5 Answers 5

Reset to default
25

Unfortunately, I was unable to recover the file system and had to resort to lower-level data recovery techniques (nicely summarised in Ubuntu's Data Recovery wiki entry), of which Sleuth Kit proved most useful.

Marking as answered for cleanliness' sake.

Improve this answer
17

This may be outdated already, but a few suggestions:

If you are absolutely sure that the original blocksize is 4096, as claimed by testdisk, you can rewrite the superblocks on the disk using mke2fs -S. From man:

 -S Write superblock and group descriptors only. This is useful if all of the superblock and backup superblocks are corrupted, and a last- ditch recovery method is desired. It causes mke2fs to reinitialize the superblock and group descriptors, while not touching the inode table and the block and inode bitmaps. The e2fsck program should be run immediately after this option is used, and there is no guarantee that any data will be salvageable. It is critical to specify the correct filesystem blocksize when using this option, or there is no chance of recovery.

If you are unsure about the correct blocksize, use mke2fs -n -b 2048 /dev/sdb1 and try all the superblock backups this command gives, and after that the same but using the last blocksize 1024.

Improve this answer
2

As mentioned, probably outdated, but fdisk (AFAIK) doesn't support GPT disks. You need to use parted or some other tool.

I just tested a Virtual Machine running Debian squeeze (kernel 2.6.32-5-486) and formatted a virtual disk as GPT using parted ...

# parted /dev/sde (parted) mklabel GPT (parted) mkpart part1 0 10G (parted) quit # fdisk -l /dev/sde . WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted. . Disk /dev/sde: 85.9 GB, 85899345920 bytes 255 heads, 63 sectors/track, 10443 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: 0x00000000 . Device Boot Start End Blocks Id System /dev/sde1 1 10444 83886079+ ee GPT

This is fdisk version 2.17.2 (util-linux-ng).

mkfs and fsck should pick up the 'real' partition OK, but in order to check that the GPT partition table is not corrupted, you should have used GNU parted.

Improve this answer
1

I got the same mounting problem after rebooting my computer. In my case it was enough to run parted and issue a command like:

set 1 lvm on

and then quit and try to remount. Maybe it will help you also.

Improve this answer
0

  • Make a complete image of the stick (in my case, a Micro SD card).

  • Restore the image to a new MicroSD Card.

  • Run

    fsck.ext4 -f /dev/sdXY

    (where sdXY is replaced with the actual device name of the new MicroSD card)

    Anser "yes" if asked whether errors should be repaired.

  • After it is done, it worked fine for me again.

Improve this answer
1
  • The question mentions running fsck and shows that it fails, so this wouldn’t help in the particular circumstances detailed in the question. Commented Apr 27, 2023 at 12:20

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.