Just recently, I needed to mount a KVM raw image file, because it was depending on a network mount that was no longer accessible, and any attempts to interact with the boot process failed. So, rather than booting off a live CD, or some other medium, I decided to mount the raw image file. After all, it is ext4.
However, mounting an image file means knowing where the root filesystem begins, which means knowing how to offset the mount, so you can access your data correctly. I used the following:
First, I setup a loop back device, so I could gather information about its partition setup:
# losetup /dev/loop0 virt01.img
# fdisk -l /dev/loop0
Disk /dev/loop0: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 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
Disk identifier: 0x0009bdb7
Device Boot Start End Blocks Id System
/dev/loop0p1 37943296 41940991 1998848 82 Linux swap / Solaris
/dev/loop0p2 * 2048 37943295 18970624 83 Linux
Partition table entries are not in disk order
In this case, the virtual machine filesystem is 21.5 GB in size, in reads and writes in 512 byte blocks. Further, it appears as though swap occupies the second partition, while the ext4 root filesystem occupies the first, and begins at sector 2048, or byte 2048*512=1048576.
So, now I just need to tear down the loop back device, and create it again with an offset of 1048576 bytes, at which point, I should be able to mount the device:
# losetup -d /dev/loop0 # losetup /dev/loop0 virt01.img -o 1048576 # mount /dev/loop0 /mnt # ls /mnt bin/ home/ lib32/ mnt/ run/ sys/ vmlinuz@ boot/ initrd.img@ lib64/ opt/ sbin/ tmp/ vmlinuz.old@ dev/ initrd.img.old@ lost+found/ proc/ selinux/ usr/ etc/ lib/ media/ root/ srv/ var/
At this point, I can edit my problematic /mnt/etc/fstab file to fix the troubled boot, and boot it up.