Repairing Boot Camp after creating new partition

Thanks for clearing that up about the 0.8.9 bug.

DHughes01 is only including partitions 1,4 & 5 in the hybrid MBR (excluding 2 & 3).

Still not ideal though.

Thanks Number88 and Christopher Murphy for your insightful thoughts. Ultimately, I decided to stay away from a 5-partition MBR as you've both made it sound like a recipe for future problems. I burned my recovery partition to a CD and saved a backup of the image on a network drive, then deleted that partition and went with four partitions (EFI, Mac, Win, and Shared - FAT32) and no hybrid MBR.

Everything seems to be working fine, as I can read and write to the shared drive in both operating systems. Unfortunately, I can also see the Mac partition in Windows. I don't know if that's a problem or not, or if Windows can try to write to the Mac partition (I wouldn't think so since Mac uses a Mac OS Extended format, but I don't know.) As long as Windows being able to see Mac can't later cause corruption issues, I'm good to go. If it could be a problem, I'll have to see if I can figure out how to safely hide the Mac partition from Windows.

Oh, and I think I discovered another bug: in order to delete the recovery partition, I enabled Debug mode in Disk Utility using defaults write com.apple.DiskUtility DUDebugMenuEnabled 1 but it won't let me turn Debug mode back off using defaults write com.apple.DiskUtility DUDebugMenuEnabled 0. It doesn't really matter as long as I keep my hands off the EFI partition, but it is annoying not to be able to hide it again. But all in all, everything turned out just super. Thanks again for your help, gentlemen.

DHughes01 wrote:

Unfortunately, I can also see the Mac partition in Windows. I don't know if that's a problem or not, or if Windows can try to write to the Mac partition (I wouldn't think so since Mac uses a Mac OS Extended format, but I don't know.) As long as Windows being able to see Mac can't later cause corruption issues, I'm good to go. If it could be a problem, I'll have to see if I can figure out how to safely hide the Mac partition from Windows.

The Bootcamp drivers contain a read-only HFS driver, which lets you see the MAC HD (it should be a non-Fusion HD).

DHughes01 wrote:

Oh, and I think I discovered another bug: in order to delete the recovery partition, I enabled Debug mode in Disk Utility using defaults write com.apple.DiskUtility DUDebugMenuEnabled 1 but it won't let me turn Debug mode back off using defaults write com.apple.DiskUtility DUDebugMenuEnabled 0. It doesn't really matter as long as I keep my hands off the EFI partition, but it is annoying not to be able to hide it again.

sudo may solve your problem. If you can see the debug menu in DU, you may need to exit DU and start it back again.

Just to be clear, if you installed Windows through Bootcamp you will (almost) certainly still have a hybrid MBR.

It's fixed in 0.8.10 which should get pushed within a week.

Yes. You can delete the Recovery HD partition and thereby have 4 sync'd partitions between GPT and MBR and that ought to be safe. At least, I'd be surprised (and super annoyed) if some utility were to repartition my drive and add a new Recovery HD without my express permission.

One drawback to no Recovery HD being on that drive, you cannot use FileVault 2 because in that configuration the unencrypted Recovery HD acts as a minimal boot partition until the encrypted OS X volume is unlocked.

in order to delete the recovery partition, I enabled Debug mode in Disk Utility

Honestly if you're going to be a partition ninja, you need to stop using Disk Utility, it causes problems that it won't inform you about. Two ways to do this is delete the Recovery HD partition in gdisk. Or you can use the 'diskutil mergePartitions' command which will preserve data on the first partition and absorb the space while destroy data from the 2nd partition. So that way your OS X volume becomes 620MB bigger.

Since it's an SSD though, it doesn't really matter. Everything is logically addressed on an SSD, so even though there are 620MB of logical sectors that are just sitting empty, their physical sectors are still being used behind the scene by the SSD firmware. If anything a bit of over provisioning is healthy for the SSD and generally obviates any need to enable trim for 3rd party drives.

First off, thanks guys.

Second, though I'm not certain, I'm reasonably sure there's no hybrid MBR. The Windows partition was originally installed using Bootcamp. But during the process of all this, I used Winclone to backup and shrink the partition size. I deleted all partitions except EFI and Mac, then used Disk Utility to create two new paritions for Windows and Shared. Next, I restored the Winclone image and went through Christopher Murphy's original steps to create a hybrid MBR (putting only partition #4, the Windows partition, inside).

I booted into Windows and let it run CHKDISK to fix any anomalies (Winclone's instructions said it was normal for that to happen after restoring an image.) But the shared partition (which I couldn't add to the hybrid MBR because of the 0.8.9 bug) was still not showing up in Windows. So the last step was switching back to Mac OS X and deliberately resizing the Mac partition in Disk Utility then putting it back to full size to once again knock out the hybrid MBR. When I was completely done rebooting again, I printed the MBR while in the recovery & transformation menu (O-Enter) and it confirmed that there were 4 entries (EE, AF, OC, and 07) instead of just 2 (EE and 07).

In any event, things seem to be running smoothly now so all's well that ends well.

The Bootcamp drivers contain a read-only HFS driver, which lets you see the MAC HD (it should be a non-Fusion HD).

Right. Read-only HFS+ in Windows, and read-only NTFS in OS X. So instead of one shared space, you could have two. Windows: read from HFS+, modify the file, save to NTFS. OS X: read from NTFS, modify the file, save to HFS+. It's a poor man's copy on write, rather than r/w support to a shared volume which is always an overwrite of the original file data with these file systems.

FAT32 is fine as long as the data isn't super critical or very large: it has a 2GB file size limit, and it's not a journaled file system which means any crashes or power failures mean you have to explicitly run a file system check/repair on it. If the volume is large and contains lots of files the check/repair can take a while.

The other alternative is to get one of the products that enables read/write HFS+ or NTFS support. There is an old free NTFS-3G binary floating around the internet, don't use that. Either buy the current version from Tuxera, or build it from source code via MacPorts yourself. Or buy the competing product from Paragon.

A hybrid MBR is a misnomer, so it's confusing. All GPT disks also have an MBR as a place holder for legacy partition tools that don't understand GPT. The sole purpose of the MBR is to lie with a single "protective" entry that says the entire disk is one big in-use partition. The partitions are really in the GPT.

A hybrid MBR means: a GPT partitioned disk, with its MBR altered to contain more than the single protective entry.

And we have to do this for now because Windows when booted in BIOS mode only boots from MBR partitioned drives. And Windows when booted in UEFI mode only boots from GPT partitioned drives. And Apple's support for Windows is only via an EFI firmware compatiblity support module that presents a BIOS to Windows. Hence why we need hybrid MBRs any time you want to dual boot OS X and Windows. Some people have had some success EFI booting Windows, but then they often have driver issues due to the fact driver expect to deal with either EFI or BIOS. So then they have to go hunt for EFI compatible video drivers rather than use the Apple supplied ones. And then there's other stuff that has to be done sometimes because Apple EFI isn't actually standard UEFI which is what Windows expects...so it's sort of a rat hole.

Just open gdisk. That will tell you the status of the MBR on your drive.

Christopher Murphy wrote:

The Bootcamp drivers contain a read-only HFS driver, which lets you see the MAC HD (it should be a non-Fusion HD).

Right. Read-only HFS+ in Windows, and read-only NTFS in OS X. So instead of one shared space, you could have two. Windows: read from HFS+, modify the file, save to NTFS. OS X: read from NTFS, modify the file, save to HFS+. It's a poor man's copy on write, rather than r/w support to a shared volume which is always an overwrite of the original file data with these file systems.

I agree, it is not an optimal solution, but Apple and MSFT can share drivers, if necessary. There is also this option (without any third-party products).

http://reviews.cnet.com/8301-13727_7-57588773-263/how-to-manually-enable-ntfs-re ad-and-write-in-os-x/

Christopher Murphy wrote:

The other alternative is to get one of the products that enables read/write HFS+ or NTFS support. There is an old free NTFS-3G binary floating around the internet, don't use that. Either buy the current version from Tuxera, or build it from source code via MacPorts yourself. Or buy the competing product from Paragon.

NTFS-3G (2010.10.2) with fuse-wait.pkg seems to work on Mavericks. (I personally use it on ML/Lion).

http://i.vishalagarwal.com/post/30387627819/ntfs-write-on-lion-or-mountain-lion

NTFS-3G (2010.10.2)

Bit old. Current stable is ntfs-3g 2014.2.15, but that hasn't yet made its way to Macports. Macports has the prior version ntfs-3g 2013.1.13 available, which is the same as what I have on Fedora 20, and Fedora tend to keep things quite current. I'm not even sure if they're using the new stable version in Tuxera NTFS for OS X. So I'd either build it for free using Macports and XCode, or ask Tuxera if you upgrade now if you get the 2014 version when available.

Hi Mr. Murphy,

I have a huge problem, my dad is a dentist and for his work he needs windows XP, it's a bootcamp on an iMac. I upgraded his OSX to maverickx and broke bootcamp ofcourse.

Because of the following output however I think there is nothing wrong with my partitions, MBR or GPT...

Is this the case?

When I try booting into xp I got a BSOD with a process1_initialization_failed error. I researched this and this is a comon problem. I just have to delete the file bootcat.cache located at \windows\system32\codeintegrity.. I can not boot into xp, neither in safe mode nor from disk (no response to function keys..) but I can browse my BOOTCAMP drive from mac. However.. the codeintegrity folder is not there...

I tried booting from my windows xp 3 cd but that doesn't work, I'm guessing it's because I am on a wireless mac keyboard and don't have a wired one laying around..

Could you maybe please confirm my GPT and MBR are fine, if it's possible could you maybe give your opinion on the matter as well?

Thanks!

I would be curious which version of MAC OSX did you upgrade from? Did WXP work before the upgrade?

Did you apply the latest Bootcamp drivers to the XP SP 3 side?

Do you see the Windows XP logo as part of the boot sequence? If you do, it is more than likely a driver issue, rather than a bootcamp issue.

One debugging tool I use is to try something like VMware Fusion (or another equivalent product - VirtualBox or Parallels) to see if the issue is Bootcamp or the installed OS?

This may be an option to try. If you install a trial version of VMware Fusion, are you able to boot XP after creating a virtual machine from the Bootcamp partition? If you want to try this, you do not need to create a new virtual disk, just use the Bootcamp partition as is. It should leave the Bootcamp partition almost untouched and should also not touch the GPT/MBR.

I assume you have a Winclone or some other backup of the XP installation and the files that you consider important. 😉