srs5694

Actually, it is possible to boot OSes from logical partitions -- Linux can be installed in this way, among others. The trouble is that you need a boot loader that supports that type of installation, and the Microsoft-style boot loaders can't handle it. My knowledge of Hackintosh boot loaders is limited, so I don't know what their precise capabilities are, but the last I checked, installing to a logical partition was discouraged. You might be able to get it to work by using GRUB 2, which includes support for booting OS X kernels; however, this support is primitive and flaky compared to typical Hackintosh boot loaders such as Chameleon. Another option might be to convert the partition from logical form to primary form. Not many partitioning tools can do this, but one that can is FixParts. There are probably other tools that can do this, but I'm not sure what they are.

I realize you posted later that you've worked around the problem, but the fact is that your hard disk is in an extremely dangerous state. Your MBR and GPT data no longer match each other. Depending on the details of how this is laid out, you could end up having one OS overwrite another OS's data. OTOH, it could be that there's no risk of this happening, but future partitioning operations could cause you to lose access to your Windows data partition. As a general rule of thumb, you should never attempt to modify a disk with a hybrid MBR (which is what you've got) using Windows' disk partitioning tools. You should also never use extended or logical partitions on a disk with a hybrid MBR. Both practices are recipes for disaster. It's probably possible to repair this damage, but I can't be certain without seeing details of both the GPT and the MBR partition tables. You can provide that information by running the following commands in OS X: sudo gpt -r show disk0 sudo fdisk /dev/disk0 Please post the results here, between [ code ] and [ /code ] tags for legibility. In the meantime, you might want to read up on hybrid MBRs at my Web page on the topic. Note that I read this forum rather sporadically. I'll make it a point to check back regularly for a couple of days, but if you post after that, please send me a PM or an e-mail (you can use the link on my hybrid MBR Web page) to alert me to the new information.

AFAIK, it's not possible with Chameleon, but it is possible with UEFI DUET: http://www.rodsbooks.com/bios2uefi/index.html https://gitorious.org/tianocore_uefi_duet_b...64_BIOS_to_UEFI http://www.insanelymac.com/forum/index.php?showtopic=186440

I believe you're confusing the Extensible Firmware Interface (EFI) and the GUID Partition Table (GPT). EFI (or its newer variant, UEFI) is software that's stored in a chip on the motherboard -- that is, firmware. Intel-based Macs use EFI, and many recent PCs use UEFI. Older (and some current) PCs use the older Basic Input/Output System (BIOS) firmware. Most PC OSes boot in BIOS mode, although support for (U)EFI booting has been slowly appearing. In Linux, aside from some exotic non-x86 implementations, (U)EFI booting has only been practical for a couple of years, and even now most distributions provide weak support. AFAIK, all Hackintosh boot loaders are BIOS-based, but they typically set up a partial or even a complete EFI environment atop the BIOS to make OS X happy. GPT is a partitioning system used on hard disks. It's defined as part of the EFI specification, but you can use GPT on a BIOS-based computer. GPT is likely to eventually replace the Master Boot Record (MBR) partitioning system that most PCs have used for 30 years, since MBR has a disk size limit of 2 TiB (assuming a 512-byte sector size) and GPT's limit is much higher. Intel-based Macs ship with GPT hard disks, and Apple's OS X installer wants to see a GPT disk (but there are ways around this limit). The support figures you mention (Linux since 2000, Vista since SP1, Chameleon works with it) all apply to GPT, but they don't all apply to EFI. As to the original question, I don't know how practical it is to install OS X on a UEFI-based PC, at least in UEFI mode. AFAIK, all the common Hackintosh boot loaders are built for BIOS, which means that if you boot the PC in UEFI mode, those BIOS-based boot loaders won't work. That said, most UEFI implementations let you switch between UEFI mode and a BIOS compatibility mode, so it is possible to install OS X as you would on an older BIOS-based computer -- ironically, you use an EFI emulation atop a UEFI firmware's BIOS compatibility mode to do the job. If other OS(es) on the computer boot in UEFI mode, though, you may need to manually switch modes when booting between OSes, which may be awkward. Also, there may be a UEFI-mode Hackintosh boot loader available or under development, or a way to get a Hackintosh to boot more directly using the built-in UEFI implementation. If so, I don't know where the instructions are to do such a thing. (I'd be interested in this myself, since I'm planning to build a new computer before too long, and it will be UEFI-based.)

I don't know about Chameleon specifically, but a lot of boot loaders include 32-bit disk sector number limits, and that limits their ability to boot anything from above the 2 TiB mark. If some critical file happens to fall above that point, the boot will fail. I can't say with certainty that you're running into this specific problem, but you might be. Certainly it's worth repartitioning your disk and trying again. IMHO, this is advisable anyhow -- for flexibility when re-installing, it's best to separate your OS system files from your personal data files so that you can wipe the OS clean without affecting your personal data. With a 3 TB disk, this is even more important, since it's hard to back up and restore so much data, should you need to completely wipe the installation partition.

Sorry to burst your bubble, but that's almost certainly not a "pure GPT" installation, at least not in the sense of having a fully valid GPT configuration with a protective MBR rather than a hybrid MBR. When you tell Apple's Disk Utility to create a FAT partition, it converts the disk from a GPT format into a hybrid MBR. None of your subsequent steps changed this configuration. If you want to check this, I recommend you run my GPT fdisk (gdisk) program on the disk. You can use either the Windows or the OS X version. When you launch it, you'll see output like this: $ [b]sudo gdisk /dev/disk0[/b] GPT fdisk (gdisk) version 0.7.2 Partition table scan: MBR: hybrid BSD: not present APM: not present GPT: present Found valid GPT with hybrid MBR; using GPT. In this example, the "partition table scan" output clearly identifies the disk as having a hybrid MBR. On a pure GPT disk, the output is different: $ [b]sudo gdisk /dev/disk1[/b] GPT fdisk (gdisk) version 0.7.2 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Note that in this case the MBR is identified as being protective rather than hybrid. This indicates what I'd call a "pure GPT" disk. AFAIK, the only way to boot Windows on a pure GPT disk is to use a UEFI implementation. Many motherboards introduced this year, and a few sold in previous years, provide a UEFI boot option. It's also possible to add UEFI support to many non-UEFI motherboards by using UEFI DUET, as described here, although the software and procedures for doing that should be considered highly experimental. FWIW, you're not the first person to be deceived in this way. I've seen plenty of posts on this forum from people who think they've found the magic incantation required to get Windows booting from a GPT disk on a BIOS-based computer. These procedures usually involve using Disk Utility to create a FAT partition, and upon further investigation they've all proven to be using hybrid MBRs (except for the UEFI DUET method).

I've just made a final 0.7.2 release that includes the new type code. In gdisk, it shows up as type 8300, "Linux filesystem". There's no point in involving the kernel developers, since the kernel doesn't currently use GPT GUID type codes except to detect LVM partitions -- or at least, I couldn't find any references to GPT GUID type codes except for that one purpose. (AFAIK, the kernel doesn't currently use MBR type codes, either.) Thus, a new Linux-only type code doesn't affect the kernel unless you wanted to redesign the kernel to use those type codes. I don't think there'd be much point to doing so, since decisions about creating, mounting, and otherwise using and manipulating partitions are all done in userspace. Except that the kernel has nothing to do with this; it's the installers, which rely on libparted, that look at the disk and decide how to partition it and where to install. That's why I contacted the parted developers. They haven't responded to my last patch, though, which I submitted over a day ago, so I don't know if they're interested. I've tested, BTW, and both Ubuntu 11.04 and Fedora 15 are perfectly happy to install on the new type code (or, presumably, any type code), although I expect they'd change it to a Microsoft Basic Data type. Presumably that would change if libparted were to support the new type code. I'd never really intended the 'R' option to be used in the way you've used it; it was there as a side effect of code intended to enable setting the unique GUIDs to random values. In changing the user interface code to simplify entry of specific unsupported GUIDs for the partition type code, the 'R' option got lost in that context -- at least mostly. You can still get a random partition type GUID by typing 'R' followed by 31 or more other characters. It's still there when entering unique GUIDs for partitions or the disk as a whole, too. Because your reason for using a random GUID is simply to hide the Linux partition from Windows, using any partition type code that Windows doesn't recognize and that "belongs" to an OS you don't run would work as well. Of course, now you can use the gdisk 8300 code.

Laqk, I've tracked down the problem, and it turns out it is related to the not-quite-GUIDs that the Windows version of gdisk generates -- but Windows seems to be "allergic" to these only in very specific circumstances, which threw me at first. Also, Vista is fine with it; only Windows 7 (both 32- and 64-bit versions) is affected. Anyhow, I've managed to get Windows to generate real GUIDs, and that fix will be released with the next version of GPT fdisk (0.7.2). I'm hoping to get it out soon, but for the moment I'm sitting on it because I'm trying to coordinate creation of a new GUID partition type code for Linux filesystems with the parted developers. I've already got the code in GPT fdisk, but I'd like to get the parted people to accept my patches related to this before I put that support in a released version of GPT fdisk, since I don't want some last-minute change in the GUID code to cause problems. To bring this on topic, this is relevant to UEFI DUET because a unique type code for Linux will keep the Linux partitions from showing up in Windows when you install both under UEFI DUET. As it is now, Linux partitions appear under Windows, and if you double-click them, Windows claims they must be formatted -- but doing that would wipe your Linux installation. (IIRC, this behavior is old new for this thread, and there are workarounds, but a proper Linux-only filesystem type code is sorely needed.)

Some more on this: I've reproduced this problem. It occurs only on hard disks (not on USB flash drives), and on Windows 7 64-bit but not Windows Vista 32-bit. It is not, as I initially speculated, a reaction to the not-quite-GUIDs that the Windows version of GPT fdisk generates -- at least, not in and of itself. It appears to be a problem of Windows not properly recognizing the change from an MBR partition table to GPT. (A conversion from nothing to GPT is fine, though.) Unfortunately, Windows seems to "remember" the crash and repeats it the next time you boot or insert that same disk. Changing the disk's primary GUID code fixes the problem, whereafter restoring the disk to the state that caused the crash to begin with has no ill effects, so it's clearly not the state of the data structures created by gdisk alone. I'm looking into real fixes, but for now my suggested workaround is to use a Linux boot to do the MBR-to-GPT conversion. Alternatively, if you've got a Vista 32-bit installation, you could use that to do the conversion.

That's puzzling. Does your Windows installation boot via BIOS or UEFI? I've never run into this myself, although I do have a vague recollection of hearing about such a problem on a single disk. If you're getting it consistently, though, it's odd. If you could use the gdisk backup feature ("b" on the main menu) to make a backup of a problem disk and e-mail it to me, I'd appreciate it. My only suggestion for a solution is to use the Linux version of gdisk; it's conceivable that the bogus GUIDs generated by the Windows version are causing problems. (The Linux version generates proper GUIDs, but the Windows version just generates random numbers since I haven't figured out how to generate proper GUIDs in Windows.) Check the OBS download links here, use a slightly older version (only 0.7.1 uses the ICU libraries), or boot up PartedMagic or some other Linux emergency disc that includes gdisk.

The UEFI DUET method does not mess with your BIOS; the UEFI DUET software runs as a normal application, loaded from hard disk, and it doesn't modify your BIOS in any way. OS X can be fussy about its install partition. Most importantly, it likes to see a gap of 128 MiB after (and maybe before) that partition. If that gap isn't present, it won't install to it. The installer also wants the partition to have its journal enabled, which IIRC GParted doesn't do by default (I don't think there's an option to do so, either). For these reasons, using GParted to prepare a partition for OS X installation is definitely not the way to go. If you must prepare the partition in Linux, be sure to leave those 128 MiB gaps and then use mkfs.hfsplus to create the filesystem. That tool has an option (-J) that creates a journal, which should make it more to the OS X installer's liking.

The GPT/MBR thing isn't nearly as solid a wall as 3.14r2 suggests. There are several ways around it, although some options are better than others: Although a stock OS X installer will only install to a GPT disk, OS X boots just fine from an MBR disk. (I think it needs a primary partition, though, which could be an issue, depending on how many primary partitions you're already using.) You can copy your current installation over using Disk Utility, Carbon Copy Cloner, or other tools and then get it working. The biggest hurdle is to get the boot loader installed and working correctly. A mistake on this score can make it hard to boot either OS until you get it corrected. It's possible to convert Windows to boot from a GPT disk by using UEFI DUET. There's a thread on this site that details the procedure, and I've written a Web page on the topic. This approach is very much "bleeding-edge," though. If you wanted to try it, I'd recommend digging up another spare disk for experimentation purposes before converting your existing Windows installation. A hybrid MBR is always a possibility. This makes Windows think the disk is an MBR disk and OS X sees it as a GPT disk. This is an easy solution, and it's the one that Apple uses to boot Windows on real Macs, but it's risky -- I've seen many reports of problems caused by hybrid MBRs. I recommend this option only if others are impossible or very impractical. Overall, I'd agree with 3.14r2 that the optimal solution is to use two disks; however, if the only second disk you've got is a 20 GB model, and if your main disk is something significantly more modern, you might get better performance by copying OS X over to your main MBR disk or installing UEFI DUET so that Windows works from a GPT disk. Note that you can carve up part of your main disk for use as an OS X data disk (even storing applications there) even if OS X itself lives on a secondary disk. In fact, this configuration can have some performance benefits, since there'll be less need for head seeks when the OS needs to access files that would exist on both drives.

One problem with that site is that there's no obvious way to download the whole package as a tarball or a ZIP file. Using git may be OK for people who are already familiar with it, but it's a very specialized tool, and lots of people aren't familiar with it. If there's something I've overlooked, could you please point it out to me? Interesting, but apparently of only theoretical interest -- I ran some tests, and I was unable to get Fedora 15, OpenSUSE 11.4, Ubuntu 11.04, or Windows 7 to boot using the optical disc option in the UEFI DUET Boot Manager. If it works for you, there must be some trick to it, or maybe it only works on some systems. If so, I'd appreciate hearing precisely how you got it to work. Thanks. I am not so well-versed with English language but this sound like DUET does not start in ALL x86_64 computers. I think it should be 'in some of the systems'. To a native speaker, at least of American English, the construction I used clearly means that it works on some but not all computers. Nonetheless, I've changed the wording since clearly not everybody reading the page will be a native English speaker. Thanks for the correction; I've modified the page appropriately. AFAIK, the kernel doesn't use partition type codes at all; they're only used by partitioning tools and other user-space programs. Still, I do appreciate your point, but any way you do it it's a bad choice. I'll try contacting the libparted people to see if I can coordinate creation of a new code for Linux data partitions.... Thanks for the links. FWIW, I considered adding XPC, but I couldn't find anything remotely resembling an authoritative URL for it; like too many things in the Hackintosh world, XPC just seems to be floating around out there on various download sites. If you know of an authoritative reference for XPC, I'll add it, but I don't want to add a link to some random download site that might go away or become a link to something obsolete in a week. BTW, I've done some more testing, and I've had success with UEFI DUET on only two of four computers for version 2.1 and only one of four computers for 2.3. The numbers are small, but one pattern is that the only computer to work with both versions uses an Intel CPU; my other three test computers all have AMD CPUs. That makes me wonder if you might have set an Intel-specific optimization when you compiled the code. If so, unsetting that option would make sense. Of course, it's also possible that the AMD/Intel correlation I'm seeing here is just a coincidence, or there could be something intrinsic to the code itself, rather than compile options, that makes it work poorly or not at all on AMD systems.

This is an old problem. Basically, Windows will only install to a disk that uses so-called Master Boot Record (MBR) partitions on BIOS-based computers, whereas OS X wants to install on (note: "install on;" when running it's more flexible) a disk using the completely different GUID Partition Table (GPT) system. There are three traditional solutions, but a fourth is becoming increasingly workable: Use a hybrid MBR, which is a dangerous and ugly hack that enables MBR and GPT to co-exist (sort-of) on a single disk. Apple uses this on real Macs, and it's a popular choice in the Hackintosh community. I've encountered and heard of too many problems with it to recommend it, though. Install Windows under MBR, then install OS X to a different disk (even a USB flash drive) using GPT, then use Carbon Copy Cloner or some other utility to copy the installation to the MBR disk. This is more work than using a hybrid MBR, but it's safer. Use a hacked installation utility to enable installation directly to an MBR disk. Such utilities exist and are fairly common, but I don't happen to have a URL handy. The newest option is to use UEFI DUET to make your PC look like it's got UEFI firmware. Windows will install to a GPT disk when the computer uses UEFI, so the combination of UEFI DUET and a standard Hackintosh boot loader for OS X should work fine. UEFI DUET is a pretty "bleeding-edge" tool right now, though. You can read about its use here; but for your use, you'd probably want to use GRUB Legacy or GRUB 2 as the MBR-resident boot loader rather than the SYSLINUX that the page describes. Note that some PCs, including many of the latest ones, have UEFI firmware built in and so don't need the DUET software; you'd just need to adjust a firmware option to enable UEFI booting support. Overall, a hybrid MBR is the easiest but most dangerous option. Either of the options to install to an MBR disk is fairly safe and simple, particularly starting from your current situation. UEFI DUET is worth considering if you're into pushing the envelope or if you have a compelling reason to use GPT rather than MBR (such as a 3TB boot disk, for which MBR is inadequate). If you've got a motherboard with built-in UEFI support, I'd recommend using that for your Windows installation; but I'm not sure how this would impact your OS X installation.

It's almost certainly just a matter of having an inappropriate partition type code set. I think that OS X's standard "gpt" text-mode utility can fix this, but I don't recall the exact syntax offhand. You could instead use my GPT fdisk (gdisk) to do the job. It'd go something like this: Launch the program on your disk by typing "sudo gdisk /dev/disk2" Type "p" to view your partitions and verify you're working on the correct disk. Type "t" to change a type code. Enter the partition number and "af00" for the partition type code. Type "p" again to review the change and ensure you changed the correct partition. Type "w" to write the changes to disk. Answer "y" to verify that you really want to save changes. One caveat: I vaguely recall hearing that MacDrive does weird things with partition type codes; you might find that it keeps changing it back or that it won't be able to access the drive after you set the code correctly. I don't recall exactly what the problem is or if there's a fix or workaround, though; it might be something minor or easily fixed.