Repairing Boot Camp after creating new partition

sudo gdisk /dev/disk0

If you get any error messages at this point, report the error messages, don't proceed further.

You're now in gdisk interactive mode. Menus/commands are single characters followed by return/enter. So type ? and <enter> and you'll get the main menu listing commands. Type p <enter> and it will print (display) the current GPT. Since you have 5 GPT entries, you can't use a 1 for 1 GPT to MBR scheme like Apple does. The following suggestion is safe, but all hybrid MBRs are non-standard inventions, and therefore I can't tell you how Boot Camp Assistant or Disk Utility will react to this hybrid MBR should you decide to make changes later. What I can tell you is Windows, Linux, and Mac OS X themselves have no problem with this MBR scheme.

r <enter> go to the recovery & transformation menu

h <enter> create a new hybrid MBR

5 <enter> add partion 5 to the MBR

<enter> accept the default MBR hex code of 07

y <enter> set the bootable flag

n <enter> do not protect more partitions

o < enter> print (display) the MBR

You should have two entries. One type EE, one 07, with the 07 entry marked with * under Boot. If you don't, report back. If you do, write out the update partition information, and hope a power failure doesn't occur for the next few seconds...

w <enter> write partition table to disk

reboot. hold down option - you should be able to boot into either Mac HD, Recovery HD, or Windows.

I just tested this same five partition GPT and 2 partition MBR on a working system and the instructions above worked.

Note, so long as CSM-BIOS and thus MBR are required for Boot Camp instead of EFI booting Windows, we're stuck with flaky MBR problems, as well as the 2TB disk limitation for Windows boot disks.

Also, I filed bug ID 11980880 at bugreport.apple.com and referenced this thread.

BTW if you want, before the w command to write out the partition to disk, you can do

o <enter>

p <enter>

And report those results first, leaving gdisk running...the modified partition tables are in memory only and nothing can be hurt by leaving it running in this state. But you do want to reboot shortly after writing this out to disk.

Oops. Forgot that one. Answer that yes.

Glad it worked. The long overdue solution to this problem is for Apple to update all of our firmware so that we can UEFI boot Windows 7 and 8 x86_64. At that point the CSM-BIOS, and MBR issues all go away.

64-bit Windows Vista, 7 and 8 minimum requirements are UEFI 2.x compliant firmware. Apple's firmware is based on Intel EFI 1.10 before it was taken over by the UEFI forum, although they have incorporated some bits of UEFI 2.x. So Apple firmware is a bit of a hybrid. But not enough to (U)EFI boot Windows without hacking. There's a long running Mac Rumors thread on how to get Windows 7 to EFI boot on Apple hardware, but some hacking is needed, although I haven't attempted it.

Advantage is faster boot, full ACPI support, and better power management translating into much better battery life for laptops, and reduced power for other hardware. So I gotta say Apple is way behind in offering more up to date and capable firmware for running other OS's

Perhaps. It will be interesting when the Apple Store starts selling 2+TB disks, what Apple tells users. So far they ignore the 2TB limit in the Boot Camp system requirements, failing to tell users that 2+TB will not work.

Through entropy, Apple will effectively break Windows compatibility entirely eventually, if they don't produce minimally UEFI compliant hardware.

It's an issue in that 2+TB disks simply can't be rationally [1] supported as Windows boot disks until Apple moves to firmware that allows Windows to EFI boot. This is about disk size. Not partition size.

[1] The UEFI spec is pretty clear that a disk is either MBR or GPT. Even by Apple, who say that a disk with an MBR that contains more than one entry is not a GPT disk and the (stale) GPT should not be manipulated. Basically, Disk Utility is violating this warning, and is what resulted in your data loss experience. Disk Utility should have refused to modify your disk.

Hello Christopher! (and Scotch)

I had the exact same problem. It seems to be quite rare so I'm lucky to have found this! It's crazy that Apple hasn't implemented a way for Windows to just use EFI seeing as how that's been a feature of Windows for a while....

Since you're writing a bug ticket, I'll add my information: Originally I had 2 disks in an early 2008 MacBook Pro (HDD in place of the optical drive), laid out like this:

$ diskutil list /dev/disk0    #:                       TYPE NAME                    SIZE       IDENTIFIER    0:      GUID_partition_scheme                        *500.1 GB   disk0    1:                        EFI                         209.7 MB   disk0s1    2:                  Apple_HFS Alyx                    499.2 GB   disk0s2    3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3 /dev/disk1    #:                       TYPE NAME                    SIZE       IDENTIFIER    0:      GUID_partition_scheme                        *1.0 TB     disk1    1:                        EFI                         209.7 MB   disk1s1    2:                  Apple_HFS Tank                    747.1 GB   disk1s2    3:       Microsoft Basic Data Barney                  252.7 GB   disk1s3

I replaced disk0 (Alyx) with an SSD (Ravenholm) to speed up my system, and didn't restore the original OS (wanted a fresh one, SSD was significantly smaller than the old HDD, and I could still access the old one via USB). Then, because I've heard SSDs can fail quite a bit (and because I could afford the space on disk1), I shrunk Tank and added a clone partition (Ravenholm) for Carbon Copy Cloner, as well as a Recovery HD for that volume using CCC's tools. The partition scheme then became this, which made Barney unbootable:

$ diskutil list /dev/disk0    #:                       TYPE NAME                    SIZE       IDENTIFIER    0:      GUID_partition_scheme                        *120.0 GB   disk0    1:                        EFI                         209.7 MB   disk0s1    2:                  Apple_HFS Grigori                 119.2 GB   disk0s2    3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3 /dev/disk1    #:                       TYPE NAME                    SIZE       IDENTIFIER    0:      GUID_partition_scheme                        *1.0 TB     disk1    1:                        EFI                         209.7 MB   disk1s1    2:                  Apple_HFS Tank                    627.1 GB   disk1s2    3:                  Apple_HFS Ravenholm               119.3 GB   disk1s3    4:                 Apple_Boot Recovery HD             799.5 MB   disk1s4    5:       Microsoft Basic Data Barney                  252.7 GB   disk1s5

This was a couple of weeks ago, but I don't remember Disk Utility warning me when I shrunk Tank and added Ravenholm, and I'm guessing this was because I was on a completely different OS than the one that originally created the boot camp partition.

Using your steps I was able to figure out my situation and update the MBR table. I didn't try to run windows again until today, but I'm glad I've waited to play some games until today, as now your thread exists!

A second barrowload of thanks to you sir!

-PM

Yeah, pretty conclusive that Disk Utility is doing the wrong thing. There are a couple of ways this could be handled better, but the way it currently works breaks Windows boot and that, in effect, is data loss. Not good.