Testing file system repair attempts on a read-only disk image

By dose | September 1, 2021
Under: Uncategorized

I recently got a damaged HFS+ formatted volume for analysis and repair.
Now I did what has to be done first on all data recovery attempts, obviously: Create a dd Disk image from the disk before messing around with it.
As the volume was very large, it would cost a lot of time and disk space to always make a copy of the image, mess around with it and if it fails, restore the original image. Copying around terabytes of data on a slow medium like classic harddisks is taking a lot of time, after all.
So I was searching for a way to operate on a snapshot-overlay of the original image to mess around with it and just dump the snapshot and revert, if something goes wrong.
Fortunately, I found this Stackoverflow post, which describes a way to do what I want.
So here is a little mount script mount_ovl.sh:

if [ $# -eq 0 ]; then
  echo Usage: $0 ro-device \[overlay-size\]
  echo i.e.: $0 /dev/loop0
if [ ! -e $1 ]; then
  echo $1 does not exist
if [ -z "$2" ]; then
truncate -s$ovlsz $ovl
size=$(blockdev --getsz "$1")
loop=$(losetup -f --show -- "$ovl")
echo "0 $size snapshot $1 $loop P 8" | dmsetup create "$newdevname"
echo Mounted $loop to $newdevname

So, to i.e. do a fsck.hfsplus without ruining the original image, I first create a loopf device of the disk image:

# losetup -P /dev/loop0 /mnt/winhexraw.dd

Let’s list the partitions that it autodetected with -P:

# fdisk -lu /dev/loop0
Disk /dev/loop0: 931,5 GiB, 1000170586112 bytes, 1953458176 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
Disklabel type: gpt
Disk identifier: B9D171AA-7F12-4DD2-B1BD-FAE6A14B1DA8

Device        Start        End    Sectors   Size Type
/dev/loop0p1     40     409639     409600   200M EFI System
/dev/loop0p2 409640 1953195991 1952786352 931,2G Apple HFS/HFS+

So /dev/loop0p2 is the partition that needs to be checked.
Now mount it R/W with the script to /dev/mapper/ovldev:

./mount_ovl.sh /dev/loop0p2

Now it can be i.e. checked with

fsck.hfsplus -f /dev/mapper/ovldev

and possibly fixed. In my case, file system was damaged and fsck was unable to fix it, so I finally resorted to HFS+ rescue to get the files off from it. But this little hint can still be useful for futher attempts to i.e. repair the filesystem by hand.

To drop the snapshot again, assuming that it got mounted to /dev/loop1:

dmsetup remove "ovldev"
losetup -d /dev/loop1

And to release original loop device for disk image:

losetup -d /dev/loop0

Might become handy some day.

Leave a Comment


E-Mail :

Subscribe :
Website :

Comments :