[personal profile] mjg59
Fedora 17 will be shipping next week. It's got a bunch of new features, none of which I contributed to in the slightest. What I did work on was improving our support for installation on x86 Apple hardware. There's still a few shortcomings in this so it's not an announced or supported feature, but it's sufficient progress that it's worth writing about.

There's a few ways that Apple platforms differs from normal PC hardware. The first is that Apples are very much intended to be EFI first and BIOS second, while that's still not really true for commodity PC hardware. Apple launched Boot Camp shortly after they started shipping x86 Macs (and shortly after I'd got Ubuntu running on one for the first time[1]) but the focus of Boot Camp has always been to be good enough to boot Windows and not much else[2]. The other is the integration with the boot environment. You can boot Linux easily enough by setting the standard EFI boot variables, but if you ever boot back into OS X it's easy to trigger deletion of those. There's then no straightforward way of resetting them, and you're left having to recover your installation.

The other difficult bit has been actually starting the installer at all. If you're happy to use BIOS emulation than this can be done without too much misery, but you're then left with dealing with Apple's custom synchronised GPT/MBR. More modern Macs will boot via the standard EFI mechanisms, but there's a range of problems that can be caused that way. Fedora 17 is the first Linux distribution to ship install media that will EFI boot a Mac when either written to optical media or a USB stick[3]. Put the install media in your system and then either select it in the OS X Startup Disk preferences menu and reboot, or reboot and hold down the alt key. In the latter case there'll be a nice Fedora logo. Click on it and it'll boot.

The biggest difference between Apple hardware and anyone else is that we'd normally put the bootloader in a FAT partition that's shared with any other installed operating systems. That does actually work on Apples, but then you run into the earlier point I mentioned. The Apple startup picker that you get by holding down the alt key doesn't pay any attention to the standard EFI boot variables, so it won't show a FAT partition merely because it's got an EFI bootloader on it. The same is true of the OS X Startup Disk preferences. The best way to get a drive to appear in the menu is to make it look like an OS X drive.

This was problematic in a few ways, due to the requirement for an OS X drive to be HFS+. The first was that we didn't have any support for that in our installer, so work had to be done there. The second was that the state of HFS+ was woefully poor in Linux[4]. Linux will refuse to write to an HFS+ filesystem if it hasn't been cleanly unmounted or fscked, and since we can't rely on everyone always shutting their machine down cleanly that means a working fsck.hfsplus. In theory we were shipping one of those. In practice, it reliably segfaulted on 64-bit systems[5]. So I had to package the latest version of Apple's code, and doing that involved dealing with the fact that Apple now use blocks almost as much as Grub 2 uses nested functions, and that meant using Clang and that meant dealing with a bug where Clang segfaulted if it had been built with gcc 4.7[6], but finally once all of those yaks had been shaven we could trust our filesystem.

Of course, more problems existed. You can't just drop a bootloader onto an HFS+ partition and expect it to work. You need to write its inode value into the superblock. Trivial, except that if you do this from userspace then the kernel kindly overwrites your update when you unmount the disk and it updates the superblock. That required a mechanism for updating that data via the kernel, which meant adding an ioctl. This would have been fine, except the OS X Startup Disk preference looks for a bootloader in a location other than where Fedora installs it. Changing our bootloader install path wasn't a great option, so the easiest thing to do was just to link them together. Except HFS+ doesn't really support hardlinks. When you hardlink something the original file gets moved into a magic directory in the filesystem root and the links are special files that refer to it. And it turns out that it's not actually the inode that the firmware wants when finding the bootloader, it's the catalogue ID, and these aren't the same when hardlinks are involved. So, another kernel patch.

All that was left for the boot partition then was adding an icon and a drive label. We already had code for generating the icon, and the drive label wasn't that difficult. Hurrah!

Ok, so we can construct a filesystem that (a) appears in the bootpicker, and (b) appears in the OS X Startup Disk preferences. We can even put a bootloader on it. This led to the next problem. The bootloader started without any trouble. But the bootloader couldn't read any files off the boot partition, including its configuration. This should have been obvious with hindsight - the problem was simply that grub legacy[7] doesn't support HFS+. Writing an HFS+ driver seemed like an excessive amount of work, especially since the firmware already supported reading HFS+, so instead I wrote a simple grub filesystem driver that uses the UEFI interfaces to read files.

A working bootloader! One more problem there. grub looks in its startup directory to find its configuration file. We have two "copies" of grub hardlinked to each other, each looking in a different directory for configuration. Hardlinking the config files together worked fine, except that most tools that update config files have this irritating habit of writing to a temporary file and moving that over the original, thus breaking the hardlink. Easily solved by using a symlink instead, except that the UEFI filesystem semantics don't really support symlinks because UEFI only really envisaged using FAT. If you use Apple's UEFI HFS+ driver to open a symlink, you get a short file containing the target path of the symlink. Rather less than ideal, and a rather gross hack to cope with it.

All set now, other than a bug in some older Mac firmware where read would return BUFFER_TOO_SMALL without returning the real buffersize and the odd way that Apple treat CDs. Oh, and a bug in Apple's Broadcom wifi driver that could overwrite the kernel, and case-sensitivity, something that obviously isn't something you often hit on UEFI when all you usually see is FAT.

Kernel-side, we had a couple of things. Obviously there the bugs I'd mentioned in the past, but those had already been dealt with. New issues included the fact that we were frequently picking the wrong framebuffer address, especially on machines with multiple GPUs. Fixed now, along with another issue where we'd sometimes get confused by models with different GPU configurations. And at that point, most of the implementation work was done.

Of course, there was also the work of integrating this into the tools that we use to generate our install media, and I'd like to thank Will Woods, Brian Lane and Dennis Gilmore for the work they put into that, along with anyone I've forgotten. Tom Calloway handled getting the device label graphics generated right before deadline. A cast of thousands helped with testing.

So why did I mention shortcomings? First, this only works on machines with 64-bit firmware. Early 64-bit Apples still had 32-bit firmware. In theory we can support that case - in practice it's a moderate amount of writing, including some mildly awkward kernel code. But anything later than mid-2007 should have 64-bit firmware, so it's not a massive concern. Second, we seem to have fairly significant trouble with Radeon hardware on a lot of Macs. We fixed one bug there, but something's still going wrong in setup and you'll frequently end up with a black screen. And thirdly, I'm sure there's some other machines that still don't work for (as yet) undetermined reasons.

With luck we'll get these things dealt with by Fedora 18. But even with these flaws, Fedora 17 will work fine on a lot of Apple hardware, and testing it is as simple as downloading and booting a live image. Bugs go in the usual place.

[1] Note my charming belief that the Ubuntu installer would fully support this hardware via EFI in the near future. 6 years ago. It still doesn't.
[2] This can be fairly easily seen from little things like the name "Windows" being hardcoded into every UI that sees a Boot Camp drive.
[3] I cover this in more depth here
[4] To be fair, it mostly still is - there's plenty of work to be done there.
[5] Approximately nobody had noticed this, which is all kinds of unreassuring.
[6] Thanks to Kalev Lember for dealing with that
[7] Still the EFI bootloader in Fedora 17. We've already swapped Fedora 18 over to grub 2.


Date: 2012-05-25 04:22 am (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawmw6_G4qrXH7xTxEdgcoTO6ManqHg3xjyU
In EFI mode:

a) video support is dead as there is no AtomBIOS (leaving a completely unusable system at boot)
b) video switching has to be hacked in at boot time to switch to a working video card
c) when you do that, the gmux backlight doesn't work as the ACPI backlight is dead but still registered
d) suspend/resume leaves the wireless driver in a state which kills connectivity
e) suspend/resume doesn't restore the video switching mode and
e) shutdown hangs

[N.B this is all for my MacBook Pro 8,2]

And that's just the first few things I noted in EFI boot. Seems like there is still a _long_ way to go.

Re: And..

Date: 2012-05-25 10:57 pm (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawmw6_G4qrXH7xTxEdgcoTO6ManqHg3xjyU
No. But as I'm using a 3.4 kernel, and these are pretty much all kernel issues, I don't see how they could be fixed. Unless there are a lot of patches on top of mainline.

Re: And..

Date: 2012-05-26 11:43 am (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawmw6_G4qrXH7xTxEdgcoTO6ManqHg3xjyU
Probably the biggest issue (for me) is the radeon bios issue. How do you fix that? I don't see any patches in the 3.5 merge window for it:

$ git whatchanged v3.4..HEAD -- drivers/gpu/drm/radeon/radeon_bios.c

Re: And..

Date: 2012-05-28 12:03 am (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawmw6_G4qrXH7xTxEdgcoTO6ManqHg3xjyU
"Fedora 17 is the first Linux distribution to ship install media that will EFI boot a Mac when either written to optical media or a USB stick[3]. Put the install media in your system and then either select it in the OS X Startup Disk preferences menu and reboot, or reboot and hold down the alt key. In the latter case there'll be a nice Fedora logo. Click on it and it'll boot."

I was hoping to test these fixes, but the "alt key" option in the quote above don't work for me. From optical media, I just get "Windows" and it boots into bios compatibility mode. I'm using (sha256):

6a42814413c4e663fb9486e8436c4bdcd1426953f37612c56353afd486796c78 Fedora-17-Beta-x86_64-Live-Desktop.iso

Re: And..

Date: 2012-05-28 10:38 am (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawmw6_G4qrXH7xTxEdgcoTO6ManqHg3xjyU
I got it from here:


Re: And..

Date: 2012-05-29 03:32 pm (UTC)
From: (Anonymous)
I tried booting using the link you gave and it just goes black/blank screen on my MBP 8,2. Anybody get past this problem?

Re: And..

Date: 2012-06-01 12:30 am (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawmw6_G4qrXH7xTxEdgcoTO6ManqHg3xjyU
Right. I got the same. And as mentioned above the problem is that requiring but not loading an AtomBIOS for the kernel radeon gpu driver in EFI boot is _NOT_ fixed.

I haven't tried hacking grub to turn off the discrete graphics card and use the working intel gpu driver, but I'm assuming that will work. You'd need something like the following in grub:

outb 0x728 1
outb 0x710 2
outb 0x740 2
outb 0x750 0

This is assuming some of the intel drm patches which are proposed in 3.5 are in the distributed kernel. If not, then you're out of luck and need to boot in bios mode.

Re: And..

Date: 2012-05-29 04:24 am (UTC)
From: (Anonymous)
I dont understand the long discussion about Apple and Linux. I have been dual booting iMac with a variant of ubuntu using what is called rEFIt. Simply when I am installing Linux, i place the bootloader in the root partition , not in MBR. If you exercise that much caution after installing rEFIt, any Linux will do, I think.

I have also another problem in Linux ie I am not getting sound, which I believe has got nothing to do with booting process.

Re: And..

Date: 2012-06-01 10:12 am (UTC)
From: (Anonymous)
You're most likely booting it in BIOS compatibility mode. Yes it works, but with a whole lot of issues.
Only the ATI card is enabled in my case with a MBP8,2, which is terrible for battery life.

@mjg59: I can confirm that I get left at a black screen when booting into F17. As one of the other posters has noted, it's likely due to lack of vbios availability in EFI boot.

Re: And..

Date: 2012-05-29 04:53 am (UTC)
From: (Anonymous)
I think BIOS vs EFI booting is just noise.
(I find no problem booting either)
I see power, macs sleep, linux throttles, as a result that macs fry running any linux distro as MUCH more important. Yet this is not mentioned ever. Don't you folk care if your mac gets fried?

Re: And..

Date: 2012-06-26 07:14 pm (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawnL4UaW8L47qQSFTmLQLy_X5s98-qeaXY8
I take it you're talking about this?


I played with doing something similar in grub2, but it would never successfully write to the legacy VGA ROM range on the MBP 8,2. I think I determined that it was locked down using TXT, but I haven't yet found time to pursue it further.

Re: And..

Date: 2012-06-26 07:09 pm (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawnL4UaW8L47qQSFTmLQLy_X5s98-qeaXY8
The wireless problem after suspend/resume should be fixed by the following, not sure if it's been picked up by Fedora though.



Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags