Bootcamp Partitioning

[browerjs]

So I'm entering the Mac world as soon as my Retina MBP ships, but while I'm patiently waiting, I have some questions on the bootcamp partition process.

1. How difficult is it to resize (up or down) the partition after the initialization.
2. If I create a partition and then I decide I don't want to use Boot Camp and just use a VM, how difficult is it to delete the partition and merge it back into the primary OSX partition?

Thanks!

 

[Sounds Good]

I'd like to know about this stuff too.

 

[murphychris]

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.

https://forums.macrumors.com/threads/1385578/

 

[balamw]

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

You said it yourself, the problem isn't Boot Camp itself, it's folks who don't understand the underlying technology and the tools and OSes that stick with only understanding MBR and not playing nice in the sandbox with other OSes.

Windows and many Windows low-level tools always assume that it must be the only OS in the box.

This is why the MR Guide on resizing your partition exists, and why it specifically calls out only Boot Camp aware tools.

The Winclone approach remains my favorite as you get a backup out of it.

B

 

[browerjs]

Since I don't do any gaming, and my main purpose for Boot Camp would be to just play around with it, sounds like the smart choice is to not worry about it and just go Virtual.

So do all the VM solutions for the Mac have dynamically allocated vhd's like I setup in Virtual Box for Windows?

I'm leaning towards just using Virtual Box and tossing the Win8 Release Preview on it until Win8 RTM, at which time I may move to parrallels as it appears that their seamless integration may be better then VB.

Does Parrallels offer a free trial?

 

[murphychris]

You said it yourself, the problem isn't Boot Camp itself, it's folks who don't understand the underlying technology and the tools and OSes that stick with only understanding MBR and not playing nice in the sandbox with other OSes.

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.

Windows and many Windows low-level tools always assume that it must be the only OS in the box.

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.

----------

So do all the VM solutions for the Mac have dynamically allocated vhd's like I setup in Virtual Box for 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.

Does Parrallels offer a free trial?

Dunno.

 

[balamw]

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

This is the only part I disagree with.

A well designed low level tool should simply check that what they see matches their expectations before doing anything. A simple "You seem to be using a hybrid GPT/MBR partitioning scheme, Proceed at your own risk."

Windows prior to version 7 or any 32 bit version simply would not be useable in your native UEFI model, I suspect that this is a major driver for the choices Apple made in the evolution of Boot Camp.

You have to remember that it was initially released at a time when Vista was new and MANY still wanted/needed to use XP on their Macs.

B

----------

Does Parrallels offer a free trial?

Yes.

https://nct.parallels.com/fulfill/0285.011

B

 

[murphychris]

A well designed low level tool should simply check that what they see matches their expectations before doing anything.

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.

A simple "You seem to be using a hybrid GPT/MBR partitioning scheme, Proceed at your own risk."

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.

Windows prior to version 7 or any 32 bit version simply would not be useable in your native UEFI model, I suspect that this is a major driver for the choices Apple made in the evolution of Boot Camp.

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.

You have to remember that it was initially released at a time when Vista was new and MANY still wanted/needed to use XP on their Macs.

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

 

[balamw]

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

The safer solution you suggest is exactly why most PCs can't every make a break away from BIOS even today. Apple's hand was forced by the onmac/XOM folks and this pushed them to a solution along the lines we see today. I don't disagree with you that they should have tried earlier to make sure that W764 would not require these shenanigans and would boot natively.

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.

Boot Camp came out in early 2006, GPT was already in use then it is now six years later. Windows 7 came out 3.5 years after Boot Camp had already been in use on Macs. Are you honestly suggesting that folks are running low level tools on their current Macs that are older than 2006 or older than W7? If so, they're just asking for trouble.

Boot Camp really isn't that fragile when you stay within the bounds of the tools Apple provides and supports. Want to resize your partition? Remove it with Boot Camp, create a new larger one, etc...

I've experienced similar levels of "fragility" using low level third-party tools on pure Windows systems on later systems where Windows has changed something in the NTFS specification that led to data corruption.

If' you're fortunate enough to have a Mac Pro, the simple solution is to install Windows on its own MBR formatted HDD. Works every time. The partitioning part of Boot Camp is completely superfluous.

B

 

[murphychris]

The safer solution you suggest is exactly why most PCs can't every make a break away from BIOS even today.

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.

Apple's hand was forced by the onmac/XOM folks and this pushed them to a solution along the lines we see today.

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

Are you honestly suggesting that folks are running low level tools on their current Macs that are older than 2006 or older than W7? If so, they're just asking for trouble.

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.

Boot Camp really isn't that fragile when you stay within the bounds of the tools Apple provides and supports. Want to resize your partition? Remove it with Boot Camp, create a new larger one, etc…

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.

If' you're fortunate enough to have a Mac Pro, the simple solution is to install Windows on its own MBR formatted HDD. Works every time. The partitioning part of Boot Camp is completely superfluous.

Indeed and points precisely to how flakey Boot Camp is.

 

[balamw]

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.

Of course there have been plenty of advantages. GPT/EFI have been in use plenty in the server side of life. It is only Microsoft's inability to break with the past in their consumer OSes that has dragged the misery that is MBR into the present. To me, MBR is an abomination as much as FAT12/16/32. A legacy of the early 1980s that was allowed to live far beyond its useful life.

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

At the time onmac/XOM demonstrated that BIOS could be emulated and XP could be installed on Intel Macs, Apple had to switch their position from: Running Windows is not supported to running Windows is supported with this somewhat non-standard method. Clearly the earlier position was "simpler", you can't do that except through VM software.

I agree with you that fdisk on OS X should warn you to use diskutil instead.

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.

I've had similar problems with Partition Magic and the like in the DOS/Windows days, and dealt with them since the early 90s. Most of those tools also required you to reboot to DOS (or not the running OS) before you could resize. This is usually the source of the issues many have, and it is often resolved by running disk utility from another drive or from CD. The simple solution that is infallible is, and always has been, backup and restore the backup to the resized partition.

Indeed and points precisely to how flakey Boot Camp is.

I still place a fair amount of the blame on Windows (at least through W7, I have not had much experience with W8 so far) and its reliance on archaic technologies like BIOS/MBR/drive letters, etc...

For the record, I've had plenty of Windows only boxes go belly up because I introduced a new drive or partition that changed the drive letter allocation and rendered it pretty much useless. It's just silly. I've also long since given up on trying to reliably run a multi-partition/multi-drive Windows install as too many things just don't respect them. Even if I created a "D:" partition and moved my user profile or the "Program Files" folders there, many installers would insist on writing to "C:" no matter what.

It would be SO much simpler if Windows 7 would officially support booting from external/removable media like any modern OS. Bootable backups. What a concept!

Most recently my W7/Ubuntu box had become un-bootable several times just by adding a non-system drive. The W7 repair wizard would take hours to repair it, but has rendered Ubuntu un-bootable. Real robust.

EDIT: Basically, my point is this. I ran DOS/Windows as my primary OS from 1988 to 2005, I've run many other OSes concurrently on those systems. In most cases throughout that time, Windows was generally the cause of the issues that I encountered. Even when I ran a mixed W2000 XP system for an extended period of time.

My Linux only boxes were rock solid, my Windows (one system only) boxes were generally rock solid. As soon as I tried to deviate from the default single C: drive model, and/or mix several OSes, danger ensued.

W7 is a fine OS, but given my experience, I will generally prefer to run it on a system with a single partition as large as it can be with any additional drives strictly reserved for data. I have it on my MB and MBP under Boot Camp for emergency use, but I will generally RDP to my desktop. I've resized my partitions and upgraded my hard disks without any issues or data loss.

For me Boot Camp has been no worse in terms of stability or finickiness than any other multi-partition, multi-OS Windows install I've ever had that didn't involve OS X.

B

 

[murphychris]

Of course there have been plenty of advantages. GPT/EFI have been in use plenty in the server side of life.

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.

It is only Microsoft's inability to break with the past in their consumer OSes that has dragged the misery that is MBR into the present.

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?

To me, MBR is an abomination as much as FAT12/16/32. A legacy of the early 1980s that was allowed to live far beyond its useful life.

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

At the time onmac/XOM demonstrated that BIOS could be emulated and XP could be installed on Intel Macs, Apple had to switch their position from: Running Windows is not supported to running Windows is supported with this somewhat non-standard method. Clearly the earlier position was "simpler", you can't do that except through VM software.

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.

I agree with you that fdisk on OS X should warn you to use diskutil instead.

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.

The simple solution that is infallible is, and always has been, backup and restore the backup to the resized partition.

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

I still place a fair amount of the blame on Windows (at least through W7, I have not had much experience with W8 so far) and its reliance on archaic technologies like BIOS/MBR/drive letters, etc...

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.

Even if I created a "D:" partition and moved my user profile or the "Program Files" folders there, many installers would insist on writing to "C:" no matter what./

How is this any different from Mac OS installers that refuse to install apps to a location other than the boot disk? Happens all the time that they want to be in /Applications and no where else.

It would be SO much simpler if Windows 7 would officially support booting from external/removable media like any modern OS. Bootable backups. What a concept!

Umm, Windows 7 can be booted from USB/external media. The problem is BIOS. Some BIOS implementations, including Apple's, does not support USB for boot. USB is only supported for booting in EFI mode, not with the CSM-BIOS mode.

Most recently my W7/Ubuntu box had become un-bootable several times just by adding a non-system drive. The W7 repair wizard would take hours to repair it, but has rendered Ubuntu un-bootable. Real robust.

A legitimate complaint about MBR is the singular boot loader the MBR can contain. And this boot loader code area, as well as the subsequent 2nd stage, can be easily overwritten/corrupted. But dual boot is generally in the realm of a hack anyway, because no OS except Linux and maybe BSD really do a decent job of expecting to be shared on one disk with another OS. Mac OS and Windows are not good citizens when it comes to sharing space with other OS's, rather considering them foreign invasions.

----------

For me Boot Camp has been no worse in terms of stability or finickiness than any other multi-partition, multi-OS Windows install I've ever had that didn't involve OS X.

I guarantee you that by definition it's less reliable and more finicky and prone to data loss on Apple hardware BECAUSE of the hybrid MBR ambiguity. It is not merely somewhat non-standard. It's exceptionally non-standard. And as I've mentioned several times, it's proscribed by an Apple technote, yet they use it anyway. And then they ignore their own recommendation to treat such a disk as MBR only.

So it's unsurprising to me that people have the recurring problems with Boot Camp'd computers they do.

 

[balamw]

Umm, Windows 7 can be booted from USB/external media. The problem is BIOS. Some BIOS implementations, including Apple's, does not support USB for boot. USB is only supported for booting in EFI mode, not with the CSM-BIOS mode.

Again my experience differs here. Please provide any source where Microsoft suggests that installing W7 to a USB or FW external removable drive is possible or supported. All I've ever seen says otherwise. e.g. http://social.technet.microsoft.com...l/thread/8f381e7f-77d2-4739-a072-7e1becfca506

No. Windows 7 cannot be installed on any drive that Windows identifies as removable. Depending on how your system is configured you might be able to install the OS on an eSATA drive, which appears to the operating system as an internal fixed drive.

In the cases where some PCs are able to boot from removable, it appears to be the BIOS that masks the removable nature of the drive to present it to Windows as an internal. (i.e. a workaround hack to deal with Windows' artificial limitation).

Can you provide a link from Microsoft that says anything where installing to a removable drive is supported? (Hard to google for as the "installing from USB" links which is supported swamp it out).

A legitimate complaint about MBR is the singular boot loader the MBR can contain. And this boot loader code area, as well as the subsequent 2nd stage, can be easily overwritten/corrupted.

That, plus the silly 4 primary partition limit and the extensions for additional (generally non-bootable) partitions, .... It's weak and should have gone away a long time ago.

But dual boot is generally in the realm of a hack anyway, because no OS except Linux and maybe BSD really do a decent job of expecting to be shared on one disk with another OS.

In my experience Mac OS X is a far better citizen than Windows, being that I can far more readily run a SL/Lion system than a W7/XP system. For me the common problem in multi-boot systems is Windows. I ran my W7 desktop as a Hackintosh with kakewalk along side ubuntu for months solid before I installed W7 on it (single drive, three partitions) and ran into problems. I removed OS X and ran W7/Ubuntu for a while until that too ran into issues.

B

 

[murphychris]

Again my experience differs here. Please provide any source where Microsoft suggests that installing W7 to a USB or FW external removable drive is possible or supported.

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/

That, plus the silly 4 primary partition limit and the extensions for additional (generally non-bootable) partitions, .... It's weak and should have gone away a long time ago.

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.

In my experience Mac OS X is a far better citizen than Windows, being that I can far more readily run a SL/Lion system than a W7/XP system.

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.

For me the common problem in multi-boot systems is Windows. I ran my W7 desktop as a Hackintosh with kakewalk along side ubuntu for months solid before I installed W7 on it (single drive, three partitions) and ran into problems. I removed OS X and ran W7/Ubuntu for a while until that too ran into issues.

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.

 

[balamw]

I recommend VM whenever possible.

On that we agree. Especially with XP. On modern hardware, XP runs in a VM about as well as it ever did on the hardware it was designed for.

Where we differ is where the problems lie. If you use Boot Camp as designed and "supported" by Apple, it is quite robust and solid even if somewhat non-standard. For all of the problems you see on the web, there are many more people using Windows on their Macs via Boot Camp without these issues.

In fact, the company I work for has standardized around W7 on MBPs without any real issues, though many of us end up using OS X or CentOS on our Macs. It works quite well.

For the record. All three of the links you provided are about creating a bootable W7 installer on USB, not a working, full installation. This is exactly what I was referring to. You can install W7 from USB/FW instead of CD, but you can't install it to and/or run it from USB/FW.

B

 

[murphychris]

Where we differ is where the problems lie. If you use Boot Camp as designed and "supported" by Apple, it is quite robust and solid even if somewhat non-standard.

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?

For all of the problems you see on the web, there are many more people using Windows on their Macs via Boot Camp without these issues.

Not relevant at all to those who have.

In fact, the company I work for has standardized around W7 on MBPs without any real issues, though many of us end up using OS X or CentOS on our Macs. It works quite well.

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.

For the record. All three of the links you provided are about creating a bootable W7 installer on USB, not a working, full installation. This is exactly what I was referring to. You can install W7 from USB/FW instead of CD, but you can't install it to and/or run it from USB/FW.

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.

 

[balamw]

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.

If nothing else it is a de facto standard that exists since 2006. As such it exists and should be dealt with.

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.

This makes your whole argument that Windows is equally good at booting off USB/FW as OS X or Linux moot. It doesn't, it's a corner case hack.

It is also true that Windows isn't designed to support a portable installation (with the exception of Windows PE which has at the heart of the Windows installer, I used to have a Bart's PE CD with a bunch of useful tools like Partition Magic on it.).

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

I've already admitted that Windows 7 is a fine OS on its own. I do not believe that MS/Windows does anything of the kind you suggest. Nor am I blind enough to think that Apple does or can do no wrong. I do think that one of Microsoft's big challenges is how to move forward without breaking compatibility with the past. I believe they've done better on those fronts with W7 and W8 than they did up to Vista. XP Mode in 7 is one such victory.

Any time you reparation a drive on the fly with any tool, including the ones provided by the OS, and even if you will only be using one OS with that drive you should expect the possibility of problems arising and proceed only with a good, verified back up.

IMO The grass really isn't any greener on the other side of the fence.

B

 

[murphychris]

If nothing else it is a de facto standard that exists since 2006. As such it exists and should be dealt with.

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.

This makes your whole argument that Windows is equally good at booting off USB/FW as OS X or Linux moot. It doesn't, it's a corner case hack.

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.

 

[eliehass]

So I'm entering the Mac world as soon as my Retina MBP ships, but while I'm patiently waiting, I have some questions on the bootcamp partition process.

1. How difficult is it to resize (up or down) the partition after the initialization.
2. If I create a partition and then I decide I don't want to use Boot Camp and just use a VM, how difficult is it to delete the partition and merge it back into the primary OSX partition?

Thanks!

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.

 

[murphychris]

1. It is difficult to resize the partition but it is possible. There is software that can do it correctly.

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.

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.

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.

 

[balamw]

No that is not my experience.

Thanks for phrasing it that way. While many may share your experience, many others do not.

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.

The easiest way to deal with this that gives you a bootable backup as part of the bargain is to use CCC to clone your partition. Wipe the internal drive and restore at your new size. Yes, things like FileVault, extra partitions, removing the system partitions etc... will make this more difficult.

Again, I do not recommend doing any kind of partition manipulation without a verified backup. So this really isn't an extra step. The advantage you have here is that the CCC backup is a real safety net. You don't need to actually restore it to be able to boot from it and use it.

My last word: Believe me, I know plenty about this topic and have helped many folks through their multi-boot issues here at MR, as well as in RL with plenty of systems, including plenty of non-Macs. I spent a fair amount of time writing a replacement for Winclone, and helping people through their issues with it when it was abandonware. My approach when writing code is to trust, but verify. Many of Winclone's problems were of this ilk. Proceeding without making sure it was safe to do so rather than raising a flag early on that trouble was ahead, which could often have been easily detected.

B