GPT and MBR partition tables, part 2
Tonight I head into the horrible world of EFI GPT vs. MS-DOS MBR and all the insanity that is dealing with A**** and I** firmware design choices. All this to see if I could enable the emergency text console on my iMac, and also to test overriding bad BIOS choices to enable high-performance disk controllers.
I remember grousing on LJ years ago about my troubles working through all the insane bugs and design problems found on modern-day EFI Macs. To sum up the earlier post, EFI introduces the new "GUID Partition Table" format and runs it alongside the old MSDOS "Master Boot Record" format. Both can be found simultaneously on the same disk to describe the partitions on said disk, which means that one has to keep them synchronized or else all hell breaks loose as you get a different view of the disk depending on which table you read.
YUCK. This hybrid mode is a horrid hack necessary to get old versions of Windows to work, because only 32-bit Windows supports only MBR (64-bit Windows supports both). As any IT person can tell you, redundant copies that have to be kept in sync or disaster happens ... is a disaster waiting to happen.
Tonight I tried an experiment in converting my grub-efi Ubuntu installation back to grub-pc (grub for legacy boot mode). Unfortunately that totally mangled the disk, because I didn't realize that grub-pc installs itself in the first 63 sectors of the disk... right on top of the GPT table. grub-pc doesn't detect that it's about to blow away a GPT; it just blows it away.
So the first gotcha is you can lay out a maximum of 4 partitions on a GPT/MBR hybrid drive. The old MBR format only allows 4 partitions unless you chain them via extended partitions, which means you can establish up to 7. GPT, however, can handle 128. Regrettably, the GPT->MBR sync program will only sync the first four GPT partitions, and guess what? The partition editors do not warn you that partitions 5+ will not be sync'd. All your legacy boot OSes have to be in the first four partitions or they won't work. There are no warnings about this!
"Aha!" you say. "Just leave space to create an extended partition!" Well, you can't do that; gptsync just plain doesn't know what extended MBR partitions are. So you're really stuck with 4.
Once I noticed the missing GPT, I simply read the table of partition start and end sectors and recreated a GPT. Problem solved, right?
The second gotcha is that Apple's firmware only looks at the partition table's type codes to find potential OSX partitions. On a plain old MBR disk you'd simply label the HFS partition as type 0xAF and the EFI will go find something bootable. This is what it does if you don't have a GPT (see above). If you *do* have a GPT, then it'll go looking for a partition with GUID "48465300-0000-11AA-AA11-00306543ECAC" and refuse to examine the MBR. Smart, given the first gotcha.
Unfortunately, this brings us to the third gotcha. parted knows how to create a GPT table, but it does NOT know how to assign GUIDs to each partition. It can edit the labels, but not the GUIDs. Lame. That meant that I went from being able to boot rEFIt from the MBR to a Mac that wouldn't boot ANYTHING because the HFS+ partition had a "Windows/Linux data" GUID. LAME.
Ok, that just means we have to edit the GUID in the GPT. It turns out that gdisk does this. So, all I had to do was edit the GUIDs in gdisk, reinstall grub-efi-ia32 on the FAT32 EFI system partition, and reboot. Finally it works. Four hours of life down the drain for this idiocy.
Why did I bother trying to go from booting Linux via EFI back to booting via legacy? I was curious to see if I could jump out of X back into the text and/or framebuffers. Turns out that text mode works in legacy mode but has some bug where it always thinks it's in 80x25 mode (this makes it unusable) ... and AHCI is disabled. In EFI mode AHCI _is_ turned on, which enables advanced SSD features like command queueing and TRIM support. Just FYI, in both modes the framebuffer can be used to boot the system, but once X starts, the old console is gone until the next reboot.
Here's a fun tip if you find yourself stuck in legacy mode: if you add "setpci -d 8086:27c4 0x96.b=0x80" (SCRAE bit) and "setpci -d 8086:27c4 0x90.b=0x40" (AHCI/IDE mode) to grub, you can whack the SATA controller into AHCI mode before Linux starts. It even seems to stay in AHCI mode after a sleep/resume cycle. Note that the location changed on ICH10; on that, one only needs "setpci -d 8086:3a20 0x90.b=0x60" to enable AHCI. For those of you on the Internet, YMMV. This AHCI quirking is a horrid hack that could very well format your hard disk, and, really, your system vendor should give the user a way to enable AHCI mode. Most do, but some are bone-heads and set the controller to compatibility (ata-piix) mode.
Or, if you prefer, a shell script to perform the ICH10 quirk. You'd probably want to put this in the Linux initrd _before_ it loads the disk drivers.
if [ "$(cat /sys/devices/pci0000\:00/0000\:00\:1f.2/vendor)" = "0x8086" -a \
"$(cat /sys/devices/pci0000\:00/0000\:00\:1f.2/device)" = "0x3a20" -a \
! -e /sys/devices/pci0000\:00/0000\:00\:1f.2/driver ]; then
modprobe fakephp
setpci -v -s 0:1f.2 0x90=0x60
echo 0 > /sys/bus/pci/slots/0000\:00\:1f.2/power
echo 0 > /sys/bus/pci/slots/0000\:00\:1f.5/power
sleep 2
echo 1 > /sys/bus/pci/slots/0000\:00\:00.0/power
fi
Enough for now.
Update: 15 April 2012: If you have grub2 (or any EFI bootable) on a FAT partition, use this command to bless it (i.e. set UEFI to boot it):
sudo bless --mount /mnt --setBoot --file /mnt/efi/refit/refit.efi --labelfile /mnt/efi/refit/refit.vollabel
(The labelfile is optional)
If you have an EFI bootable on a HFS+ partition, omit the --mount option and its argument.
I remember grousing on LJ years ago about my troubles working through all the insane bugs and design problems found on modern-day EFI Macs. To sum up the earlier post, EFI introduces the new "GUID Partition Table" format and runs it alongside the old MSDOS "Master Boot Record" format. Both can be found simultaneously on the same disk to describe the partitions on said disk, which means that one has to keep them synchronized or else all hell breaks loose as you get a different view of the disk depending on which table you read.
YUCK. This hybrid mode is a horrid hack necessary to get old versions of Windows to work, because only 32-bit Windows supports only MBR (64-bit Windows supports both). As any IT person can tell you, redundant copies that have to be kept in sync or disaster happens ... is a disaster waiting to happen.
Tonight I tried an experiment in converting my grub-efi Ubuntu installation back to grub-pc (grub for legacy boot mode). Unfortunately that totally mangled the disk, because I didn't realize that grub-pc installs itself in the first 63 sectors of the disk... right on top of the GPT table. grub-pc doesn't detect that it's about to blow away a GPT; it just blows it away.
So the first gotcha is you can lay out a maximum of 4 partitions on a GPT/MBR hybrid drive. The old MBR format only allows 4 partitions unless you chain them via extended partitions, which means you can establish up to 7. GPT, however, can handle 128. Regrettably, the GPT->MBR sync program will only sync the first four GPT partitions, and guess what? The partition editors do not warn you that partitions 5+ will not be sync'd. All your legacy boot OSes have to be in the first four partitions or they won't work. There are no warnings about this!
"Aha!" you say. "Just leave space to create an extended partition!" Well, you can't do that; gptsync just plain doesn't know what extended MBR partitions are. So you're really stuck with 4.
Once I noticed the missing GPT, I simply read the table of partition start and end sectors and recreated a GPT. Problem solved, right?
The second gotcha is that Apple's firmware only looks at the partition table's type codes to find potential OSX partitions. On a plain old MBR disk you'd simply label the HFS partition as type 0xAF and the EFI will go find something bootable. This is what it does if you don't have a GPT (see above). If you *do* have a GPT, then it'll go looking for a partition with GUID "48465300-0000-11AA-AA11-00306543ECAC" and refuse to examine the MBR. Smart, given the first gotcha.
Unfortunately, this brings us to the third gotcha. parted knows how to create a GPT table, but it does NOT know how to assign GUIDs to each partition. It can edit the labels, but not the GUIDs. Lame. That meant that I went from being able to boot rEFIt from the MBR to a Mac that wouldn't boot ANYTHING because the HFS+ partition had a "Windows/Linux data" GUID. LAME.
Ok, that just means we have to edit the GUID in the GPT. It turns out that gdisk does this. So, all I had to do was edit the GUIDs in gdisk, reinstall grub-efi-ia32 on the FAT32 EFI system partition, and reboot. Finally it works. Four hours of life down the drain for this idiocy.
Why did I bother trying to go from booting Linux via EFI back to booting via legacy? I was curious to see if I could jump out of X back into the text and/or framebuffers. Turns out that text mode works in legacy mode but has some bug where it always thinks it's in 80x25 mode (this makes it unusable) ... and AHCI is disabled. In EFI mode AHCI _is_ turned on, which enables advanced SSD features like command queueing and TRIM support. Just FYI, in both modes the framebuffer can be used to boot the system, but once X starts, the old console is gone until the next reboot.
Here's a fun tip if you find yourself stuck in legacy mode: if you add "setpci -d 8086:27c4 0x96.b=0x80" (SCRAE bit) and "setpci -d 8086:27c4 0x90.b=0x40" (AHCI/IDE mode) to grub, you can whack the SATA controller into AHCI mode before Linux starts. It even seems to stay in AHCI mode after a sleep/resume cycle. Note that the location changed on ICH10; on that, one only needs "setpci -d 8086:3a20 0x90.b=0x60" to enable AHCI. For those of you on the Internet, YMMV. This AHCI quirking is a horrid hack that could very well format your hard disk, and, really, your system vendor should give the user a way to enable AHCI mode. Most do, but some are bone-heads and set the controller to compatibility (ata-piix) mode.
Or, if you prefer, a shell script to perform the ICH10 quirk. You'd probably want to put this in the Linux initrd _before_ it loads the disk drivers.
if [ "$(cat /sys/devices/pci0000\:00/0000\:00\:1f.2/vendor)" = "0x8086" -a \
"$(cat /sys/devices/pci0000\:00/0000\:00\:1f.2/device)" = "0x3a20" -a \
! -e /sys/devices/pci0000\:00/0000\:00\:1f.2/driver ]; then
modprobe fakephp
setpci -v -s 0:1f.2 0x90=0x60
echo 0 > /sys/bus/pci/slots/0000\:00\:1f.2/power
echo 0 > /sys/bus/pci/slots/0000\:00\:1f.5/power
sleep 2
echo 1 > /sys/bus/pci/slots/0000\:00\:00.0/power
fi
Enough for now.
Update: 15 April 2012: If you have grub2 (or any EFI bootable) on a FAT partition, use this command to bless it (i.e. set UEFI to boot it):
sudo bless --mount /mnt --setBoot --file /mnt/efi/refit/refit.efi --labelfile /mnt/efi/refit/refit.vollabel
(The labelfile is optional)
If you have an EFI bootable on a HFS+ partition, omit the --mount option and its argument.