I admit it! "I like Windows XP despite its many flaws". This is not to the exclusion of my other choices (Windows 7 and UBUNTU) but this is my comfortable preference. So when I found that I needed to migrate my current multi-boot system to a new drive, I was not looking forward to reinstalling everything in three operating systems. This is the procedure that I uncovered and that worked for me without reinstalling operating systems or applications.
Note the description below is for BIOS firmware; computers with GPT styled drives and associated UEFI bios firmware are not covered
A couple of years ago, I built my desktop with a triple boot option. To do this, I installed XP Pro first, in its usual (possibly necessary) first disk, first partition, and then installed Windows 7 Pro in its own Primary partition (lots of examples on the web how to do this -- here is one). The Windows 7 install setup the dual boot by replacing the XP ntldr with the Windows 7 bootmgr and boot database (\boot\BCD) on the XP (i.e. boot) partition.
UBUNTU OS was installed in the third Primary partition (leaving an Extended partition for me to divide up as other drives). During install, UBUNTU was told to install its Grub boot loader in the same partition (not the Master Boot Record (MBR)) so that it did not interfere with the XP-Win7 boot. While running under UBUNTU, I copied its partition boot record (first 512 bytes of the partition) into a file (named linux.bin) using dd.
dd if=/dev/sda6 of=/mnt/share/linuxboot.bin bs=512 count=1
Details explained here
Then, restated under Windows 7 and added it to the Windows 7 boot database options using BCDEdit.
> bcdedit /set {GUID} device boot
> bcdedit /set {GUID} path \linuxboot.bin
> bcdedit /set {GUID} description UBUNTU
> bcdedit /displayorder {GUID} /addlast
Details of using BCDEdit can be found here and here.
The result has a particular Windows flavor to it ... when bootmgr selects Windows 7 it becomes the C: drive and maps XP to D: This is something that should be kept in mind if you intend (as I did) to merge or change any of your other partitions.
I have been running like this a number of years. Here is its BCD database:
Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=D:
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {ntldr}
resumeobject {a906a50b-5f67-11e2-95db-de7af13ba091}
displayorder {ntldr}
{a906a50c-5f67-11e2-95db-de7af13ba091}
{aa1fb6a9-627c-11e2-a60a-3085a9a216e1}
{e51fb7b3-bf9b-11e4-bb50-3085a9a216e1}
toolsdisplayorder {memdiag}
timeout 30
Windows Legacy OS Loader
------------------------
identifier {ntldr}
device partition=D:
path \ntldr
description Windows XP Pro
Windows Boot Loader
-------------------
identifier {a906a50c-5f67-11e2-95db-de7af13ba091}
device partition=C:
path \Windows\system32\winload.exe
description Windows 7
locale en-US
inherit {bootloadersettings}
recoverysequence {a906a50d-5f67-11e2-95db-de7af13ba091}
recoveryenabled Yes
osdevice partition=C:
systemroot \Windows
resumeobject {a906a50b-5f67-11e2-95db-de7af13ba091}
nx OptIn
Real-mode Boot Sector
---------------------
identifier {aa1fb6a9-627c-11e2-a60a-3085a9a216e1}
device boot
path \linux.bin
description UBUNTU
Over the years I added another drive to my system (bigger -- 1Tb) and as the older disk began to fail (lots of chkdsk runs on start up), I decided to move everything to the newer bigger disk ... and I did not want to reinstall my operating systems!
There is a lot of help out there for such an operation but the specifics of my system (and yours) means that one needs to avoid copy-paste solutions -- understanding is the key.
Initially, I assumed that if I copied each of the partitions onto the new drive, powered down and switched cables with the old one; the system would come up not knowing the difference. Wrong! ... the modern Windows boot manager identifies both the physical disk and the partition offset (details here and here). Although during the partition copy I had carefully maintained the same order of the primary partitions, they were now at different locations on the new, larger hard drive.
A previously under-used entry in the Master Boot Record (MBR) is the "disk signature". Since Windows Vista, Microsoft has employed this value to identify each physical disk in its BCD database. Many MBR editors, multi-boot or other software that updates the MBR can overwrite this value -- so you are warned! Do not use other MBR editors when following this procedure.
I verified the disk signature by looking in the XP registry at HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. The short (12 byte) data values of keys that begin "\DosDevices\" followed by a drive letter and colon are partitions. The longer ones are mountable devices. The entry for my C drive was "\DosDevices \C:"=hex:ac,d7,ac,d7,00,7e,00,00,00,00,00,00 -- the first 4 bytes are its disk signature.
This value was found on my old disk at MBR offset 0x1B8 and is 4 bytes in length (below).
My newer drive had a HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices signature of "\DosDevices\G:"=hex:1c,e8,a0,ae,00,d4,69,04,3c,00,00,00 which was matched to its MBR offset 0x1B8.
Using the trusty HxD, I changed the newer drive MBR to have signature ACD7ACD7 and powered down. Then I set up so that my newer drive was the first (and only) physical drive.
It booted up and showed the bootmgr menu, but only the XP option would actually bring up an operating system!
Note: it would not be a good idea to have two drives with the same drive signature connected at the same time. So long as both drives had the same signature, I only connected one drive.
Now the question is: where does bootmgr place the partition offset within the boot database? The MiniTool Partition Editor has a "Partition Properties" choice that will present a multi-tab dialog, one of which (Partition Info), lists the first physical sector of the partition. I took this value for the Windows 7 partition on my completely working (older) disk, converted to hex and started HxD to look for the value in the older disk's BCD.
I wanted to investigate both drive's partition locations. So now I needed both drives to be connected. This required re-setting the old drive's signature ... I booted up on it (alone) and used HxD to change the MBR signature's first byte from AC to FC so that it would appear different from the new drive.
Once powered down, I reconnected the new drive as the boot drive and booted into XP to investigate using HxD. Initially I could not find a match for the offset -- even when reversing the digits for little endian. It had to be somewhere. Although I could find the disk signature, nothing in the BCD looked like an offset. I noticed that the BCD.LOG had the same time stamp as the BCD, so I assumed that the boot database involved it as well.
Here is a reference screen print -- a bit messy -- explained below.
I was able to find the disk signature in BCD.LOG (Green above), but not the offset. Then I looked at locations near the signature ... there was a 4 byte value (Blue above) that could be the offset but was not the right number. It was bigger. So on a hunch, I doubled the offset from MiniTool Partition Editor (Rust above)-- it matched! If you took into account that it was writen little endian in the BCD.LOG.
The values in Partition Properties listed as "first physical disk sector" are 16-bit words! They need to be doubled to get the byte offsets recorded in BCD.LOG.
Now I went to the MiniTool Partition Editor and got the value for the new (1Tb) disk's offset to its Windows 7 partition and doubled it. I saved this info in a text file and prepared to rebooted on the old disk so that I could edit the BCD database on the new drive. For this to work, the disk signature of the old disk had to be reset to its original value (first byte from FC back to AC) and reverse the process for the new drive signature's (changing the first byte from AC to FC). I used HxD on both drives before I powered down and change to boot from the old drive.
Note: The active BCD is always kept open by the running Windows 7 OS.
I used HxD to open the BCD.LOG file on the new drive and searched for the old offset (12 B3 E5 54) replacing it with the partition location from the new drive -- C0 0C F5 BB (see image above) -- it is reversed due to little endian hardware (Intel) that I am running on. This replacement was done in multiple locations. Saved, and just before power down, I reset the new drive to its correct signature by (changing the first byte from FC back to AC). Then powered down, setup my new drive as the first physical drive (and only drive) ... and on boot up I was able to load either XP or Windows 7.
Recall that the original Windows bootmgr BCD had an entry that passed control to my UBUNTU partition. The partition copy on the new drive was also in a new location and so a new partition boot record file needed to be hooked into the bootmgr's menu.
I used a very simple method -- allowing EasyBCD to "include" it. Instructions are here in the answer by fossfreedom: http://askubuntu.com/questions/62440/is-it-possible-to-boot-ubuntu-using-the-windows-bootloader.
For me, this did not produce the correct result. I was booted in Windows 7 and it had created its NST\AutoNeoGrub0.mbr in the Windows 7 partition, but since this system was a multi-boot, I need it on the XP partition where the BCD database was. I copied the directory to the XP Partition and updated its BCD database replacing "path \linux.bin" with "path \NST\AutoNeoGrub0.mbr"
>bcdedit /set {GUID} path \NST\AutoNeoGrub0.mbr
Upon reboot, with only the new dive connected, I was able to launch into UBUNTU!
To manage the disk signature difference, it was simplest to manipulate the MBR on old and new drive so I was able to boot off each independently using the same BCD database (since the new drive was a copy of the old one)
To manage the partition offset difference, the BCD.LOG on the new drive had to be edited to reflect the new location of the partition on that drive.
All is working now ... booting from the new 1Tb drive. I reset the disk signature of the old disk (changing the first byte from AC to FC) so it could co-exist with the other drive and now I can clean it up for recycle.