Use rEFIt to boot a Super Grub 2 boot disk, and use that to chainload your Debian installation (that can’t boot on itself due to the aforementioned nuked MBR). Also, we’re not home yet, we’re still in legacy mode.

Once in Debian: remove grub-pc and install grub-efi-amd64.

Mount the EFI boot partition and make an EFI boot image for grub using grub-mkimage.

The process is slightly complicated, but it’s the same as Rod’s guide (except I installed Debian and not Ubuntu), up until point 7, where I’m diverging from both of the guides. The main difference is that mennucc1 is basically building him/herself a new boot on the EFI startup partition, containing a separate copies of all Grub modules, kernel images etc. This means, specifically, that it’s completely out of sync with the debian config and needs to be manually maintained at every kernel update.

On the other hand, Rod’s approach didn’t exactly work for me either, because the installation of grub-efi didn’t update the module files in boot, leading to cryptic error messages at boot about »Invalid arch independent ELF magic« and, even worse, to the video drivers not being loaded and thus no image.

So, what I altered was: after generating the EFI image with grub-mkimage (and using my /boot/grub path, (hd0,gpt3)/grub as argument to -p) and placing it in a separate folder on the EFI boot partition (that is (hd0,0) on my computer, or sda1 – probably is on yours, too), I simply copied every .mod file from /usr/lib/grub/x86_64-efi/ to /boot/, overwriting the old files from grub-pc. After a reboot, Grub launched and booted Debian as expected.

It seems that what the -p argument does is setting the root partition for GRUB, from which it loads its modules and config files. In addition to this, I also updated /etc/default/grub to add GRUB_VIDEO_BACKEND=”efi_gop”, followed by the usual update-grub before reboot.

When everything works, delete the BIOS boot partition, as in Rod’s guide.

It’s worth mentioning that I have a quite complicated setup with encrypted LVM, and that everything worked out of the box once the grub.efi image was in place (and the correct .mod files copied to /boot/), save for the keyboard layout for the encryption password. Fortunately, I can still type with qwerty, just not very fast. I’d guess, however, that this is just a matter of passing the right module the right parameters somewhere.

For those who are interested, the boot process now goes something like this: EFI firmware → rEFIt → grub.efi on (hd0,0) → module files and settings on (hd0,gpt3)/grub/ (a.k.a. /boot/) → Linux kernel (also on (hd0,gpt3)).

Known problems

If I Insert a USB stick before I boot, this will be assigned to hd0 in grub, leading to grub.efi failing to load its settings or modules, since they are now at (hd1,gpt3)/grub, their device number having been incremented by one. I suppose this could be solved by using disk UUID for the -p argument in grub-mkimage.

Why going through all that trouble?

Well, mainly because I’m not fond of Debian being treated as a second-class citizen on the computer, running in an emulated BIOS legacy mode, but also because some functions aren’t available in that mode.

I hope someday this will be the default boot mode in Debian on Macintoshes. Actually, this shouldn’t be very far away, since everything I’ve done could easily be automated by debian-installer.

What lies ahead?

The, long, hard road to the perfect configuration. Also, playing around with Mac OS X to see how far I can customize it into something actually useful (think tiling window manager, Emacs, a package manager and much less fancy graphics, rounded corners and semi-transparency).