Intel-based Mac Boot Incompatibility

Surprisingly, you can’t boot both PowerPC-based Macs and an Intel-based Macs from a single drive (internal or external). The Intel-based Macs use a new partition scheme — GUID Partition Table — that’s incompatible with the previous scheme. You can get the gory details in my TidBITS article.

This stands to be a headache for folks who support Macs (including your own!), so it’s best to understand the issues involved before called upon to Save The Day.

Update: Some nuggets instigated by Dan Knight:

• It’s not just booting. GPT drives can’t be mounted by Macs that don’t understand GPT. That appears to be any Mac running 10.4.2 or earlier. Long term, this may be a worse compatibility headache than booting is today.

• Dan asked if GPT was “better” than APM. Intuitively, I was going to respond: yes, of course it is, how can you run such a great, informative website and think that a new partition format isn’t better than all that came before it, why the people who craft partition schemes all meet up to go body-boarding in Maui every year, where they discuss what crushing limitations they’d remove if somebody — anybody — would only allow them to ship a new incompatible partition scheme to an unsuspecting world.

  Then I sat down an compared the specifications. It turns out GPT isn’t better than APM. GPT has better checksumming (is that a word?), but it’s limited to two terabytes in size. I’m surprised this “new” scheme doesn’t use 48- or 64-bit sector addressing. In fact, APM supports volumes larger than 2TB, although you have to increase the sector size (both schemes use 32-bit sector addressing, however GPT assumes a 512 sector size while APM specifies it).

  Next time, someone buy me a ticket to Maui. I need to talk some sense into these partition scheme guys.

• You can boot off USB drives on Intel-based Macs. This opens the world of USB 2.0-only drives to Macs users as bootable backup devices. That sound? It’s David Nanian drooling.

Update: There’s a subtlety here pointed out by Eric Gouriou. If you read the GPT format carefully, you’ll notice it does set aside eight bytes (64-bits) for Logical Block Addresses. Only the backwards-compatible “Protective” MBR uses 32-bit addressing.

I suspect when we start bumping our heads against the 2TB limit, PCs+Macs will learn to simply ignore the limiting Protective MBR on GPT drives, getting the real partition data from the 64-bit GPT Partition Table Header at physical block 1. That nicely blows away the 2TB GPT limit.

That said, nothing in this update should be construed as a reason to withhold crucial Maui tickets.

Update: The plot thickens — the installer DVD that ships with the iMac is bootable. It’s also APM. So, the EFI subsystem does know how to handle and boot from APM disks. Following tips from Robert Mohns and Jolin Warren (pointing to http://appleintelfaq.com/imac/diskutil.html), I successfully populated a single Firewire drive that can boot both types of Macs. Rough outline:

• Reformat the drive as APM with at least two partitions. Name one partition “PPC” and the other “Intel”.

• Install Mac OS X 10.4.4/PPC (who’s current build number is 8G32) on the “PPC” partition using a PowerPC-based Mac.

  Normal so far.

• Install Mac OS X 10.4.4/Intel (current build number 8G1165) onto the “Intel” partition.

  This is easier said then done. You can’t just boot off the System Installation DVD — that’s where you run into the “You cannot install Mac OS X on this volume. Mac OS X cannot start up from this volume.” blocker. Instead, you need to install onto a different partition on your internal hard drive. Once installed, use Disk Utility’s “Restore” tab to perform a block-level from the internal partition to the “Intel” partition.

  I tried just just copying from the original internal partition using Disk Copy, but that yielded a crippled system (falling into console mode with launchd sputtering about nibindd spawning too quickly). It seems block-level mode is necessary, at least with Disk Utility. I also tried SuperDuper, but that crashed on launch. I suspect I need an Intel-compatible version.

Now you’ll have one drive with two mutually exclusive systems on it. You’ll kernel panic if you select the wrong one for the system you’re one, but that shouldn’t cause any damage. Just restart, hold down the option key and use the firmware volume picker to select the partition which matches your machine’s architecture.

Now, the question that comes to mind is, if Intel-based Macs can indeed boot from APM drives, why does the Mac OS X Installer go out of its way to not allow installation on APM drives? Right now I’m guessing a quality control issue was discovered late in the game and Apple made the decision to just block that route than hold up to fix it. But that’s just a guess.

Update: Joe Jackson writes:

I tried just just copying from the original internal partition using Disk Copy, but that yielded a crippled system (falling into console mode with launchd sputtering about nibindd spawning too quickly). It seems block-level mode is necessary, at least with Disk Utility. I also tried SuperDuper, but that crashed on launch. I suspect I need an Intel-compatible version.

Been there, done that. ;-) Your system copy was crippled because a bunch of files that need to be owned by “root” were owned by your normal user account. Disk Utility’s Restore feature botched the permissions because the external drive was mounted with the “Ignore ownership on this volume” turned on when the restore was done. Here’s the best part: if you tell Disk Utility to “Erase Destination” when doing a restore, it also turns the “Ignore ownership” option back on for external drives. Disk Utility reports the state of that option at the bottom of the window, but doesn’t let you change it.

So you don’t need to use a block-level copy to make copied systems work. Just erase the external disk first, use the Finder Get Info window to turn “Ignore ownership” back off, then use Disk Utility to perform a restore without the “Erase Destination” option. I did it that way, and it worked fine.

Monday, January 30, 2006
12:00 AM