Mounting a hard disk image including partitions using Linux


A while ago I thought it would be a good idea to make a backup of my Linux server by just dumping the complete disk to a file. In retrospect, it would have been much easier had I just dumped the individual filesystems.

When I finally got around to using this backup, long after the 10GB disk had perished I realized that to use the loopback device to mount a filesystem it actually needs a filesystem to mount. What I had was a disk image, including partition table and individual partitions. To further complicate matters the data partition was also not the first partition inside this image.

For reference, I created this image using the Unix ‘dd’ tool:

# dd if=/dev/had of=hda.img
30544113+0 records in
30544113+0 records out
# ls -lh
-rw-r--r-- 1 root    root  9.6G 2008-01-22 14:12 hda.img

I followed the instructions on http://www.trekweb.com/~jasonb/articles/linux_loopback.html to try and mount the partitions inside the disk image, but ran into two problems.

To mount a partition inside the disk image you need to calculate the offset of where the partition starts. You can use fdisk to show this information to you, but you need to specify the number of cylinders if you are using a disk image.

You then also need to multiply the start and end numbers with the calculated sectors to get a byte offset.

I found another tool more useful for this task, called parted. If you are using Ubuntu, you can install it with ‘apt-get install parted’

# parted hda.img
GNU Parted 1.7.1
Using /data/rabbit/disk_image/test2
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit
Unit?  [compact]? B
(parted) print
Disk /data/rabbit/disk_image/test2: 10262568959B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number  Start        End           Size         Type     File system  Flags
1      32256B       106928639B    106896384B   primary  ext3         boot
2      106928640B   1184440319B   1077511680B  primary  linux-swap
3      1184440320B  10256924159B  9072483840B  primary  ext3
(parted) quit

Now we have the offsets and we can use those to mount the filesystems using the loopback device:

#mount -o loop,ro,offset=32256 hda.img /mnt/rabbit

That mounted the first partition, the ‘boot’ partition, but this didn’t have the data on it that I was looking for. Lets try to mount partition number 3.

#umount /mnt/rabbit
#mount -o loop,ro,offset=1184440320 test2 /mnt/rabbit
#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

Oops, that doesn’t look right. According the article referred to above if you are using a util-linux below v2.12b then you cannot specify an offset higher than 32bits. I’m using util-inux 2.13 which shouldn’t have that problem, and besides, my offset is well below the 32bit limit.

The article also offers an alternative loopback implementation that supports mounting partitions within an image, but that requires patching and recompiling your kernel which I would rather not do.

Instead I decided to extra ct the filesystem from the image which would then allow me to mount it without specifying an offset.
Doing this is quite straightforward with ‘dd’. You need to give ‘dd’ a skip count, or, how far into the source to start copying, and a count, how much to copy.
Here you can either use the single byte offsets retrieved with parted or divide them by 512 and let ‘dd’ use 512 byte blocks. Copying just one byte at a time takes a very long time, so I suggest using a larger block size.

Here is the command I used to extract my filesystem. Skip is 2313360 (1184440320/512) and Count is 17719695 (9072483840/4)

#dd if=hda.img of=hda3.img bs=512 skip=2313360 count=17719695
17719695+0 records in
17719695+0 records out
9072483840 bytes (9.1 GB) copied, 485.679 seconds, 18.7 MB/s

After extracting the filesystem I was able to mount it without any problems.

# mount -o loop hda3.img /mnt/rabbit/
# df -h /mnt/rabbit
Filesystem            Size  Used Avail Use% Mounted on
/data/rabbit/image/hda3.img
8.4G  6.3G  1.7G  80% /mnt/rabbit
  • Share/Bookmark

, , ,

  1. #1 by Gunnar - March 17th, 2008 at 07:49

    This is one solution, but a more elegant solution is to use the offset-flag in loop-mounting.

    In stead of splitting up your image you can just type inn mount -o loop,offset=[same offset as calculated above].

  2. #2 by AndreMiller - March 22nd, 2008 at 07:50

    I do mention the offset option in my article, but that it has limitations. I offered the splitting as an alternative to using that if you’re having problems with it.

  3. #3 by Marko - May 28th, 2008 at 21:39

    Thanks for your article, it really heped me a lot while I was trying to find out what is wrong with my Xen disk image with multiple partitions.

  4. #4 by Angus Lee - September 1st, 2008 at 21:40

    Very helpful!
    I spent one whole afternoon on mounting a dd image found on the DVD from the book ‘Real Digital Forensics’.
    By following your steps, it just cost me one minute.
    I love you!

  5. #5 by Joe - October 9th, 2008 at 14:51

    Makes sense. I made a backup of latptop disk with 1 ntfs partition and 1 dos partition using dd if=/dev/sda and was trying to figure out how to extract the partition. This is what I was looking for. I hope it works.

  6. #6 by Anonymous - October 15th, 2008 at 03:41

    Thanks a million. Now I can sleep better.

  7. #7 by Tomaz - December 5th, 2008 at 14:32

    Great article!

    I would just like to point to a small error :
    “.. and Count is 17719695 (9072483840/4) ”

    It should be “.. and Count is 17719695 (9072483840/512)” .

  8. #8 by Anonymous - January 28th, 2009 at 06:10

    All useful information – just a followup. If your ext3 partition has been uncleanly unmounted (or you took a dump from a live system, say running as a VM) then you won’t be able to mount it directly as the journal is unclean. Follow the “dd” instructions above to extract just the partition, then run

    “fsck.ext3 hda3.img”

    to repair the filesystem before mounting.

  9. #9 by Algo - March 29th, 2009 at 22:51

    Very useful. Thank you

  10. #10 by Juuso Alasuutari - September 10th, 2009 at 15:31

    To follow up on comment #8 — here’s a page I found that explains very clearly where the “wrong fs type, bad option, bad superblock” mount error is coming from, and how to deal with it.

    (Spoiler alert: Yes, it’s all because of an unclean journal. :) )

  11. #11 by Juuso Alasuutari - September 10th, 2009 at 15:32

    Juuso Alasuutari :
    here’s a page I found that explains very clearly where the “wrong fs type, bad option, bad superblock” mount error is coming from, and how to deal with it.

    Bah! I forgot the URL: http://sansforensics.wordpress.com/2008/12/18/mounting-images-using-alternate-superblocks/

  12. #12 by David Kendall - November 19th, 2009 at 07:56

    This worked well for me. This article also applies to loading a vmware disk image that has several partitions.

    I used this to mount my vmware disk as a disk image…

    sudo vmware-mount -f Frog/Frog.vmdk /mnt/frog/

    I could then mount individual partitions in the image like this….

    sudo mount -t ntfs -o loop,offset=10487232000B /mnt/frog/flat /mnt/toad/

    vmware-mount seems to have issues with partitioned disks. This provided a great way to work around those issues.

  13. #13 by Miguel Angel Rojas - November 27th, 2009 at 02:26

    It works for me, I was died until I rescued my info.
    Thanks

(will not be published)