GUID/MBR hybrid partitioning, untangling WinXP from Win7-64

R

rcfa

Member
Here's the setup:
MBR partition table:
block 0: boot block
block 1 to n: GPT protective partition
block m to l: HFS+ partition
block k to j: NTFS w/ Win7-64
block i to h: NTFS w/ WinXP-32

The GUID partition table matches the three main partitions, but has its own structure within the area covered by the GPT protective partition.

I had WinXP installed, then added Win7 and fell into the M$ multi-boot trap.
Now I try to untangle these, such that a third party boot loader can directly boot either partition 2, 3, or 4 with the respective native boot loaders taking over.

For that purpose I want to untangle WinXP and Win7, because partition 4 is the system partition and partition 3 is the boot partition for Win7.

So my goal is to get Win7 to be self-contained and self-booting from only partition 3. That seems to be elusive. Whatever I try, Win7 won't boot unless partition 4 is active and visible.

When I e.g. use the EasyBCD change boot drive option to make the C: partition the boot partition while booted into Win7, EasyBCD will switch the active partition to partition 3, etc. but booting fails.
If I boot from the Win7 Install DVD and try to fix startup problems, it doesn't find anything wrong and fixable.
The moment I make partition 4 visible and active again, I'm back in business, but it's exactly that interdependency between the two partitions that I'm trying to break, particularly since with WinXP I seem to have the "options" of either multi-booting, WinXP and Win7, at which point all users are automatically logged out instantly after a log-in, or I can only boot WinXP and things work just fine.

Any hints on how to separate the two?
 

Attachments

  • DM.GIF
    DM.GIF
    106.1 KB · Views: 6
  • EBCD.GIF
    EBCD.GIF
    80.1 KB · Views: 7
Last edited:
Just one little remark: the main thing that started all this, is that after Win7 created its own M$ brand of stupid multi-booting, while I could boot WinXP, it would log out all users instantly after log-in.

On the other hand, if I restore the disk image I created of the WinXP partition, users can log in just fine, but of course the Win7 boot fails, which can be repaired with a variety of voodoo, but then I'm back to not being able to log into XP.

I would go ahead, simply wipe both partitions, install Win7, then hide the partition, then restore WinXP, and then install the Chameleon boot loader and all would likely be fine, BUT: since Win7 is based on a Home Premium and Any Time Upgrade license, reinstalling Win7 turns into a nightmare, because Win7 won't accept an upgrade license key for installation, etc. I went through that mess once and spent a good part of several days in M$ supports' phone queue until they got it going by doing some remote voodoo and giving me a new license key (which according to them is still only an upgrade license, so the same problem would likely happen again).

So for that reason, I'm trying to hold on to that Win7 installation as I have it, and try to get it fixed/untangled from WinXP. I don't have a problem nuking the WinXP from its partition temporarily, if needed. I just don't want change the layout of the partitions on the drive or mess with partitions 1 and 2 (reserved for Chameleon boot loader and Mac OS X)

I think the problem is, that somehow it seems to be impossible to get that partition 3 to be recognized as a system partition. EasyBCD copied the boot folder over from the WinXP partition, sets it active, etc. but then the boot fails unless I reactivate/unhide partition 4 (with WinXP on it).

Also, seeing that I can't log into WinXP, I must run everything from Win7 booted, but I can't boot Win7 unless the partition 4 with WinXP is active. Chicken, Egg...
Oh, and when I try to repair the install with the Win7 Install DVD it claims to either not find any problem or to be unable to do the repair, depending on what is active and visible.
 
Last edited:
You have to note that changes made from EasyBCD to a hybrid GPT/MBR disk will not hold.

The MBR scheme on a GPT disk is a one-way street: it's for MBR-only apps to see and understand the contents of the disk. But the actual booting and settings will be from the EFI bootloader which does not respect the MBR's active partition configuration.
 
I'm aware of that, but I'm willing (and did so) to temporarily stomp all over the GPT boot loader. The GPT partition info is protected within the protective partition.

Also, the PC actually boots with regular BIOS and uses the MBR info, but when multi-booting, the active partition will be partition one, and there an EFI emulation takes over which then uses the GPT partition table, because Mac OS X assumes to run on a Mac which uses GPT/EFI not MBR/BIOS.

So in a way, in my setup it's the GPT that's fake and the MBR that's real.

In any case, I let EasyBCD write the MBR, etc. and that was successful enough that the multi-booter is out of the loop, so I assume at that point I'm just running regular MBR/BIOS based booting and all the GPT stuff is hidden in partition 1

Does that make sense, or am I completely off the mark?

In any case: as long as I can protect the data in the ranges of the current partitions, I don't care what I have to do with the partition tables and boot records to get Win7 untangled and working all of a single partition. Once I get to that point, I can clone that partition with WinClone as a backup, set up the multi-boot loader again, and things should likely work.

But somehow I need to break Win7's addiction to partition 4. :frowning:
 
EasyBCD -> Useful Utilities -> Power Console
Code: 
bootgrabber.exe /tlist

Paste the output or a screenshot?
 
Back
Top