Mount a dd Disk Image with Partition Table inside
After making a backup from a hard disk ta a disk image using plain old ‘dd’, I was just looking into mounting it using the Linux loopback device.
If you ‘dd’ a single partition into an image file, then this is very straight forward. But if your image file contains multiple partition partitions including the partition table itself, then you need to take additional steps.
So the first thing to know is the exact offset of the partition to be mounted.
You may examine this easily using parted. Just provide it with the path to the image file instead of a block device.
root@debian:~# parted full_hd.dd GNU Parted 2.3 Using /root/full_hd.dd Welcome to GNU Parted! Type 'help' to view a list of commands.
Now switch parted to use ‘Byte’ units, then print the partition table:
(parted) unit B
(parted) print
Model: (file)
Disk /root/full_hd.dd: 8012390400B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1048576B 8012169215B 8011120640B primary ext4 boot
Keep a record of the ‘Start’ offset, you’ll need this shortly. Quit parted using the ‘quit’ command.
Let’s look into mounting the partition: pass the partition offset to the mount command using the ‘offset=’ option like this:
root@debian:~# mount -t ext4 -o loop,offset=1048576 full_hd.dd /mnt/test/
It may well be possible, that receive this error message as a result to your mount command if you try to mount the disk image read-only:
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
In this case, examining the system logs, may reveal something like this:
[ 8754.209469] EXT4-fs (loop0): VFS: Can't find ext4 filesystem
[ 8758.913583] EXT4-fs (loop0): INFO: recovery required on readonly filesystem
[ 8758.913587] EXT4-fs (loop0): write access unavailable, cannot proceed
To get around this, try adding the ‘noload’ option to skip journal recovery:
root@debian:~# mount -t ext4 -o loop,ro,noload,offset=1048576 full_hd.dd /mnt/test/
May 26th, 2012 at 7:43 pm
Thanks adding the noload option worked for me.
$ file system-2012-05-26.img
system-2012-05-26.img: Linux rev 1.0 ext4 filesystem data, UUID=7b2f96e2-c9ae-49ac-bad2-803ab58fa702 (needs journal recovery) (extents) (large files) (huge files)
Inspecting the image actually seems to reveal that the journal needs recovery. I wonder if there’s any harm to using noload or what would happen if you mounted the image as writable and let the journal recover?
May 27th, 2012 at 12:00 am
Well, that actually depends on the situation.
Let’s assume you just have such an image you want to mount read/write and you actually know everything is fine with it.
Then there’s actually no point in mounting it read-only and “noload” option to not recover the journal.
On the other, if your image is let’s say a dump of a crashed hard drive you were just lucky enough to recover with dd?
In this case you most propably might want to mount the image in read-only and with “noload” option so as to not change anything within the file system at first.
You may always try to read-write mount it with full journal recovery in a second step, then.
So, going back to your question: Is there any harm in using “noload”? — Not as long you mount it read-only anyways. But you might have the usual troubles of dirty file systems.
What happens if you mount read-write with journal recovery? — If the image is intact, nothing else as with a regurlar mount. If it is corrupt already (as from a hdd crash), a journal recovery might make things more worse than living with the “dirty” state of using r/o mount with “noload”.
Again, it always depend on what you actually want to do.