The setup in question is as follows: Windows 7 64bit host running VirtualBox. The guest machine is running Windows XP 32bit.
After a power failure on the host box, the guest machine cannot boot and complains that
inconsistency between grain table and backup grain table
Any help to boot the guest machine without reinstalling it appreciated.
PS: What is a grain table anyway?
VMware has a tool called
vmware-vdiskmanager
located in"/Applications/VMware Fusion.app/Contents/Library/"
and symlinked to/usr/local/bin
when installed. You can use this tool to repair VirtualBox VMDK disks as well. It saved me a couple of times already.Installation
a. You can install vmware-fusion (requires macOS Catalina; use
vmware-fusion10
for older macOS versions)b. Or you can download the
vmware-vdiskmanager
utility directly from Attachments section at the bottom of this page:http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023856
Usage
Invoking without parameters gives help usage:
Can't really help, but I found what the grain tables are here: http://www.vmware.com/support/developer/vddk/VirtualDiskAPIprogramming.pdf (page 16)
Like the user mailq says, looks like your virtual drive is broken. Maybe check the vmdkck tool (on this page http://datto.org/projects/vmdk-tools ) to double check it's broken?
Your virtual hard drive is broken. Grain tables are some internal stuff of virtualization environments.
Googling for the exact term reveals that there are not many possibilities to recover: https://forums.virtualbox.org/viewtopic.php?f=6&t=40049
I used CloneVDI to solve this problem. I made a clone and the new file works very well.
I had this error after moving my
~/VirtualBox\ VMs
from Linux to MacOS. I tried @mens solution usingvmware-vdiskmanager
, but it failed for me.During my migration from linux to MacOS, I added all of the
*.vbox
files back into Virtualbox and they all failed to boot with the same error (using vagrant):I verified that the data transfered correctly,
md5 box-disk1.vmdk
returned the same thing for both files.I managed to get a vm to boot again by converting the
vmdk
files tovdi
doing the following. (Requiresqemu
,brew install qemu
)Updated path to volume for
.vdi
and machine booted.In my case, vdi file is slightly larger, don't forget to delete
.bin
as it's huge. Oh and it fails to authenticate on first run. Anyway, if possible, maybe you should spin up a new vm from scratch instead.