Unbootable VM after P2V of a Win2K with unusual CHS geometry

[kpv]

For several days, I've been trying to do a P2V of an old Win2K machine (Compaq Proliant with SmartArray 5i) into a VirtualBox VM, but get boot errors ("Missing Operating System") when trying to boot from the .vdi disk created from a .dd raw disk image.

I have basically followed the steps outlined in Migrate_Windows, taking the disk image with dd, and used "VBoxMange convertfromfaw ..." to convert it into .vdi, which I attached to the VM.

When I boot the VM from some LiveCD (both Linux e.g. SysRescCD, Gparted and Windows Win2K CD etc) the filesystems on the .vdi disk appear fine (I can mount the NTFS partition inside the .vdi and read its contents). But I can't get the VM to boot independently from the NTFS partition inside the .vdi.

I've booted the VM from the Win2K installation CD and used the Recovery Console and ran fixmbr/fixboot (RC found the c:\winnt), I also tried partclone.ntfsfixboot from SysRescCD, tried Gparted etc to no avail.

Since the the disk of the Win2K machine I'm trying to P2V uses a rather unusual CHS geometry of 8716/255/32, after some googling, it seems that my booting problem might be related to the issue described in removing-chs-based-access-from-windows_3170 (note: sorry but forum won't allow me to post URLs)

The VMware .vdmk format allows manual specification of disk geometry values, however I can't seem to find a similar tunable in VBox.

Are there any options, other than patching the Win2K bootloader or switching to VMware ?

[mpack]

I doubt that the CHS geometry is relevant. That geometry works out at 33GB or so, and the BIOS CHS support maxes out at 8GB, after which everything on the drive is addressed using LBA. The usual mistake when imaging a drive is to image the partition instead of the drive: in which case naturally the drive is not bootable.

If you still have access to the Win2k PC then you might try imaging it again with CloneVDI - as far as I know this should run on Win2K. Enter the Windows drive name in the source file, e.g. ""\\.\PhysicalDrive0" (replace the last digit with the actual drive number), and enter a name for a VDI file in the destination field - the destination path should lead to a USB (not FAT formatted!) or network drive, in fact any kind of secondary drive because CloneVDI can't usefully image a drive it's currently writing to. Also make sure no apps are running.

VERY IMPORTANT: Make sure the "Compact" option is set in the CloneVDI options as this will keep the image a workable size.

You can then build a VM around the VDI.

This isn't what CloneVDI was designed for, and hence while still better than any of your alternatives, it's less friendly than it could be: in particular you can't browse when using physical devices, so just type in the drive/filenames directly.

I'm surprised you ever went the cumbersome dd route. Linux users seem to love unnecessary pain, but Windows users generally don't.

[mpack]

Note for anyone coming to this thread later. If you were P2Ving XP or later then Disk2VHD would be an obvious choice, but the latter uses the Volume Snapshot Service which wasn't available in Win2K, hence the suggestion to use CloneVDI instead.

[kpv]

Thanks for the feedback.

The disk image(s) I'm using are indeed a full copy made of the entire "logical" disk /dev/sda (I say "logical", because actually it is a pair of physical disks in RAID1 on the Compaq SmartArray), not an image of some individual filesystem. I used "dd if=/dev/sda | gzip | netcat ..." to create them.

I've booted several LiveCDs and used Linux tools like fdisk, cfdisk and Gparted on those .dd images to check the partition table inside the .dd/.vdi, mounted the Win2k system's NTFS partition /dev/sda2 and viewed its files, ran Windows Recovery Console etc all inside the VM itself.

The .dd / .vdi disk of 36GB has two partitions:
1) /dev/sda1 a small 30MB hidden partition with Compaq EISA tools and
2) /dev/sda2 the Win2K system partition on NTFS, marked "active" (boot-flag set)

In all cases where I booted the Win2K residing on the NTFS partition via the Windows bootloader, I got a "Missing Operating System" error. Since I could view the NTFS partition's contents by all LiveCDs I tried (Linux & Win), I assumed it was due to brain-dead Win2K bootloader issue with CHS geometry.

Today I continued my efforts, testing two other ideas:

1) I booted the VM from SysRescCD patched the stock Win2K bootloader using the killchs.c code (clemens endorphin org/killchs.c‎) -- it found the Win2k bootloader in the NTFS partition (./a.out /dev/sda2) and successfully patched it, but when booting I still got the dreaded "Missing OS" error

2) installing Linux's GRUB2 on the NTFS partition, configured according to "How to switch a Windows MBR to Grub2" (using "grub2-install --root-directory=/mnt/sda2 /dev/sda" it installed itself under C:\BOOT\GRUB2). Note: I had to delete the 30MB Compaq hidden partition, otherwise grub2 didn't have enough room to install itself.

Grub2 (installed inside the NTFS partition) displayed the grub menu, but failed immediately when trying to booting Win2K:

Windows 2000 could not start because of a computer disk hardware configuration problem. Could not read from the selected boot disk. Check boot path and disk hardware. Please check the Windows 2000(TM) documentation about hardware disk configuration and your hardware reference manuals for additional information.

PS: I've tried attaching the .vdi disk to both BusLogic SCSI and IDE adapters on the VBox VM.

[kpv]

If you still have access to the Win2k PC then you might try imaging it again withCloneVDI - as far as I know this should run on Win2K. Enter the Windows drive name in the source file, e.g. ""\\.\PhysicalDrive0" (replace the last digit with the actual drive number), and enter a name for a VDI file in the destination field - the destination path should lead to a USB (not FAT formatted!) or network drive, in fact any kind of secondary drive because CloneVDI can't usefully image a drive it's currently writing to. Also make sure no apps are running.

Does CloneVDI do any Windows-specific tweaking (like VMware Converter or Acronis TrueImage) to ensure a smoother P2V migration? Because I believe that I already have accurate block-level images of all disks and the source Win2K system is a very old and slow Pentium3 with 10/100Mbps Ethernet NIC.

I'm surprised you ever went the cumbersome dd route. Linux users seem to love unnecessary pain, but Windows users generally don't.

Well, for me it was just a simple one-liner on both ends (after booting the Win2K system with a Linux LiveCD and make sure it recognized the Compaq SmartArray RAID controller and the Compaq 10/100Mbps Ethernet NIC. This way the imaging was faster too (5.5MB/sec).

[mpack]

No, CloneVDI doesn't do anything except image the disk directly to an VDI, with compaction to eliminate unnecessary space wastage. I'm sure you believe that you did the imaging correctly, and you're probably correct. But I do know that the mistake I referred to isn't even possible with CloneVDI because you don't get the option.

AFAIK TrueImage doesn't manipulate the image content either. VMWare Converter does.

The cumbersome nature of "dd" I was referring to is because it has no smarts regarding the image content. If you image a 1TB drive you get a 1TB image, even if there was only 100MB of data on the drive. So you need much larger disks to store the image on, and it takes forever to copy the darn thing from place to place.

[kpv]

The cumbersome nature of "dd" I was referring to is because it has no smarts regarding the image content. If you image a 1TB drive you get a 1TB image, even if there was only 100MB of data on the drive. So you need much larger disks to store the image on, and it takes forever to copy the darn thing from place to place.

Ah, I see what you mean, but I imagine this is more of an issue with newer systems that have large disks... The Win2K system I'm trying to P2V is very old Pentium3 system with 36GB and 146GB disks which are both nearly full, so it wouldn't really save space.

[kpv]

Quick followup, after a week of frustration with VirtualBox (4.2.18) I finally gave VMware Player a chance ...

I quickly hacked a CHS geometry of 8716/255/32 into the .vmdk of the 36GB .dd image of the Win2K's first disk (the same one I used with VBox's convertfromraw), which booted successfully, progressed several seconds into the Win2K graphical screen and progress bar, but eventually bombed with a blue screen with errorcode 0x0000007B INACCECSSIBLE_BOOT_DEVICE

[mpack]

That stop code usually means that you selected the wrong controller type. Note however that we do not support VMWare products here.

[michaln]

I quickly hacked a CHS geometry of 8716/255/32 into the .vmdk of the 36GB .dd image of the Win2K's first disk (the same one I used with VBox's convertfromraw), which booted successfully, progressed several seconds into the Win2K graphical screen and progress bar, but eventually bombed with a blue screen with errorcode 0x0000007B INACCECSSIBLE_BOOT_DEVICE

Welcome to Windows plug and play... so what storage controller was that machine set up with?

BTW VirtualBox should observe the geometry specified in the VMDK (or other format) file. Raw files of course have no geometry, which is why they kind of suck.

[kpv]

I quickly hacked a CHS geometry of 8716/255/32 into the .vmdk of the 36GB .dd image of the Win2K's first disk (the same one I used with VBox's convertfromraw), which booted successfully, progressed several seconds into the Win2K graphical screen and progress bar, but eventually bombed with a blue screen with errorcode 0x0000007B INACCECSSIBLE_BOOT_DEVICE

Welcome to Windows plug and play... so what storage controller was that machine set up with?

The physical server's boot disk is connected on a Compaq SmartArray 5i. The server's hardware specs can be found here. It's a very old system at an non-profit organization.

BTW VirtualBox should observe the geometry specified in the VMDK (or other format) file. Raw files of course have no geometry, which is why they kind of suck.

Can you please verify that VBox respects the geometry specified in the VDMK file (because I recall reading a post stating otherwise in the bug-tracking db) ?

I like VBox, but in this particular P2V project it gave me nothing but grief ...

[michaln]

The physical server's boot disk is connected on a Compaq SmartArray 5i. The server's hardware specs can be found here. It's a very old system at an non-profit organization.

A Pentium III-S with the ServerWorks HE-SL chipset. Sweet That was the good stuff in the Pentium 4 world...

The storage controller is definitely a problem. I don't really know what a "Compaq SmartArray 5i" is in terms of the SCSI HBA chip, but unless it happens to be the LSI Logic chip that VirtualBox and VMware emulate by sheer luck, that's the real problem. Do you know what the name of the Windows storage driver is?

At any rate, you'd somehow have to change the storage driver inside Windows, which is a fairly major surgery and not something Microsoft officially supported. I don't know if some kind of repair install would work. This is more of a question for Windows forums.

Can you please verify that VBox respects the geometry specified in the VDMK file (because I recall reading a post stating otherwise in the bug-tracking db) ?

[/quote]
Check the VBox.log file and search for 'CHS'. I believe the geometry may only be observed for IDE/SATA disks and the SCSI controllers synthesize their own (since SCSI drives do not have a geometry the way IDE drives do).

[kpv]

The storage controller is definitely a problem. I don't really know what a "Compaq SmartArray 5i" is in terms of the SCSI HBA chip, but unless it happens to be the LSI Logic chip that VirtualBox and VMware emulate by sheer luck, that's the real problem. Do you know what the name of the Windows storage driver is?

At any rate, you'd somehow have to change the storage driver inside Windows, which is a fairly major surgery and not something Microsoft officially supported. I don't know if some kind of repair install would work. This is more of a question for Windows forums.

I agree this is probably a question for Windows forums ... but I was that hoping someone else around here might have had to P2V a system with RAID disk hardware.

Can''t I just "inject" the drivers for the new virtualized hardware (e.g. VMware's vmscsi.sys) into Win2K's %systemroot%\system32\drivers\ before the P2V disk imaging ? Basically my question is, would Win2K attempt to boot from some new SCSI device, or would it insist that its old hardware be present?

I guess I'll find out tomorrow ...

[michaln]

Can''t I just "inject" the drivers for the new virtualized hardware (e.g. VMware's vmscsi.sys) into Win2K's %systemroot%\system32\drivers\ before the P2V disk imaging ? Basically my question is, would Win2K attempt to boot from some new SCSI device, or would it insist that its old hardware be present?

Adding the driver file is necessary, but not sufficient. Windows has information in the registry that says which services (drivers) should be started and how the driver objects are stacked. The system isn't really very flexible. The driver needs to be properly installed in Windows, but that's a bit hard if you can't boot it.

This page http://www.tim.id.au/blog/tims-f6-driver-guide/ suggests that a repair install is the way to go. Since you already have a virtual disk image and can use snapshots etc., that's probably worth a shot.

[kpv]

I would like to report that the Win2K VM created by the P2V process I undertook, has been booting and running fine under VMware for the past week.

I have also tried to boot the very same .vmdk/.dd disk images under Virtualbox (4.2.18), without success ("Missing Operating System"). Apparently VBox disregards the CHS geometry specified in the .vmdk files.

As others have requested in related reports at the bug-tracking database, it would be great if VBox would allow advanced users to manually specify CHS disk geometry.