Installing Linux on Sandybridge MacBook Air

Matthew Garrett got a report from someone who bought a brand new Sandybridge MacBook Air and was trying to install Fedora on it. The screen went black as soon as the i915 driver tried to set the initial mode.

I bought one to try and help out. Just getting Linux installed turned out to be a minor adventure and I thought I'd write a few notes for the next person who comes along and tries to do this.

The obvious method

I downloaded a collection of Debian ISO images, live images, netboot images from testing and CD-1 of squeeze. I downloaded a Fedora 16 alpha XFCE live image. I burned all of these to actual CDs, and then stuck them in a CD drive and held the 'c' key while booting the machine.

Nothing worked. The CD would spin up, the screen would switch from white to a black text mode with a blinking cursor at the upper left and then then CD would stop.

rEFIt attempts

rEFIt provides a boot selection menu and various configuration bits to provide for a multi-boot environment. This is necessary to leave the OS-X install on the disk and also install Linux.

It also lets you boot from removable media, or at least that was the story. rEFIt would list removable USB flash storage devices, but it would not list CD drives, even after the CD drive spun up and did stuff for a while. This makes me wonder if the 'c' key technique wasn't actually trying to boot from the CD.

However, rEFIt wouldn't boot from a grub2-enabled USB key.

ISO on USB flash key

What rEFIt will boot is a Fedora or Debian ISO image copied directly to the USB flash device. The Ubuntu 11.04 live image and it did not work.

Fedora F16 Alpha

The live image came up and started X in frame buffer mode. However, when I went to install the image to the hard disk, it got stuck trying to discover devices. I waited about 20 minutes and it never finished, although it did chew up a lot of CPU time.

Debian Squeeze

I copied CD-1 of the 32-bit Squeeze distribution to my flash key. That booted up to text mode and went through the install. Nothing really unusual until it came to installing grub. I let it install grub to /dev/sda4, the new partition I had created for Linux. I figured installing grub to /dev/sda would be a bad idea (I think it would have actually worked just fine in retrospect).

A slight out-of-sync diversion here -- I couldn't get the 32-bit kernel to talk to any keyboard or USB networking device, so I eventually installed a 64-bit kernel and that works just fine. You can run a 32-bit user space with a 64-bit kernel without any trouble.

Making EFI boot

Naturally, I couldn't get the machine to boot to Linux after this. rEFIt, the multi-boot tool for Mac OS X appears only interested in booting EFI images, or at least was not interested in booting my BIOS-based Grub2 installation on /dev/sda4.

I used the 'rescue' mode on the USB flash drive to get back to my installed Linux image and installed grub-efi-amd64. The OS X EFI version does not support 32-bit EFI code, which seems entirely reasonable to me.

What took a while was figuring out that all of the grub files need to be readable through EFI, and that the Mac EFI code can only read FAT (and HFS?) partitions.

So, the trick appears to be to stick the grub files on the Mac OS X efi partition (/dev/sda1). I created a directory over there, /EFI/grub and then mounted that as /efi and made a symlink from /boot/grub to /efi/EFI/grub. Now, grub-install sticks the files in the right place, and update-grub will even place grub.cfg in the directory where it needs to go.

At this point, rEFIt will happily find the core.efi and grub.efi files and show them in the list of possible operating systems to boot. I don't know why there are both core.efi and grub.efi files; I've only ever picked 'grub.efi' and that has worked nicely.

Broadcom WiFi

I haven't gotten that working yet; the b43 supported chip list says it works in kernel 3.1. I'm busy building a 3.1-rc4 kernel as I type this, so perhaps that will 'just work' when I boot that.

i915 KMS

The whole reason for doing the install is to fix problems with the eDP EDID discovery which is currently preventing the machine from running X. I'll be working on that next; a quick kludge to just read the current mode from the device should get something on the screen (we already do that for LVDS panels). Beyond that, I'll be trying to figure out whether I can make EDID actually work, or whether it's just not available in this machine.

Somehow the kernel frame buffer ended up as 1280x800, which was quite annoying. As a temporary kludge, I ran fbset -yres 768 to at least avoid having text disappear off the bottom of the screen. Once the panel size is discovered correctly, that should be fixed.

Status

This is sure not like installing Linux on a regular PC. However, I'm reasonably hopeful that the devices in the machine will be working pretty well under Debian within the next few days.