Currently Being ModeratedJul 28, 2012 2:19 PM (in response to Scotch_Brawth)
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.
Currently Being ModeratedJul 28, 2012 2:32 PM (in response to Christopher Murphy)
Aha. Yes, I thought I read on a forum somewhere that Windows 7 was compatible with EFI. Well, fingers crossed. In fact, I'm going to put in some feedback in that regard right now. To all those that come across this thread: please do the same - Apple does listen!
Currently Being ModeratedJul 28, 2012 2:39 PM (in response to Scotch_Brawth)
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
Currently Being ModeratedJul 28, 2012 4:20 PM (in response to Christopher Murphy)
If the benefits are only for other OSes, I can't see a firmware being forthcoming any time soon, if at all.
Currently Being ModeratedJul 28, 2012 4:54 PM (in response to Scotch_Brawth)
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.
Currently Being ModeratedJul 29, 2012 8:58 AM (in response to Christopher Murphy)
Ah, so when you said:
the 2TB disk limitation for Windows boot disks.
You mean that the disk being 2TB (or greater) in size as a whole was going to be a an issue? I took it to mean that the Windows partition itself had to be 2TB+.Mac mini (Mid 2011), OS X Mountain Lion, 8GB RAM, 500GB HDD
Currently Being ModeratedJul 29, 2012 12:07 PM (in response to Scotch_Brawth)
It's an issue in that 2+TB disks simply can't be rationally  supported as Windows boot disks until Apple moves to firmware that allows Windows to EFI boot. This is about disk size. Not partition size.
 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.
Currently Being ModeratedJul 29, 2012 5:31 PM (in response to Christopher Murphy)
Well, a quick search on my favourite IT sites and Amazon shows not a single 2TB 2.5'' drive for sale, so this limit won't affect my MBP or Mac mini any time soon. The only computers this really affects at the moment would appear to be the Mac Pro (and with spare drive bays it's not crucial there), and maybe iMacs - do they use 2.5'' or 3.5'' drives? Also what with no current Macs using eSATA as standard, and with the only Thunderbolt to eSATA adapters available through really quite expensive docks, this limit won't hit for some time, if ever. Who knows: by the time it becomes a problem, Windows may finally allow booting from USB!
Anyway, thanks for being so informative.
Currently Being ModeratedAug 1, 2012 3:27 AM (in response to Christopher Murphy)
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!
Currently Being ModeratedAug 1, 2012 8:35 AM (in response to wizpig64)
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.
Currently Being ModeratedAug 3, 2012 5:04 PM (in response to Christopher Murphy)
Hello Christopher - Thank you very much. I had a similar issue from the end of last year with Lion upgrade. Following the issues, the windows install disk (on trying to fix startup repairs on windows bootcamp booting) changed the whole partition to MBR, including that of the mac side!. However, everything worked as they were, but nothing more in terms of software update or like was possible.
Calls to applecare were of no use, all google search and research and attempts did not help. By chance, I stumbled on this, and your responses to the thread https://discussions.apple.com/thread/4151736?start=15&tstart=0
With absolutely no background in programming or computer tech, I read and re-read your potential solutions and their context you so aptly described. Your contextual approach to solving a problem gave me the courage to attempt something similar on my computer. Mainly due to your providing the context and rationale for your potential fix, I was able to come up with a suitable solution for my needs today without any knowledge of programming or tech. The computer works okay on both sides now. Early times, but I wanted to thank you first before using it. Hopefully it will stay the same.
One clarification re. MBR hex code - In my three attempts, the mac never gave the 07 code as default. It came up with AF or EF as default (and had * to indicate boot capability). Both times, windows bootcamp did not work without start up repairs which meant another MBR whole partition!. Finally, I manually input 07 as code in my third attempt, and things worked.
One outstanding issue - Similar to "taylor136's" issue on the other thread, I have a free space of some 170gb which is not seen after recovery HD. I tried to extend the size on disk utility and click apply. It applies but then reverts to the original way. Tried your commands as described in that thread to resize, again to no avail. Nothing seems to work on that front. Appreciate any other thoughts to reclaim that for windows if possible.
I guess that is the least of my worries at this stage. Really wanted to get this MBR to GUID partition sorted and have windows and mac operating as they should. I achieved them both, so I am happy for the moment. Thank you again, and you have a great weekend.
Currently Being ModeratedAug 3, 2012 10:13 PM (in response to Christopher Murphy)
Sorry - The main purpose behind my last note was to thank you for your efforts, and also to Scotch for raising the issue.
The only question I have is regards caiming back the free space in the hard drive that is not recognised by mac or windows (as in this attached case below). In that instance, you had made a passing remark in the thread that you can recover that lost space and add it for mac or windows usage per one's wish. My missing space is around 170gb which can come in handy for me.
So, in an ideal world, I was hoping there is a way to do that. Having said that, where things are now with everything working in my machine, I am more than happy. Hope that clarifies, thanks.
Currently Being ModeratedAug 3, 2012 10:34 PM (in response to gmtri)
The resize info command is
diskutil resizevolume /dev/disk0s2 limits
and that will tell you how much bigger it can be made. If maximum is ~170MB bigger than current, the actual resize command is
diskutil resizevolume /dev/disk0s2 R
If current and maximum are the same, then I need to see the volume listing from
Currently Being ModeratedAug 3, 2012 10:43 PM (in response to Christopher Murphy)
Thanks, I tried those commands from your earlier post. Unfortunately, the current and maximum are same. I am not in front of my computer now, but the diskutil list command showed 4 discs.
It was very similar to what taylor136's looked like and experienced!... I can show the exact details shortly if that will help.
More Like This
- Retrieving data ...
- This solved my question - 10 points
- This helped me - 5 points