How to read contents of a hard disk image file that seems to be part of a RAID

Question

I received a hard disk image file from a friend. I decompressed it with xz.

Afterwards, I ran fdisk -l the-decompressed-hard-disk-image-file. Output:

Disk the-decompressed-hard-disk-image-file: 64 MiB, 67108864 bytes, 131072 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: dos
Disk identifier: 0x04b1efc7

Device             Boot Start    End Sectors Size Id Type
the-decompressed-hard-disk-image-file1       2048 131071  129024  63M fd Linux raid autodetect

How can I now recover the existing data? Can I create a software RAID device with mdadm using the the-decompressed-hard-disk-image-file without losing its data and then mount it?

I attempted to simply mount it: mount the-decompressed-hard-disk-image-file /mnt. Output:

mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

I tried mdadm --assemble /dev/md0 the-decompressed-hard-disk-image-file. Output:

mdadm: the-decompressed-hard-disk-image-file is not a block device.
mdadm: the-decompressed-hard-disk-image-file has no superblock - assembly aborted

I am on a Linux banshee 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux. df -Th returns:

Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/sda1      ext4      2.0G  833M  1.1G  45% /
udev           devtmpfs   10M     0   10M   0% /dev
tmpfs          tmpfs      25M  232K   25M   1% /run
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs      49M     0   49M   0% /run/shm

Any information/ help will be greatly appreciated!

AdminBee · Accepted Answer · 2021-10-15T12:42:51.173

Mounting an image file is possible, but you need to use the "loopback interface" for that. You can try the following (as root)

~# losetup -Pf /path/to/imagefile.img

This will choose the first available loopback device (usually number 0) and set it up to attach the image file. It will also peform a partition scan in case your image contains several partitions.

If you are using a graphical desktop environment, you should already see icons for the (not yet mounted) filesystems appear. Double-click to mount and open.

If you want to do it purely on the console, you use

~# mount /dev/loop0 /mnt

where you substitute the the number after loop with the actual number of the loopback device actually used, or even with device number and partition number in the form (e.g.) loop0p1 if the image contains several partitions. Running losetup -l -a will give you a list of all loopback devices and their statuses.

Once you are finished working, unmount and run

~# losetup -d /dev/loop0

do detach the image from the loopback device.

Note however that if the image file actually belongs to a RAID, then mounting a partition from that image will not help you unless you also get the image files for the remaining RAID devices. You will then still need to set up the loopback devices for all image files, but instead of mounting them, you would re-assemble them via mdadm as usual, only that you will use the /dev/loopN devices (or, if the RAID uses partitions rather than entire drives, /dev/loopNp1) instead of physical hard drives /dev/sdX.

Assuming that /dev/md0 is not yet used as RAID device, and since your fdisk scan indicated that a partition is present on the image file, you can use

mdadm --assemble /dev/md0 /dev/loop0p1 ... other loopback devices here

If you only have this one image file, then your friend might have created a single-drive RAID (rather unusual, but not unheard of), or your are missing image files. If only one image file is missing, and the drive was of an "actually redundant" RAID type (i.e. not RAID0), you can try to start it in degraded mode:

mdadm --assemble --force /dev/md0 /dev/loop0p1

Then, mount and inspect it.

`losetup -l -a` returns `/dev/loop0`. I ran `mdadm --create /dev/md0 --level=0 --force --raid-devices=1 /dev/loop0` and received the following warning `mdadm: partition table exists on /dev/loop0 but will be lost or meaningless after creating array`. Will I lose the data if I hit continue? I guess partition table is not that important if only 1 partition existed before? Does that mean that disk contents will still be available? — festiv, Oct 15 '21 at 11:35
No, the partition table is not meaningless. You are not forced to use entire hard drives as RAID devices, you can just as well use _partitions_ (see [here](https://unix.stackexchange.com/q/550497/377345) e.g.). So, assuming `loop0` is the device associated with your image file, try adding `loop0p1` (and yes, partition numbers will start a _1_) to the RAID when assembling, instead of `loop0`. Note that you must use `assemble` rather than `create` since the device you have belongs to a RAID that was already "created". And the syntax in your last comment was lacking the MD device (`/dev/md0`). — AdminBee, Oct 15 '21 at 11:58
@FrédéricLoyer, @AdminBee I ran `mdadm --assemble --run /dev/md0 /dev/loop0p1` (`--run` was provided as `mdadm --assemble /dev/md0 /dev/loop0p1` returned `mdadm: /dev/md0 assembled from 1 drive - need all 2 to start it (use --run to insist).`) I then tried `mount /dev/md0 /mnt/test` and received `mount: unknown filesystem type 'crypto_LUKS'`. Does that mean hard drive has been encrypted? Is there anything I can do from here? — festiv, Oct 15 '21 at 12:28
That sounds like an encrypted filesystem. You will have to read into decryption of LUKS devices and ask your friend for the passphrase/keyfile/whatever ... But this is an entirely new question. — AdminBee, Oct 15 '21 at 12:32

How to read contents of a hard disk image file that seems to be part of a RAID

1 Answers1