Error loading operating system after importing OVA

[fth0]

Note that I said that the error means that a boot sector was found at sector 0, so you are not showing the important sector - we already knew that sector 0 was good.

Well, I appreciate seeing the MBR and the partition table, and re-learning something from my past:

The MBR is most likely a (Windows 2000/XP MBR). Depending on the drive geometry returned by Get Drive Parameters (INT 13h function 08h), the MBR code will either use Read Sectors (INT 13h function 02h) with the CHS First Sector values (0,1,1), or Extended Read Sectors (INT 13h function 42h) with the LBA First Sector value (56).

The partition table would be fully consistent if the drive really had 56 SPT (Sectors Per Track). Therefore, I suspect that the returned drive geometry is (1023,254,63) and sector 63 is read instead of sector 56. But it could also be the other way around, so I'd take a look at both sectors 56 and 63.

If I'm suspecting correctly, wouldn't it be better to patch the VDI header instead of the MBR (and the VBR)?

[mpack]

If I'm suspecting correctly, wouldn't it be better to patch the VDI header instead of the MBR (and the VBR)?

I doubt that patching the VDI header will change the behaviour. LBA addressing in a VDI drive is not affected by drive geometry. The boot partition either does or doesn't begin on sector 56. If it does then that's very unusual, the usual starting sector for this era being 63.

[fth0]

My rationale is that the VirtualBox BIOS implementation of Get Drive Parameters (INT 13h function 08h) gets the drive geometry (1023,254,63) from the VDI header (that's a guess for now, I didn't check in the sources/binaries). If this is the case, and the boot sector is on sector 56, then patching the VDI header could be an alternative solution.

[Lucmove]

Hi. I am struggling with the exact same problem, down to the 56 LBA First Sector. Has a solution been found?

TIA

[mpack]

The solution was mentioned above. Find out where the system partition actually begins, and patch the MBR to suit. It's possible that "fixboot" type tools would do this for you, but personally I'd just use a hex editor.

Where did this XP image come from? No way you installed it yourself and got a start sector of 56.

[Lucmove]

The solution was mentioned above. Find out where the system partition actually begins, and patch the MBR to suit. It's possible that "fixboot" type tools would do this for you, but personally I'd just use a hex editor.

Where did this XP image come from? No way you installed it yourself and got a start sector of 56.

Yes, I installed it myself but on VMware where it boots just fine, then I imported it into VirtualBox this week. It won't boot on VB.

Ideally, I could install it again directly on VirtualBox, but 1) I've gone through many old boxes and can't find the original CD, and I don't want to use a pirated copy and 2) it is already customized to just the way I like it and I was hoping I wouldn't have to do it all over again. The worst problem is that I can't find the original CD. I've been using Linux and XP on VMware occasionally for so long I ended up burying that item somewhere. I am a male so you see, I keep a lot of old "techie" junk in boxes and drawers.

And I have no idea how to patch an MBR.

[Lucmove]

Well, this is messed up.

I just upgraded to Version 6.1.16 r140961 (Qt5.7.1) then I imported the virtual machine from VMware all over again.

But this time, the VM image contained this utility:
https://www.ambience.sk/fdisk-master-bo ... fixmbr.php

Then I booted from a live XP boot CD called "FalconFour Ultimate Boot CD". I ran a DOS session and ran the utility.

I had two choices:
1) mbrfix /drive 0 fixmbr
2) mbrfix /drive 0 restorembr mymbr

Note that I had stored the MBR from the VMware image running on VMware as a file named "mymbr".

I tried number 1, rebooted, and it failed.
I tried number 2, rebooted, and it failed.

I have run out of ideas so I am giving up on this. I will have to keep using that VM on VMware.

Before I did all this, though, I ran another option of the mbrfix utility:

C:> mbrfix /drive 0 driveinfo > driveinfo.txt

I ran it on VMware and got this:

on VMware

before.png (13.3 KiB) Viewed 1785 times

Then I imported the VM into VirtualBox, ran the same command and got this:

on VirtualBox

after.png (13.28 KiB) Viewed 1785 times

They are not the same.

If this makes the issue easier to understand to anyone here, please help.

If nobody knows, I will just give up.

TIA

[jds]

Well, four years down the track, and I too have been bitten by this very nasty bug! I used version 5.2.44 (released July 2020), as this is apparently the latest version that can run on a 32-bit host.

This issue is actually the same as per thread 56195, originally from June 2013. It's very tragic that at least 7 years later (per version 5.2.44), this bug had still not been addressed! Incidentally, that thread was closed/locked by socratis on 2019/12/09, stating "Once again... VirtualBox does not modify your VMDK, period. Your Guest OS is the only one that can do that. Please stop spreading misinformation."

I had a small MS-W2000 VMDK from VMware that I tried to load into VB, and immediately got the error message "Error loading operating system", when I tried to run the VM. After this, the WMDK was likewise broken in VMware.

Looking into this, I found that this error message actually comes from the MBR boot code, which means that the Guest OS never actually had a chance to run. So unless the MBR code is suspected to write to its drive, there is no way that the above "VirtualBox does not modify your VMDK, period. Your Guest OS is the only one that can do that." assertion holds any water.

Investigating further into this, I realised that the original drive format had 56 sectors/track, whereas the now-broken VMDK header indicated 63 sectors/track (obviously, the number of cylinders and heads must also have changed). So I did an experiment. I created a new dummy VMDK in VMware, loaded it in VB, then exited without even running the VM. Lo and behold, the VMDK file was changed! Most pertinently, the header included the following changes :
from ...
ddb.geometry.cylinders = "293"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "56"
to ...
ddb.geometry.cylinders = "0"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"

So simply attaching this VMDK in VB, without even running the VM, changed the CHS geometry of the drive!!! No wonder the VMDK is then broken! The partition System ID in this case was 6, which means FAT16B, and which relies on CHS addressing. When the MBR boot code asked for CHS sector 0:1:1 (the start of the partition), instead of getting sector 56 (per the original format), it got sector 63, which it rejected as this lacked the correct signature.

Studying my original (now broken) VMDK and the dummy VMDK that I had experimented with, it seemed that the first $2A00 bytes were the header structure that VB had messed with, so I transplanted these bytes from the unadulterated dummy VMDK file back into my original/broken VMDK file. Voilà! My original WMDK was now working again in WMware! And I will never let VB touch it or any other of my WMDK files ever again!

Joe.