Here you go!
gpt show: disk0: mediasize=3000592982016; sectorsize=512; blocks=5860533168 gpt show: disk0: Suspicious MBR at sector 0 start size index contents 0 1 MBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B 409640 1953125000 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC 1953534640 1269544 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC 1954804184 1576 1954805760 1953122304 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 3907928064 1120 3907929184 1952341800 5 GPT part - 48465300-0000-11AA-AA11-00306543ECAC 5860270984 262151 5860533135 32 Sec GPT table 5860533167 1 Sec GPT header
.. and ..
Disk: /dev/disk0 geometry: 97451/255/63 [1565565872 sectors] Signature: 0xAA55 Starting Ending #: id cyl hd sec - cyl hd sec [ start - size] ------------------------------------------------------------------------ 1: EE 1023 254 63 - 1023 254 63 [ 1 - 409639] 2: AF 1023 254 63 - 1023 254 63 [ 409640 - 1953125000] HFS+ 3: AB 1023 254 63 - 1023 254 63 [1953534640 - 1269544] Darwin Boot *4: 07 1023 254 63 - 1023 254 63 [1954805760 - 1953122304] HPFS/QNX/AUX
Short version is that I agree with your assessment that this is not supported by Apple. Anyone doing this is advised to have a most aggressive and consistent backup strategy. That should be the case anyway with any Boot Camped disk, but all the more the case with this 2.2+TB disk work around for Boot Camp.
Long version is that I think the work around is interesting. I'll bet Apple would consider the work around a bug and may try to close it if they ever figure out it's possible. I say that because Apple's tools, both Disk Utility and diskutil, refuse to produce a hybrid MBR if the GPT contains 5 or more partitions. MBR can only contain four partitions. In a Lion or Mountain Lion installation, three partitions are needed: EFI System, OS X, and Recovery HD. This leaves one partition for one additional BIOS booting OS.
For a good primer, and then some, on hybrid MBRs (vs protective MBRs) see this article by Rod Smith, the developer of GPT fdisk (gdisk) and rEFInd, the EFI boot manager:
Bill's around gets around the Disk Utility limitation by creating three partitions, but are actually four due to the EFI System partition. One partition is formatted as a FAT32 volume, therefore a hybrid MBR is created. The installer then splits the first HFSJ partition into two to make the Recovery HD. But instead of nuking the hybrid MBR entirely as a result of a fifth partition being created like Disk Utility would, the installer seems to just drop the MBR entry for the last partition, which is Bill's 2nd HFS+ data partition. Since there can be no MBR entry for it (no more entries, and MBR can't define a location beyond 2.2TB anyway), the main negative consequence is this volume can't be accessed from within Windows, no matter what file system is used.
Normally, if only Disk Utility is used to add another partition to a disk already containing four, like what happens when people with OS X and Windows already installed want another partition for data, the result is the hybrid MBR is blown away in favor of a protective MBR, and access to Windows is lost. It simply vanishes. (Access can be restored with a tool like gdisk, but it's a CLI only application, and exactly what to do in each instance isn't exactly obvious.)
There is anecodatal evidence from these and other forums that upon major upgrades (SL to Lion, Lion to ML) if the disk contains 5+ partitions, and/or the GPT and MBR are not in sync, something during installation causes the hybrid MBR to be replaced with a protective MBR. So again, good reason to make judicious backups especially before using Disk Utility to make repairs or OS updates/upgrades. I don't know exactly what causes this to occur so I can't say exactly what situation to avoid.
Anyway, Boot Camp is a rabbit hole. It gets vastly deeper and more risky with each "unsupported" behavior added on, and this one adds both a fifth partition as well as a disk larger than 2.2TB. Risky in that if anything modified either the MBR or GPT, it'll get messy fast! But at Bill now has in effect backed up both his MBR and GPT partition schemes on Apple's forums so his chances of recovery should something get messed up, are much better. So it's not a bad idea to take a snapshot of your current partition mappings if you go down the rabbit hole.
As for why there's a limitation on disk size: Apple hardware supports Windows through an EFI compatibility support module, called the CSM. It's BIOS baked into an EFI module. In effect when booting Windows, Apple hardware has BIOS. When booting OS X it uses only EFI. EFI specifies GPT partition scheme. Windows booted in BIOS mode only honors MBR boot disks, hence the need for hybrid MBRs on Apple hardware. And MBR encoding only supports disk sizes of 2.2TB or less. So the problem is a combination of limitations. The long term solution is for Apple to support EFI mode boot of Windows, and it's unclear if that will happen as none of Apple's hardware meets the minimum Windows requirement for UEFI 2.x spec firmware or greater. Apple EFI is based on the Intel EFI 1.10 spec. Nevertheless some people are having varying degrees of success getting Windows 8 to boot on Apple hardware in EFI mode. There's a huge thread on Mac Rumors of people working on this.
No because Fusion Drive is leveraging Core Storage which is an Apple logical volume manager. It requires XNU to be running first to implement Core Storage. Meaning you can take advantage of this through a VM, but not natively booting Windows which will have no way of understanding the proprietary on-disk-format to make Fusion work.
OK, no Fusion Drive to the Windows partition (2nd partition), but what about the 1st Partition (Partition 1 - OSX (HFS)? When I remove the coreStorage Logical Volume Group to divide the HDD in 3 partitions it is definitive or it can be restored to allow the OSX to use the Fusion Drive functionality? (Im sorry if theres any flaw in my question - Im not an expert in the system core functions)
I don't know how smart the new Disk Utility and Boot Camp Assistant are in dealing with this situation. The message boards are littered with people experiencing data loss because Disk Utility can do the wrong thing when the user goes even slightly off script: the script is to use Boot Camp Assistant for everything related to setting up drives for use with Windows.
But based on what I've read you should be able to use Boot Camp Assistant to make a Windows volume on either the SSD or HDD; and then the remaining space on both SSD and HDD can be used by Core Storage as a Fusion drive for OS X. But you have to have Windows entirely on SSD or entirely on HDD.
I am trying to do the method above but its keeps saying "Ownership of the affected disk is required" how do i get that and what are the commands and my new imac wont let me boot off a mac osx lion disk that i burnt through the dmg through the appstore why is it doing that ? I wanna do this so i can run terminal through the setup disc.
xxxx-iMac:~ xxxx$ diskutil coreStorage list
CoreStorage logical volume groups (1 found)
+-- Logical Volume Group xxxxx
Name: Macintosh HD
Size: 1483372879872 B (1.5 TB)
Free Space: 0 B (0 B)
+-< Physical Volume xxxxxxxx
| Index: 0
| Disk: disk0s2
| Status: Online
| Size: 1483372879872 B (1.5 TB)
+-> Logical Volume Family xxxx
Encryption Status: Unlocked
Encryption Type: None
Conversion Status: NoConversion
Conversion Direction: -none-
Has Encrypted Extents: No
Fully Secure: No
Passphrase Required: No
+-> Logical Volume xxxx
Size (Total): 1483054104576 B (1.5 TB)
Size (Converted): -none-
LV Name: Macintosh HD
Volume Name: Macintosh HD
Content Hint: Apple_HFS
xxxx-iMac:~ xxxx$ diskutil coreStorage delete UUID
Error deleting CoreStorage Logical Volume Group: Not a valid CoreStorage Logical Volume Group UUID (-69778)
xxxx-iMac:~ Jerry$ diskutil coreStorage delete UUID disk0
Usage: diskutil coreStorage delete lvgUUID
Delete a CoreStorage logical volume group. All logical volumes will be removed.
Ownership of the affected disk is required.