1

So I'm creating this training scenario whereby participants have to take an image of a broken disk, loop mount and recover the data. It's supposed to be fairly basic, but I've come accross this weird issue.

There's this drive /dev/vdb:

[root@training ~]# fdisk -l /dev/vdb

Disk /dev/vdb: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

First I take an image and make sure the md5sum of both the image and drive match:

[root@disk-training ~]# dd if=/dev/vdb of=/recovery/recovery.img conv=sync,notrunc,noerror
10485760+0 records in
10485760+0 records out
5368709120 bytes (5.4 GB) copied, 64.6406 s, 83.1 MB/s

[root@disk-training ~]# md5sum /dev/vdb
08452c6ca60007e69694e7e96258554d  /dev/vdb

[root@disk-training ~]# md5sum /recovery/recovery.img
08452c6ca60007e69694e7e96258554d  /recovery/recovery.img

Next, to ensure no caches confuse the situation, I drop them:

[root@disk-training ~]# sync; echo 1 > /proc/sys/vm/drop_caches
[root@disk-training ~]# sync; echo 2 > /proc/sys/vm/drop_caches
[root@disk-training ~]# sync; echo 3 > /proc/sys/vm/drop_caches

Using a mix of testdisk to recover the partition and fsck to recover the filesystem, I can retrieve the file:

[root@disk-training ~]# testdisk /dev/vdb
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
You have to reboot for the change to take effect.

[root@disk-training ~]# partprobe /dev/vdb

[root@disk-training ~]# fsck -y /dev/vdb1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
/dev/vdb1 was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23896, counted=23897).
Fix? yes
Free blocks count wrong for group #1 (32127, counted=32126).
Fix? yes
Free inodes count wrong for group #0 (8181, counted=8180).
Fix? yes
Free inodes count wrong (327669, counted=327668).
Fix? yes
/dev/vdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vdb1: 12/327680 files (0.0% non-contiguous), 58463/1309696 blocks

[root@disk-training ~]# mount /dev/vdb1 /mnt/

[root@disk-training ~]# ls -l /mnt/file
-rw-r--r-- 1 root root 10 Dec 12 15:41 /mnt/file

So that's all good. So I set up the image as a loop device and do another md5sum to be sure:

[root@disk-training ~]# losetup /dev/loop0 /recovery/recovery.img

[root@disk-training ~]# md5sum /dev/loop0
08452c6ca60007e69694e7e96258554d  /dev/loop0

Now if I run the same process on this, it doesn't succeed:

[root@disk-training ~]# testdisk /dev/loop0
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
You have to reboot for the change to take effect.

[root@disk-training ~]# partprobe /dev/loop0

[root@disk-training ~]# fsck -y /dev/loop0p1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/loop0p1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

And here's some basic troubleshooting I've done:

[root@disk-training ~]# dumpe2fs /dev/loop0p1
dumpe2fs 1.42.9 (28-Dec-2013)
dumpe2fs: Bad magic number in super-block while trying to open /dev/loop0p1
Couldn't find valid filesystem superblock.

[root@disk-training ~]# mke2fs -n /dev/loop0p1
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
327680 inodes, 1309696 blocks
65484 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1342177280
40 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


[root@disk-training ~]# for i in {32768,98304,163840,229376,294912,819200,884736}; do e2fsck -b $i /dev/loop0p1; done
e2fsck 1.42.9 (28-Dec-2013)
e2fsck: Bad magic number in super-block while trying to open /dev/loop0p1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

e2fsck 1.42.9 (28-Dec-2013)
e2fsck: Invalid argument while trying to open /dev/loop0p1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2

......

I'm really confused by the results of this and wonder if someone can explain to me what is going on.

  • not your problem but something to look out for anyway: dd noerror sync might cause data to go to the wrong offsets superuser.com/a/1075837/195171 - use ddrescue instead – frostschutz Dec 14 '18 at 16:39
0

Turns out that the image loses its drive geometery, causing testdisk to recover an incorrect partition. Using testdisk to set the number of heads above 1 seemed to fix it.

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.