I do most everything computer-wise with open source software, but the one hold out remaining that requires the use of a proprietary OS is TurboTax. As a result, TT ran in a Windows XP virtual machine under VirtualBox on my Linux desktop. Unfortunately, after completing our most recent return, I got a little excited to do some basic housekeeping and tried to merge snapshots from the VM in order to save some disk space. Unfortunately, as the attempt at merging snapshots resulted in an error being reported by VirtualBox that basically amounted to “you’re really screwed, buddy” but put in much geekier terms with a bits and bytes error code. A later attempt to re-merge or boot the VM again did not work. The virtual machine claimed that key windows files (like the kernel) were not available. Argh!
OK, so I’m usually pretty careful and save off critical files from the Windows VM to the Linux host. I sadly did not do that for the very-last-as-filed TurboTax working file (I had an interim copy from several hours earlier but I know we made changes later). Had the pdf copies of our returns but not the final version of the .tax2011 file, which normally copies over key details to our next year’s return. And of course, hadn’t yet set up SpiderOak to backup the files from within the VM to the cloud. Double argh!
As the VM would not boot, I tried various alternative boot scenarios to get at the files but none of them worked, using either a Windows install CD or a Linux live CD image within the VM. Furious Googling finally turned up a useful working solution to allow access the files on the Virtual Disk Image (VDI) associated with the VM. Was then able to copy out the files needed from within the virtual Windows environment to native Linux file storage. Phew, dodged that bullet! Here’s what I did under Linux Mint LMDE 64-bit to get access and then clean up afterwards:
Install Required Packages
Using Synaptic, installed the
qemu-utils package, which dragged along a bunch of dependency packages.
Gain Access to the Disk Image
Within a terminal window, executed the following commands:
lsmod | grep -i nbd
Nothing was returned, so the nbd module was not loaded already. Loaded it:
sudo modprobe nbd max_part=16
qemu-nbd to expose the entire unbootable image as a block device named /dev/nbd0, and the partitions within it as subdevices.
sudo qemu-nbd -c /dev/nbd0 WinXP_VirtualBox.vdi
The referenced blog posting/commentary said to issue a
partprobe command, but I got an error about it not being available and didn’t seem to need it as the partitions were visible without it. Could see this by:
ls -l /dev/nbd*
To determine partition details:
sudo fdisk /dev/nbd0
This revealed the desired Windows NTFS partition from the virtual disk:
Disk /dev/nbd0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 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: 0xdc94dc94
Device Boot Start End Blocks Id System
/dev/nbd0p1 * 63 20948759 10474348+ 7 HPFS/NTFS/exFAT
Access and Copy Off Files
OK, so create a mount point for the virtual disk and mount it READ ONLY:
sudo mkdir RECOVER
sudo mount -t ntfs -r /dev/nbd0p1 /RECOVER
Finally I could look at that mount point and recover the files:
Once I got all that I needed off the VDI, unmounted the image and shut down the
sudo umount /RECOVER
sudo qemu-nbd -d /dev/nbd0
Then used Synaptic to remove all the qemu packages I’d just installed, to prevent the accretion of bloat hopefully never needed again. I’m trying to keep this Mint LMDE install tidy and avoid an OS reinstall for a good long time!