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.