vbox 3.10 could not boot on raw disk. => fixed in the 3.1.0_BETA1, and will be fixed in 3.0.12

[firemeteor]

I have a winxp system, configured to dual boot in both Virtualbox & real machine.

It works fine in 3.08. However, it refuses too boot once I updated to 3.10. It looks like the MBR & partition table are corrupted in 3.10. When I try to fix the problem using winxp install CD, it seems that writing to MBR does not take any effect, and the installer could not recognize partitions.

Thankfully, downgrade to 3.08 makes things back to normal.

The raw disk is built using commandline like this:

VBoxManage internalcommands createrawvmdk -filename sd3_xp.vmdk -rawdisk /dev/sda -partitions 3 -mbr hd.mbr

[Sven-Ola Tuecke]

Same here. After todays update from 3.0.8 -> 3.0.10, a raw vmdk disk was inaccessible. Reverting to 3.0.8 does does the trick. Host system is a i386-Ubuntu-Hardy with a WinNT4 guest. Here's a snipped from the vmdk:

# Disk DescriptorFile
version=1
CID=51495665
parentCID=ffffffff
createType="partitionedDevice"

# Extent description
RW 63 FLAT "winnt-data-pt.vmdk"
RW 1959867 ZERO
RW 58717575 ZERO
RW 173759040 FLAT "/dev/sda" 60677505
RW 5103 ZERO

# The disk Data Base
#DDB

ddb.virtualHWVersion = "4"
ddb.adapterType="ide"
ddb.geometry.cylinders="16383"
ddb.geometry.heads="16"
ddb.geometry.sectors="63"
ddb.uuid.image="578a427d-052b-4046-8329-4c818580c6dd"
ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
ddb.uuid.modification="71f1284b-2e8e-425c-bee4-5b592f445010"
ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000"
ddb.geometry.biosCylinders="1024"
ddb.geometry.biosHeads="255"
ddb.geometry.biosSectors="63"

And this is the physical disk layout:

fdisk -l /dev/sda

Platte /dev/sda: 120.0 GByte, 120034123776 Byte
255 Köpfe, 63 Sektoren/Spuren, 14593 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x0003fd02

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1               1         122      979933+  82  Linux Swap / Solaris
/dev/sda2   *         123        3777    29358787+  83  Linux
/dev/sda3            3778       14593    86879520    7  HPFS/NTFS

[scpcom]

I have the same problem with Ubuntu Hardy x64, VirtualBox 3.0.10 and WinXP x86 VM. I don't use the raw disk partitions to boot, but XP says "unknown partition", they should be NTFS. Worked fine with VirtualBox 3.0.8 and lower.

[scpcom]

My vmdk was created by VMware Server 1.08 Wizard. Here's a snipped from my vmdk.

# Disk DescriptorFile
version=1
CID=706d14d4
parentCID=ffffffff
createType="partitionedDevice"

# Extent description
RW 63 FLAT "SCPMAIN-2-pt.vmdk" 0
RW 29318562 ZERO
RW 13542795 ZERO
RW 63 FLAT "SCPMAIN-2-pt.vmdk" 63
RW 878916087 ZERO
RW 63 FLAT "SCPMAIN-2-pt.vmdk" 126
RW 878916087 FLAT "/dev/sda" 921777633
RW 63 FLAT "SCPMAIN-2-pt.vmdk" 189
RW 152826282 FLAT "/dev/sda" 1800693783
RW 5103 ZERO

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "4"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.geometry.biosCylinders = "121601"
ddb.geometry.biosHeads = "255"
ddb.geometry.biosSectors = "63"
ddb.adapterType = "buslogic"
ddb.uuid.image="9315616f-ece2-44a0-856e-d98204b72f23"
ddb.uuid.modification="760d149e-c658-40ed-8ab0-43007d7970ca"
ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
ddb.uuid.parentmodification="e17bcab6-ea88-45cc-8c1c-9982656b9579"

And this is the physical disk layout:

# fdisk -l /dev/sda

Platte /dev/sda: 1000.2 GByte, 1000204886016 Byte
255 Köpfe, 63 Sektoren/Spuren, 121601 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x90fe8397

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1               1        1825    14659281   83  Linux
/dev/sda2            1826        2668     6771397+  82  Linux Swap / Solaris
/dev/sda3            2669      121601   955329322+   5  Erweiterte
/dev/sda5            2669       57378   439458043+  83  Linux
/dev/sda6           57379      112088   439458043+   7  HPFS/NTFS
/dev/sda7          112089      121601    76413141    7  HPFS/NTFS

[dterrahe]

Similar problem here. Host Win7 64-bit. Guest Debian 64-bit. Worked fine when I was still running Vista 32-bit as the host. Upgraded to 7/64 but kept the same vmdk files. Seemed a little bit more unstable (maybe because I enabled the 2nd processor core for the guest) so was hoping some of that was solved with 3.0.10. Now when I boot I only get the first stage of Grub2 and then "error: no such disk Entering rescue mode..." The debian boot partition was in sda1, the rest of the partitions in an LVM in sda3. Win7 is installed in sda2, which is not read-write in the vmdk file. When I boot the same virtual machine but attach an Ubuntu 9.10 iso and start from it in live-cd mode, I do see the correct partition map, but sda1 seems to contain rubbish.

Downgrading to 3.0.8 makes it work again, but I do have occasional lock-ups there which may already have been solved in 3.0.10.

[Klaus Espenlaub]

Confirmed the regression. Doesn't look very difficult to fix. The OSE repository already has a fix for the immediate problem.

[idlecoder]

I've fixed this problem on my installation: In the VMDK file (ex: winxp.vmdk) I changed the following : RW 39070017 FLAT "/dev/sda" 63 to: RW 39070017 FLAT "/dev/sda1"

where sda1 is my windows partition... Else, try to generate a new vmdk file with -partition and -relative options, it made a line like "/dev/sda1" in my new vmdk, instead of "/dev/sda" 63... So I've modified my old vmdk and everything works for now... PS: Before doing this, I've tried to change the MBR, use a pseudo grub-livecd to boot, etc. with no success...

[f.hoefling]

I can confirm the same bug after updating to 3.0.10-54097_Ubuntu_jaunty from the previous 3.0.10-5xxxx.

Thanks a lot idlecoder! Creating a VMDK file with the -relative option and a virtual MBR fixed the problem for me too. (But this doesn't fix the bug.)

[fcrespel]

I also encountered this bug, however my case led to damaging the physical partition table!

I have a Windows XP VM installed on a raw NTFS partition (/dev/sda2), with a Linux host (/dev/sda9). On the physical hard drive, the MBR contains GRUB and the active partition is /dev/sda1. In the raw VMDK, the virtual MBR is a standard one (no GRUB) and the active partition is /dev/sda2.

After updating to VirtualBox 3.0.10, the VM didn't boot anymore and failed with a GRUB error message, as if it was using the real MBR instead. Without thinking, I tried doing what I usually do after creating/updating the raw VMDK: fixmbr and fixboot in the Windows XP Recovery Console (from the CD).

After rebooting the VM, it failed again to boot with a message saying NTLDR is missing. So, foolishly, I tried rebooting the real machine to try with a Windows XP host (as I also have a raw VMDK to boot the VM in there). No way. The REAL machine now displayed "NTLDR is missing", without even loading GRUB.

I then booted from a Linux LiveCD to restore GRUB, but had a very bad surprise. The entire partition table was corrupted, displaying inconsistent/invalid partitions (unknown type, wrong start/end, wrong size, wrong number.. everything random, it seems). It could have been a small disaster if TestDisk hadn't saved the day by reconstructing the partition table (I have backups for the most important things, but not everything - and it would have made me lose a lot of time to restore everything).

For me, it clearly shows VirtualBox used and wrote in the physical MBR instead of the VMDK one, leading to critical damage to the partition table. I can only blame my own stupidity for not reacting before rebooting the real machine, but still. Please release a fix ASAP! For now I'll try recreating the raw VMDK or downgrade to 3.0.8...

[Klaus Espenlaub]

Replying to fcrespel:

I also encountered this bug, however my case led to damaging the physical partition table!

You can only destroy something by trying to "repair" something which isn't broken, namely the raw partition configuration. Normal use of a raw partition setup will fail to mount filesystems, and thus will never write to the wrong place on the real disk.