Problems with rEFIt and GRUB after installation

Many people report problems with rEFIt. rEFIt is needed to dual boot MacOSX and Linux. After installation of Linux and rEFIt, rEFIt won't sync the partition table. The message is then "gptsync: GPT partition of type 'Unknown' found, will not touch this disk". This is what I got when I resized my linux partition using parted, resulting in the GPT and MBR partitions going out of sync. Now this is something rEFIt's gptsync should be able to solve fairly easily, but if you have a so called 'BIOS Boot Partition', a small partition created by grub2 (as shipped with Karmic), then you're in quite some trouble. The partition tables won't sync and you'll find yourself unable to boot your linux system.
( In this example I assume your disk is /dev/sda , default for macbooks, and your root partition is /dev/sda4 , adapt these if necessary! )

1) Download an Ubuntu Live CD ( see ) and burn the ISO to CD.

2) Boot your macbook from the CD (hold option key at startup if you don't have rEFIt)

3) Open a terminal, mount your original root partition

sudo mkdir /mnt/root
sudo mount -t ext4 /dev/sda4 /mnt/root

4) Find the correct package for your architecture on and download it to somewhere under /mnt/root/

5) Set up /proc and /dev

sudo mount -t proc none /mnt/root/proc
sudo mount -o bind /dev /mnt/root/dev

6) Chroot into your original system, you're now in your own system.

sudo chroot /mnt/root /bin/bash

7) Install the package downloaded in step 4

sudo dpkg --install gptsync*deb

8) Run gptsync on the affected disk

sudo gptsync /dev/sda

9) Reinstall grub (this shouldn't overwrite rEFIt, but you can keep a copy of rEFIt on CD if you're concerned)

sudo grub-install /dev/sda

10) reboot, the system should be able to boot again now

It was also reported that when rEFIt works fine, Grub also seems to work fine, actually choosing the Linux partition to boot from, will end up with a black screen, saying "no bootable device found". This is because GRUB does not see a boot flag. The solution is to boot into a liveCD, run gparted (the partitioner in Ubuntu) and to manually set the boot flag on the root partition of Linux, even when you see a boot flag there. After a reboot, GRUB should work as expected.

Please report if you find additional tricks to solve these kind of problems.

Edit 17.03.2010
As rEFIt 0.14 is out, the hope is that problems like these are of the past.

Re: gptsync: GPT partition of type 'Unknown' found, will not touch this disk.

Originally Posted by jamesixgun View Post
Unfortunately, I'm unaware of a fix without a complete wipe and reinstall. If one exists, I hope someone will correct me.

I've posted before in this thread, but people seem to be ignoring me. My own GPT fdisk (gdisk) package can create hybrid MBRs with a great deal of flexibility. It should be possible to use it to fix any problems that are caused by corrupt hybrid MBRs. Please review my earlier posts for additional details and other suggestions, and read my hybrid MBR Web page for information on hybrid MBRs generally and on how to create them in gdisk. Note, however, that I don't have a dual-booting Intel-based Apple Macintosh, so I have no first-hand experience with this specific problem.

Apple uses the GUID Parition Table (GPT) partitioning system, vs. the Master Boot Record (MBR) system that's used on most PCs. Although you can use an MBR disk with Apple hardware, it's probably better to stick with GPT.

When you use Apple's Disk Utility, there's an advanced option hidden away on an options screen somewhere to set the disk type: GPT, MBR, or the Apple Partition Map (APM) system used on PowerPC-based Macs. You can use Disk Utility to set up the disk, as tgalati4 suggests, but you should check that it uses GPT. Alternatively, you can use a Linux partitioner such as GParted and locate the equivalent option. My own text-mode GPT fdisk, available for both Linux and OS X, also sets up GPT disks. IMHO, Apple's Disk Utility is very limited and awkward, so my preference would be to use GNU Parted, GParted, or gdisk for this job.

One quirk of Apple's Disk Utility is that if you tell it to put a FAT filesystem on any partition, it'll convert the disk into a hybrid MBR disk, which is an ugly and dangerous hybrid of GPT and MBR. Apple's Boot Camp relies heavily on hybrid MBRs to boot Windows. I don't believe this is necessary to dual-boot Linux and OS X on a Mac, but my knowledge of the details of such configurations is a bit foggy. Thus, I recommend you research this more, and avoid a hybrid MBR configuration if possible.

On BIOS-based computers, the Linux GRUB 2 boot loader works best if you've got a BIOS Boot Partition on a GPT disk. I don't know if this is useful on an EFI-based system like a Mac, though. If in doubt, you might as well create a BIOS Boot Partition; the worst-case scenario is that you'll lose a tiny bit of disk space. You'll need GNU Parted, gdisk, or possibly GParted to create a BIOS Boot Partition; Apple's Disk Utility won't create one. I don't think an EFI System Partition is strictly necessary, since one will be present on your main disk, but Apple's Disk Utility will create one automatically. Creating one manually in another utility will just consume a small amount of disk space, so to be completely safe, you might as well create one.

Other guy reported this:
Well, I'm confused, but Ubuntu isn't sure what's going on either

Since Windows is pickier about boot tables, I installed it first, setting up the partitions in a dual-boot friendly way (deleted all existing partitions first): 40Gb NTFS, 39Gb unallocated space, and the 100Mb 'system reserve' that W7 likes to have.
Formatted the whole drive to do this.
Installed W7 as usual.
Booted up with Ubuntu 10.04 install disk and proceeded through the install till I got to the partition section when Ubuntu reported that no OS was installed and it was allllll unallocated space.

I booted into Ubuntu from the disk, and GParted tells me it's 75Gb of unallocated space, while the Disk Utility sees the partitions. fdisk gives me the error that 'GPT detected on /dev/sda' and to use GNU Parted. Despite this warning fdisk gives me the partitions that Disk Utility sees.

After some digging, it looks like my problem largely stems from a GPT/MBR hybrid partition table that Windows likely set up. But I would think that Ubuntu should be able to handle this. Or even if it's an EFI problem, doesn't 10.04 recognize all of these? Disk Utility does.

With no OS X I can't really put on rEFIt can I? There is no EFI directory to bless.

So the question is: can I easily fix the GPT/MBR problem without having to put on OS X, put on rEFIt, delete OSX via W7 installation and THEN Ubuntu?
My Google-fu is too weak to find the solution, because every document I've dug up so far all assumes that if you have a Mac, you want to keep an OS X partition on there.

Any assistance is greatly appreciated! Thanks!

Solution again gdisk:
I'm uncertain how Windows 7 will see the computer, or the drive, in your configuration. Windows 7 can boot from GPT disks on EFI-based systems, but I know that Apple's Boot Camp sets up a "fake" BIOS environment for Windows, and in such an environment, Windows will only boot from MBR. I don't know which way it'll work on a Mac without an OS X installation. I can conceive of three possible causes for your problems:

  1. The problem is a bad MBR configuration, such as the one I describe on this Web page. If so, you could fix the problem by editing the MBR table in the way described. I think this is a bit unlikely, though.
  2. Your system has an old GUID Partition Table (GPT) in addition to a new MBR that is not configured with a GPT protective partition. This could be confusing GParted. If so, the solution is to either eliminate the GPT data structures, leaving an MBR-only disk, or to create a hybrid MBR similar to what Apple's Boot Camp sets up.
  3. You've already got a hybrid MBR configuration, but it's corrupt in a way that's confusing GParted. If so, you'll need to either eliminate the GPT data and the protective partition in the MBR (type 0xEE) or regenerate the hybrid MBR, using either the GPT or the MBR data as a base.

In the case of #2 or #3, you can fix the problems with my GPT fdisk (aka gdisk). You should be able to install a somewhat old but still serviceable version in an Ubuntu live CD by typing "sudo apt-get install gdisk" at a shell prompt; or download the latest version from the project download page on Sourceforge. (I recommend the latter approach, if possible, since there have been quite a few improvements and bug fixes since the version in the Ubuntu repositories. Note you can use the Windows version if that's convenient.) Check the GPT fdisk project page, and particularly the sub-pages on partitioning advice, hybrid MBRs, and repairing GPT disks, for more advice.

If you want to create a disk with a plain MBR configuration, use the 'z' option on the experts' menu to destroy the GPT data.

If my hypothesis #2 is correct, then GPT fdisk may ask you whether to use the MBR or GPT data when it launches. Chances are the MBR data is correct, but you should check both of them to be sure.

If my hypothesis #3 is correct, then GPT fdisk will report the problems if you use the 'v' option. Regenerating the hybrid MBR (via 'h' on the recovery & transformation menu) will then be necessary. (You'll also need to regenerate the hybrid MBR if you use the MBR data as a basis for a new hybrid MBR if my hypothesis #2 is correct.)


© 2002-2012 Jeroen Diederen. Drupal theme by Kiwi Themes.