My Windows 10 vm under LXD has stopped working and I am unable to get it started but I’d like to get some data off the root.img file /var/snap/lxd/common/lxd/storage-pools/lxd/virtual-machines/win10/root.img
Is there a way to do this? I’ve tried mounting on loopback, etc and can’t find anything that works.
Here is gdisk -l root.img:
GPT fdisk (gdisk) version 1.0.8
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk root.img: 104857600 sectors, 50.0 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 1A40A062-3100-4020-866C-9471A36E34FD
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 104857566
Partitions will be aligned on 2048-sector boundaries
Total free space is 104857533 sectors (50.0 GiB)
As to why it stopped working, the boot process is hanging on a not found error for the qemu hard drive and a timeout on the cd-rom and eventually i get the boot shell.
One thread had mentioned using an hwe kernel as a workaround but my zfs is stuck at 2.1.6 for now and won’t work on 6.xxx kernels and I’m reluctant to recompile to a higher version (root on zfs)
You can use kpartx to map the root.img to devices in /dev/mapper, that will give you per-partition devices which you can then mount.
Should be something like kpartx -a /var/snap/lxd/common/lxd/storage-pools/lxd/virtual-machines/win10/root.img then use ls -lh /dev/mapper to locate the partition you want and finally mount it with mount /dev/mapper/XYZ /mnt
PS: LXD is no longer part of Linux Containers, support is now handled by Canonical on their forum instead.
root@upstairs:/var/snap/lxd/common/lxd/storage-pools/lxd/virtual-machines/win10# kpartx -a /var/snap/lxd/common/lxd/storage-pools/lxd/virtual-machines/win10/root.img
root@upstairs:/var/snap/lxd/common/lxd/storage-pools/lxd/virtual-machines/win10# ls -lh /dev/mapper
total 0
crw------- 1 root root 10, 236 Oct 17 21:59 control
root@upstairs:/var/snap/lxd/common/lxd/storage-pools/lxd/virtual-machines/win10# mount /dev/mapper/control /tmp/mnt
mount: /tmp/mnt: /dev/mapper/control is not a block device.
root@upstairs:/var/snap/lxd/common/lxd/storage-pools/lxd/virtual-machines/win10#
Maybe root.img is corrupt? I went back to previous copies of root.img and they are all showing like this:
GPT fdisk (gdisk) version 1.0.8
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk root.img: 62914560 sectors, 30.0 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 6BE9AFB4-8D96-4266-822A-860F0F659B31
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 62914526
Partitions will be aligned on 2048-sector boundaries
Total free space is 62914493 sectors (30.0 GiB)
gdisk has some support for partition table recovery by looking at the backup location of the GPT table, though I would have expected it to report that the two are out of sync in your ouput above which it didn’t…
You may need to use actual disk forensics tooling to try and figure out exactly where the partitions should be and then fix your partition table, hoping that the data within the partitions is still fine.
testdisk used to be the goto last time I had to deal with this.