virtualbox.org

I'm currently running Windows XP SP3 as a guest on both a Linux and OpenSolaris host. I have tried MyDefrag version 4.2.3 and 4.2.5 from within the Windows guest. Version 4.2.3 results in an unbootable disk while 4.2.5 has consistently kept the disk bootable. The author suspects that there is something different with the way the boot works with the virtual disk vs a physical disk and as MyDefrag is issuing commands to the Windows OS to move the data, it is moving a specific file that is required to permit the boot to occur.

Any insight into the difference, if any, in the way a VM boots using the standard Windows XP boot manager as opposed to a physical disk? Or any difference in the way the MBR of a Virtual Disk is represented that is different than what it would look like on a physical disk?

Wild guess: Are you using raw disk access to hold the WinXP partition? VirtualBox 3.0.10 has a problem with raw disk access.

Nope. Normal VDI with 3.0.8 on OpenSolaris and 3.0.10 on Ubuntu.

There is no difference from the OS point of view. If you get an unbootable system, it's a bug in the program that defrags your data.

There is no difference between the MBR of a physical vs a virtual PC: in fact there can't be, because it's put there by the same software in both cases, and that software is not aware of the distinction between physical and virtual.

However the pedant in me cannot avoid noting: the MBR should not be relevant to a defrag utility, because defrag is applied to a partition, and the MBR is not stored inside any partition. A bootable partition on a Windows system starts with a volume boot sector: this is mapped as a file in the NTFS filesystem, but of course must not be moved. There is also a backup boot cluster, I believe that can be moved, but it should be to somewhere sensible (making it contiguous with the primary copy is not sensible! - but may not cause any immediate harm either).

(*) A note for posterity. A similar question I investigated and answered for myself yesterday: does VirtualBox actually execute the code in the MBR? Or does it parse the partition table and go directly to executing the code in the partition boot sector? Answer: it does indeed execute the MBR code.

Another thought occurs to me...

jpbrown wrote:Version 4.2.3 results in an unbootable disk while 4.2.5 has consistently kept the disk bootable.

What is the exact error message or symptoms you get when the disk is not bootable?

For information regarding MBRs may I suggest the following site: http://thestarman.narod.ru/asm/mbr/index.html#MBR

jpbrown wrote: any difference in the way the MBR of a Virtual Disk is represented that is different than what it would look like on a physical disk?

If you want a definitive answer I would suggest making a backup of your MBRs using mbrfix.exe and comparing them in a hex editor. The main website for downloading mbrfix.exe seems to be down at the moment but this link will give you some answers regarding use of mbrfix: http://www.sysint.no/nedlasting/mbrfix.htm

jpbrown wrote:I have tried MyDefrag version 4.2.3 and 4.2.5 from within the Windows guest.

I use MyDefrag too. I've noticed my VM being slow after using versions prior to 4.2.5. Yes, the author does only access the windows api, but he also made some bug fixes so I would suspect part of the problem being with the older version of MyDefrag. With 4.2.5 I have not experienced any slowing down of my VM

Thanks for all the feedback.

Code: Select all

What is the exact error message or symptoms you get when the disk is not bootable?

The message is:

Code: Select all

A disk read error occurred
Press Ctrl+Alt+Del to restart

I can mount fixntlrd.iso and using its first, default method to access the disk, boot. But I just can't boot from the virtual disk directly.

"Disk read error" is reminiscent of very low level errors, e.g. attempting to read a bad sector or a sector number that doesn't exist on the drive. This would make me suspicious of the defrag software, assuming a chkdsk prior to the defrag showed no drive errors. Obviously there cannot be any real bad sectors on a virtual drive.

mpack wrote:"...Obviously there cannot be any real bad sectors on a virtual drive.

I was just wondering if bad sectors on the physical HDD would be reflected in the virtual drive?

Here is a tool that would help there. It also assists with MBRs. http://www.cgsecurity.org/wiki/TestDisk

I was just wondering if bad sectors on the physical HDD would be reflected in the virtual drive?

That's a great question. I'll double check the physical disk on my Ubuntu box. On my OpenSolaris box which is also seeing the exact same problem I'm using mirrored zfs and it all checks out perfectly ok.

I wonder if the virtual disk characteristics (heads, blocks, LBA...) could be a problem. The images I use began with Windows XP installed on a physical hard drive. I used Clonezilla several years ago to save off the image retaining the NTFS file system (not a bit for bit copy but used the NTFS functionality in clonezilla). I then put Ubuntu down on the laptop and added VB and a virtual disk which was the same size as the physical hard disk of the original image (80 GB), allowing it to grow as needed. This base image I've cloned several times, removed software I didn't need in the new image. The original physical disk was an IDE drive. I added the Intel Storage Matrix software to the image and switched VB to access it as SATA instead of IDE. All has been fine. Chkdsk with repair options all show no issues on the disk prior to defrag.

Could I have a difference in something that Windows XP captured from the original physical disk and the characteristics of the virtual disk? I'm thinking that perhaps NTFS is thinking things are located in one location while VB's disk is slightly different and it causes a problem when I'm defragging something near the contents of the MBR or the partition boundary. But when I use fixnltdr.iso to boot into the image, all looks great. I'll try some of the other utilities mentioned here.

The one thing I haven't yet tried is to do a clean install of Windows XP. I've always used clones of the original image.

Etepetete wrote:I was just wondering if bad sectors on the physical HDD would be reflected in the virtual drive?

Nope. A virtual drive is just another user data file, and how often do you encounter bad sectors in data files? In a Word document say? They don't occur any more often in VDI files, just because that kind of file is pretending to be a disk drive.

Bear in mind that a physical disk error is a host fault (a simulated drive can only have simulated faults!), hence my guess is that it would be reported as a host fault by VBox rather than silently handled as a guest fault.

I dug through the VirtualBox log to see what additional information I could find on why I wasn't able to read from the disk to boot.

What is the exact error message or symptoms you get when the disk is not bootable?

BIOS: int13_harddisk: function 02, parameters out of range 0001/0021/001a!

I did pull down the mbrfix.exe, backed up the MBR, ran a fix, backed it up and did a compare -- they are identical. Tried to boot -- same problem. That makes sense since it doesn't appear to be the MBR but perhaps something more related to disk geometry.

Diskpart reports:

Code: Select all

VBOX HARDDISK
Disk ID: 4DF4504C
Type    : IDE
Bus      : 2
Target  : 0
LUN ID : 0

mbrfix reports:

Code: Select all

Drive 0
Cylinders = 166440
Tracks (heads) per cylinder = 16
Secotrs per track = 63
Bytes per sector = 512
Disk size = 85899018240 (Byts) = 79 (GB)

VBox Log:

Code: Select all

00:00:02.425 AHCI: LUN#0: disk, PCHS=16383/16/63, total number of sectors 167772160
00:00:02.425 AHCI: LUN#0: using normal I/O
00:00:02.425 AHCI ATA: LUN#0: disk, PCHS=16383/16/63, total number of sectors 167772160
00:00:02.425 AHCI ATA: LUN#1: no unit
00:00:02.425 ATA: Ctl: finished processing RESET
00:00:02.535 AHCI ATA: LUN#0: no unit
00:00:02.535 AHCI ATA: LUN#1: no unit
00:00:02.535 ATA: Ctl: finished processing RESET
00:00:02.635 ATA: Ctl: finished processing RESET
00:00:02.735 ATA: Ctl: finished processing RESET

00:00:02.848 DevPcBios: SATA LUN#0 LCHS=1024/16/63

I think I next have to figure out what the BIOS error message really means:
BIOS: int13_harddisk: function 02, parameters out of range 0001/0021/001a!

jpbrown wrote:I wonder if the virtual disk characteristics (heads, blocks, LBA...) could be a problem. The images I use began with Windows XP installed on a physical hard drive.

Yes, and I had exactly the same error message at boot because of heads/cylinders when I P2V'ed my guest.
(Although I wouldn't have thought it would suddenly develop after a defrag...)

The fix was to boot UBCD4WIN on the VM and fix the ~~MBR~~ Volume Boot Record:

Find the correct disk characteristics with Easeus Partition Manager: Start>Programs>Disk Tools>Partition>Easeus Partition Manager>(Select disk)>Right-click>Properties>Partition Info>Physical Geometry
(I could be wrong about how I found the physical geometry, but I found it somehow...)
Fixup the ~~MBR~~ Volume Boot Record with the correct values: Start>Programs>Disk Tools>Partition>BootBuild>File>Read from disk>(Select drive)>OK>Edit ~~Sectors Per Track and~~ Number of Heads>File>Write to disk>(Select drive)>OK

YMMV.

Edit: UBCD4WIN is a largeish download (255MB). Instead, you can download just the tools needed:
Easeus Partition Manager can be downloaded separately
Edit: ~~hdparm for Windows can also show the correct geometry, use the -g option. Either run the setup program at the link above or extract the EXE from the ubcd4win-plugin ZIP.~~ I'm not sure hdparm reports the correct number... The correct number is 255 anyway for virtual hard disks > 8GB.
Roadkils' Boot builder can be downloaded separately from UBCD4WIN.

jpbrown wrote: mbrfix reports:
Code: Select all
Drive 0
Cylinders = 166440
Tracks (heads) per cylinder = 16
Sectors per track = 63
I think I next have to figure out what the BIOS error message really means:
BIOS: int13_harddisk: function 02, parameters out of range 0001/0021/001a!

Int 13h function 2 is the legacy disk read function in the BIOS - "legacy" meaning it uses CHS addressing instead of LBA. I assume the parameters given in the error message are the C,H,S values passed, in which case they are indeed out of range (H(21h) is greater than Heads(16)).

The disk geometry is not stored in the MBR btw, so I'm not sure what Marks's fix does. Perhaps it uses the drive geometry to correct the partition table, each entry of which has CHS addresses for start and end of partition. With a partition size of 8GB or more the end CHS values are usually maxed out, so only the CHS start address would matter, and that nearly always has a fixed value: 0,1,1 for the first partition.

virtualbox.org

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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