Is the MBR of a virtual disk the same as a physical disk?

Discussions related to using VirtualBox on Linux hosts.
jpbrown
Posts: 18
Joined: 11. Sep 2008, 01:49

Re: Is the MBR of a virtual disk the same as a physical disk?

Post by jpbrown »

Mark's fix and instructions worked perfectly. Since making the change, I've gone back to the MyDefrag 4.2.3 which was causing problems and it now works without causing the problem. Thanks Mark!

But now I'm perplexed. I have a working hypothesis that it was the moving of $MFT with the bad geometry stored on the NFTS volume that caused the problem -- perhaps calculating a different location based upon one geometry (either in the BPB or vdi's disk geometry). But if this were the case, why can I still boot using fixntldr.iso which I'm assuming would use the partition info to find $MFT. Perhaps it is further back that an adjustment to the MBR was done to point to the location of the partition and the calculation done with the bad geometry in the BPB was used, resulting in a new location being placed in the MBR even though the partition didn't move. I have more digging to do.

Thanks all for your help.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Is the MBR of a virtual disk the same as a physical disk?

Post by mpack »

If patching the MBR fixed the problem then the problem was not that $MFT moved. The partition boot sector (first sector of your NTFS partition) has a reference to the location of the MFT (and MFTMirr), but the MBR doesn't. The only explanation I can think of is that you had a bad partition table (illegal CHS values) - but if the problem is corrected then it's too late to check that now.
jpbrown
Posts: 18
Joined: 11. Sep 2008, 01:49

Re: Is the MBR of a virtual disk the same as a physical disk?

Post by jpbrown »

but if the problem is corrected then it's too late to check that now
I actually still have a snapshot that still contains the disk state prior to making any changes using bootbuild. If you'd care to guide me through how to check the integrity of the partition I'd be happy to revert the disk state back to that spot.

This morning I did go back to that state prior to applying change with bootbuild, ran the Easeus Partition Manager and had it check the partition and run chkdsk -- both completed and reported all was good. I then wanted to get the system back into the unbootable state so ran MyDefrag 4.2.3 and as expected got an unbootable system. I then booted with UBCD4WIN and applied the change to MBR/Partition using bootbuild. On my system, my sector number was correct, but the head count was 255 instead of 16. After changing that and writing it back to disk, I rebooted. The system booted fine. So, some part of the boot sequence must look to the parition's BPB for the stored geometry. One would have thought that I'd have had the problem 2 years ago, but the files must have been in just the right spot -- defrag moved one, perhaps causing logic to be invoked that then required looking at the geometry.
MarkCranness
Volunteer
Posts: 875
Joined: 10. Oct 2009, 06:27
Primary OS: MS Windows 7
VBox Version: PUEL
Guest OSses: Windows Server 2008 R2; Ubuntu 11.04; Windows 2000 Server; Windows XP

Re: Is the MBR of a virtual disk the same as a physical disk?

Post by MarkCranness »

FYI, some sleuthing shows that BootBuild is storing the 'Number of Heads' value @ offset 0x1A (26 decimal) of the Windows' Volume Boot Record (aka Partition Boot Sector), which is the NumberOfHeads field in the BIOS parameter block.

All about BIOS parameter blocks : '0x1A - number of heads - This is the logical disc geometry, as it appeared to the tool that high-level formatted the volume. This field is used by boot code in the remainder of the boot block to translate logical block addresses into Cylinder/Head/Sector addresses, on systems where the machine firmware does not support the EDD firmware extensions'

How NTFS Works : '0x1A - Not used or checked by NTFS'

(It is ALSO clearing the 4 bytes at offset 0x4C - 4F to zero, which is the last 4 bytes of the 8 byte Volume Serial Number, I'm not sure why it would do that, and Windows seems to only report the first 4 bytes anyway...)

[Edited about a million times...] I think what's happened is this: MyDefrag moved something read by the VBR boot code. That something before it was moved just happened to have an INT13 head number < 16. After the move, it just happened to have a head number >=16 (0x21 in fact), which when passed to INT 13H, caused the 'A disk read error occurred' error.
Post Reply