Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm trying to boot an existing Windows XP installation under Linux. It was a piece of cake under VMWare Fusion, but I've been pulling my hair out to do the same thing on Ubuntu 10.10.

First I tried VMWare Server. (The virtual machine is a network service.) After much effort, Windows does seem to boot, but there's no console interaction so I can't enter the Windows license key, and VMWare itself seems to crash often. It's officially at the end of support, so I guess it's not a good idea under recent Ubuntu desktop.

VirtualBox installs very easily, and I can boot the .vmdk file I was using under VMWare. Unfortunately, the process has taken too long and I need to use a new machine image. I used these commands to clone the disk again:

sudo dd if=/dev/sdf2 of=powerhouse.dd
VBoxManage convertfromraw powerhouse.dd powerhouse.vdi

But I keep getting this message and no OS:

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

My guess is that I'm trying to boot an unpartitioned image. Can I add a partition map to the existing VDI, or what is the correct process to do this? (And aren't unpartitioned images just an obsolete annoyance in this day and age?)

share|improve this question
add comment

2 Answers 2

up vote 2 down vote accepted

This can be a complicated process to get exactly right. There are instructions on the VirtualBox.org page that describe a general process to do this along with some pitfalls: http://www.virtualbox.org/wiki/Migrate_Windows - specifically it calls out that simply using dd to image a partition will not work (as you have found out).

The shortened version - get the number of bytes for the device you will be using, and pipe the device to VBoxManage to create the drive:

# fdisk -l /dev/sdf
Disk /dev/sdf: 1500.3 GB, 1500301910016 bytes
# cat /dev/sdf | VBoxManage convertfromraw stdin OutPutFile.vdi 1500301910016

If you have other data on that device that you really don't want to bring over, you are going to need a more sophisticated cloning utility, like Clonezilla that can take just a single partition (and the relevant boot loader information) and "clone" it to a new drive. Under that scenario you would take the image, then fire up a new virtual machine (booting the Clonezilla Live ISO perhaps) with a blank virtual hard disk that you would write the cloned image to.

share|improve this answer
    
Excellent! I feel a little bad about not RTFMing, but I've really run out of time on this. Looking at that page, the problem isn't dd itself, but the fact I only want the one partition. The image I want is an 80 GB partition on a 2 TB drive. So it comes down to creating the proper partition map in an image file. Do you know of a Linux tool that will do this? Apple Disk Utility will, but… –  Potatoswatter Jan 25 '11 at 21:35
    
Thanks for this answer – it helped me with something in Ask Different, 10.7.x or 10.8 (Build 12A269) in VirtualBox. –  Graham Perrin Aug 14 '12 at 11:46
add comment

You need to prefix the copied partition with an MBR and the appropriate amount of space before the partition. For many disks this will be a total of 63 (0x3F) x 512K blocks, but for newer drives it may be different.

I had success with an approach like this:

  • Create a new, tailored MBR image containing just the single partition: $ sudo dd if=/dev/sdf count=63 | xxd > new-mbr.img.xxd $ vim new-mbr.img.xxd

  • Build the image:

    $ { xxd -r new-mbr.img.xxd; dd if=/dev/sdf2; } \
      | VBoxManage convertfromraw stdin newdrive.vdi \
                                        $(( $partition_bytes + 63 * 512 ));
    

Since you'll need to understand the binary format of an MBR in order to do this, it might be easier to just keep the existing MBR and then fix it with [sc]?fdisk by running a live/rescue CD in the VM before booting off the resulting .vdi.

Getting the size of the partition ($partition_bytes) can also be tricky, I think I figured this out by reading the value as it is in the MBR and multiplying by block size (512). I think sfdisk --dump will give you this value too.

Anyway, this did actually work, after I'd pulled a couple of lions and an explosive alien artefact out of my hat.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.