Bootcamp Partitioning

I'd like to know about this stuff too.

 

I've done this a lot with both GUI and command line commands, and I think it's a huge PITA. It basically sucks. And the reason why is even with my significant command line prowess, and ability to manually relocated partitions on the disk, inexplicably both GUI and command line tools will simply puke and refuse to do a resize. There is no useful error message.

Most often, the command line utility works the best. Most often the first and second resize work: that's a resize to create the Windows partition (shrink Mac OS partition) and then delete it and recombine with Mac OS. After that, all bets are off as to whether the procedure will work.

These forums and Apple's forums are full of people who try to do this more than once, let alone more than twice, with GUI tools, and get a message saying they have to repartition, reformat, and reinstall Mac OS and all their apps. It's just a craptastic situation, and that's my diplomatic characterization.

So if you do not have an explicit requirement for native booting Windows (i.e. games, in which case I recommend a separate gaming machine anyway), I suggest you use a VM. That is so much vastly better and easier and safer. And the performance hit is minor, if they aren't games.

Anyone who decides to dual boot Windows, needs to thoroughly understand that you cannot use Windows utilities for resizing. It will invariably lead to data loss for Mac OS or Windows or both portions of the disk. Those tools are completely GPT unaware, they assume the MBR is the only thing that matters, and they will completely hose the disk beyond repair.

I cannot say enough bad things about Boot Camp. I hate it. And I haven't even experienced (meaningful) data loss.

Yet another thread, as an example.

http://forums.macrumors.com/showthread.php?t=1385578

 

I disagree that this is what I'm saying. The problem is Apple's support for Windows, collectively called "Boot Camp", presently depends on BIOS booting Windows. When Windows boots in BIOS mode, it will only honor MBR disks as boot disks. So Apple went with a non-standard, and arguably a violation of the UEFI spec, hybrid MBR + GPT partitioning scheme. And that is what has led to confusion. There are two partition maps.

The UEFI spec rather clearly says that GPT disks only have a single protective MBR entry. However after Boot Camp Assistant has repartitioned the disk, the MBR has multiple entries (with Lion, it has four, the maximum an MBR can contain).

There is no good reason for Windows tools to be aware of hybrid MBRs or how to deal with them correctly.

A long time ago already, Apple should have supplied current hardware with firmware updates so that we can UEFI boot Windows 7 x86_64, and completely dispense with the perversion that is hybrid MBR.

Apple's own developer documentation explicitly says hybrid MBRs are bad, but then Apple goes an uses them itself.

And when the poo hits the fan, Apple's tools themselves puke and tell the user to reformat to solve the problem, rather than being able to fix the problem. So across the board, Boot Camp sucks.

Well, it's actually following a spec for once in this case. So you can't pin this on Windows or Windows apps being dumb. The hybrid MBR that Apple hardware requires to support native Windows booting is a fundamentally fragile thing, and fraught with peril for user data as far as I'm concerned.

----------

Apple TN2166, Protective MBR

Specifically, if block 0 contains an MBR with more than one partition entry, or a single partition entry whose OSType is not 0xEE, it is not a compliant GPT disk, and manipulating the GPT may cause dangerous inconsistencies between it and the legacy MBR.

Boot Camp does precisely this to block 0 (the MBR): it adds multiple entries found in the GPT to the MBR. Apple's own tech note says this is not a compliant GPT disk and manipulating the GPT may cause problems. Manipulating the MBR can also cause problems, as that's what Windows tools will manipulate without updating the GPT that Mac OS X depends on.

What Apple should have done for Boot Camped computers, is convert the GPT to MBR only. Not used a hybrid MBR. And then sooner they should have had UEFI booting support for Windows 7 64-bit, which then uses only GPT for boot disks.

This is already a problem for people who want disks bigger than 2.2TB, which MBR does not support, and thus Boot Camp cannot support either. The only way around it is UEFI booting Windows.

----------

Yes. Be aware most of them are single monolithic files. The instant one bit is changed in the environment, that whole file is considered modified and subject to being backed up again. There are some ways around this depending on the specific format, for example if you use snapshots frequently an additional file is created that contains all of the changes since the snapshot was created. This file is much much smaller. But I can't tell you off hand if for sure the base file is completely unmodified even when there's a snapshot file in place. I know that's the case for QCOW2. I think it's also the case for VDI as I get separate snapshot files made, rather than the snapshot info being stuffed into the original VDI. But that original VDI I think has its modification date changed, so I think it still gets backed up - which is why I've excluded VM disk images from backup. I consider them expendable anyway, and use folder sharing to make sure important data is on the Mac side, and subject to its regular backups.

Dunno.

 

Umm, you're talking about tools that predate GPT. They have absolutely no possible way of knowing about GPT disks at all. They see a valid MBR, with an xEE entry that does not protect the entire disk. Therefore the expectation for such tools is that it's strictly an MBR disk, and perfectly acceptable to modify.

Further, both UEFI spec and Apple's own documentation suggests that a disk with both GPT and MBR, with an MBR containing multiple entries is no longer a valid GPT disk. Therefore it should be treated strictly as MBR, which is precisely how the tools behave, except Apple's.

That's inconsistent with the UEFI spec, and Apple's own documentation. The reality is, hybrid MBRs are inherently dangerous, they should not be used, Apple has been unwise to use them. They should have converted GPT disks to MBR only upon Boot Camp repartitioning the disk, instead of this hybrid MBR nonsense that has cause immense problems.

And that's aside from the problems that are unrelated to MBR. For example the Lion Recovery HD partition, located in between the Mac OS JHFS+/X partition and the Windows NTFS partition. That Recovery HD has to be relocated every time there is a resize operation, and often that causes problems resulting in the resize command simply failing (in either direction).

And if you use FileVault 2, you're hosed. You can't resize.

I'm suggesting for BIOS booting Windows, they should have converted the disk to MBR. For UEFI booting Windows, they can leave the disk as GPT.

Oh I remember fine. I think they made the wrong call. They went with a fragile solution instead of a safer solution.

 

How so?

Does not seem true considering UEFI PC's are now flooding the market. A more logical explanation for PC's breaking with BIOS is that there hasn't been major advantages to UEFI over BIOS, compared to its massively increased complexity and bugs.

What do onmac/XOM have to do with Apple's hybrid MBR decision?

Not if the spec is followed, and the PMBR is a single entry only that covers the entire disk. The whole point for that portion of the spec is to allow for the LIKELIHOOD of legacy MBR tools which will be stuck in time forever, as is often the case. The GPT designers expected the very behavior that Apple's scheme has thus thwarted, by design and against their own recommendations.

Further, Apple's own fdisk included with Mac OS X does not recognize GPT or even warn the user that one is in place. Conversely modern fdisk on Linux has long been updated to recognize GPT disks and warn the user to use a different tool to modify GPT partitions because fdisk is strictly for MBR editing.

Routinely users use the provided tools and are told they cannot resize/shrink to create a Windows partition, even after removing the old one. These boards are littered with these complaints, as are Apple's forums, users experiencing the famous line from Boot Camp Assistant that they need to repartition with a single partition and reformat, even though they already have only one single partition.

Indeed and points precisely to how flakey Boot Camp is.

 

The exact area where you're least likely to find UEFI because the advantages of GPT on a boot disk are < 0. Servers aren't often using 2.2+TB disks. Aren't using more than 4 partitions.

What are you talking about? Please be precise. GPT has been supported for non-boot disks since Windows XP 64-bit. A very long time ago. It has been supported for boot disks for UEFI hardware in Vista and 7 64-bit. What exactly about this is a problem? What exactly would you say they should have done different?

And yet to you this MBR "abomination" is quite OK to hybridize with GPT on your Mac. This logic is totally daft.

Apple did not have to support Windows. They did not have to produce a CSM or BIOS for their EFI implementation. For BIOS support for Windows dual booting with Mac OS, there is nothing wrong, and everything right and safer to convert a GPT disk to pure MBR only. There would be fewer problems, and less confusion.

The hybrid MBR gives us the worst combination of limitations of GPT and MBR anyway, so there is no advantage to the hybrid MBR.

diskutil is not the GPT equivalent of fdisk. The gpt program is what's provided. The better equivalent is GPT fdisk, a.k.a. gdisk, but Apple doesn't include it.

Yeah and this basically sucks, and with modern file systems and logical volume management would not be a problem.

I don't see the distinction between drive letters and superfluous drive icons because we don't have meaningful logical volume management on Mac OS to pool storage, and then create logical volumes, easy to resize without having to deal with partitions at all. Precisely how do you blame Windows for BIOS and MBR when Microsoft do not make hardware at all, and have had GPT and UEFI support for quite some time?

How do you account for Microsoft's support for UEFI Secure Boot, to prevent boot loader malware, whereas Apple presently has no such support? How do you account for the fact Microsoft supports UEFI 2.x and Apple does not? Apple's latest and greatest hardware is still based on Intel EFI 1.10, not UEFI 2.x.

Across the board Microsoft's support for EFI is better than Apple's. That the OEM and end user market haven't really cared much until recently about UEFI hardware is not Microsoft's fault. I don't see how you assign this blame to them.

 

Many examples:

http://www.intowindows.com/how-to-c...-flashpen-drive-with-a-single-click-must-try/

http://www.microsoftstore.com/store/msstore/html/pbPage.Help_Win7_usbdvd_dwnTool

http://arstechnica.com/business/2009/12/the-usb-flash-drive/

I can make the same argument that MBR and GPT should be discarded in favor of LVM2 because even GPT is weak compared to that. But these things take agreement and the overwhelming sentiment of users, businesses and hardware OEM's is that the benefits of GPT over MBR are incremental. The benefit of UEFI is largely outweighed by it's complexity and bugs. As that complexity is better understood and the bugs are being reduced, we're seeing much more usage.

And the implementations of UEFI GUI's are insane and impressive, there are even 3D configuration screens now. We're very unlikely to see a configurable UEFI from Apple. Ever. So while you castigate the limitations of MBR and BIOS, basically we have a castrated and old EFI implementation on Apple hardware. So I really don't see where you're going with the complaints.

Apple's and oranges. You're talking about two EFI and GPT aware operating systems, versus two requiring different schemes. EFI+GPT is potentially more friendly to multiple booting because there is a large partition to store multiple boot loaders for each operating system. BIOS+MBR systems were only designed for one bootable OS.

This is rather significantly off topic. My suggestion remains that users think twice about using Boot Camp / native boot Windows on Apple hardware. It's a pain. Users have inordinate numbers of problems and the forums on various web sites bears this out. I recommend VM whenever possible.

 

This is coddling Apple, and sugar coating the design. It's not just somewhat non-standard, it doesn't even meet their own standard in the technote I cited.

You admit there are problems, I don't understand the disagreement of problem source. What is the significant downside of GPT to MBR conversion for the dual boot scenario? You already admit that it's better to install Windows on an MBR only disk on its own. If MBR is better in that case, why not conversion for dual boot support?

Hybrid MBR has all the same limitations as MBR only, and then some. So why use it? Why is that a better design?

Not relevant at all to those who have.

It could be better. It's more prone to problems than pure GPT or pure MBR arrangement for all the reasons cited, including Apple's own technote that even says failure to heed the recommendations may result in the loss of user data. And in fact users have lost data as a result of this scheme.

Yes it's possible if you have hardware that can do it, and some hacks. No it's not supported by Microsoft, for similar reasons why they don't support GPT for boot disks on BIOS hardware. It's problematic enough that they just refuse to support it.

And it's even problematic on Apple hardware, despite EFI having much better USB support than myriad BIOS implementations. My MBP 4,1 hates Kingston R500 media. It takes 45+ minutes for it to boot a Recovery HD image. The same USB stick on MBP 8,2 boots in under a minute. A Lexar stick boots the 4,1 in 2 minutes, and the 8,2 in about the same or a bit less. And I've had sticks that flat out vanish from EFI, resulting boot is from the default disk.

Ancient WinHEC2003 USB Flash Drive document in .DOC format.

2nd to last page describes issues related to USB flash drive bootability. It's not as simple as Microsoft/Windows sucks donkey balls.

 

See, you assume Apple is the only company creating and using hybrid MBRs, that's the only reason why you'd say this. There are other implementations, there are many ambiguities between them. And there is dependency on firmware's interpretation of them. Apple's hybrid MBR implementation is known by Apple firmware. Other firmware interprets it different. Apple's firmware interprets other hybrid MBR implementations differently too.

This is the problem with non-standardization. You don't get to say Apple's is the de facto standard. It's just absurd. If there were agreement in this area, it would necessarily require widespread firmware updates (BIOS and EFI) for millions of computers, and a lot of kernel, boot loader, and utility program code. It will never happen.

You also must not be very familiar with MBR and GPT or you would realize the unresolvable ambiguities their combination causes. There isn't an automated way to resolve these ambiguities. And manual resolution often hits a brick wall as well.

Hybrid MBRs should be avoided, it's an ill conceived dirty hack that Apple should not have subjected its users to. There's no advantage of it over conversion of Boot Camp targeted dual boot disks to plain MBR, and every advantage because then ambiguities can't occur.

Cute. I, and others would consider hybrid MBR a corner case hack. It occurs on far less hardware, at a far lower percentage, than people successfully booting Windows from USB drives.

For two, I never said it was equally good, your threshold for Windows bootability from USB drives was low because you didn't require direct Microsoft support for it.

Linux is no better on Apple hardware than Windows is in this regard, because again, it's a limitation of Apple's CSM-BIOS implementation that prevents USB bootability. Now, recent Linux distros have started to support EFI booting on Macs, in which case USB booting does work. Again pointing to a limitation of hardware, not the OS.

 

I feel like this thread got a little off topic. To put it simply:

1. It is difficult to resize the partition but it is possible. There is software that can do it correctly.
2. The bootcamp utility on OS X can remove the windows partition and swallow the HD space back into the OS X partition no problem. It's just one or two button presses and you're done.

 

The problem is the success rate. Not how easy or difficult it is. I consider the success rate very low, maybe 30% of the time it will refuse to resize without a reason why. But even that is misleading. The older the Mac OS volume is, the greater the chance it cannot be resized. The more full the Mac OS volume is, the greater the chance it cannot be resized. When it cannot be resized, yes, it is a matter of difficulty because the Apple recommendation is to totally repartition the disk, reinstall Mac OS X, restore your user data, and then try again. I've found command line work arounds that can deal with these situations some, but not all, of the time.

No that is not my experience. Usually it works, but sometimes it will delete the Windows volume, making it Free Space, but that free space is NOT re-added to the Mac OS volume, resizing is not possible. There are many posts in these forums and Apple's forums, where people successfully deleted the Windows partition but readding that space to Mac OS X's partition was not possible at all with GUI tools.

In such cases, 100% of the time so far, if I delete the Recovery HD partition, which requires a command line GPT partition tool like gdisk, I can then usually resize. Sometimes I also have to rebuild the JHFS+/X catalog from command line using the fsck_hfs -r flag (Disk Utility does not have this option as far as I can tell). And then resizing to absorb that free space usually works. And then restore the Recovery HD partition (make a new 620MiB partion and dd the Recovery HD backup image back to that partition).

From this reunified state, Boot Camp Assistant will frequently, but not always, tell me that I need to repartition the disk with a single partition, reinstall Mac OS X, and try again.

Behaviors change yet again if you use File Vault 2.