[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..

From: (Anonymous) - Date: 2012-05-29 03:32 pm (UTC) - Expand

Re: And..

From: (Anonymous) - Date: 2012-05-29 04:24 am (UTC) - Expand

Re: And..

From: (Anonymous) - Date: 2012-06-01 10:12 am (UTC) - Expand

Re: And..

From: (Anonymous) - Date: 2012-05-29 04:53 am (UTC) - Expand

Both kernel patches link to the same place

Date: 2012-05-25 04:28 am (UTC)
From: (Anonymous)
"adding an ioctl" and "another kernel patch" both lead to the same place.


Date: 2012-05-25 05:00 am (UTC)
From: (Anonymous)
Note that if using Filevault on OSX 10.7, things are different. AIUI, the FAT partition is then used for boot.


Date: 2012-05-25 09:38 am (UTC)
From: (Anonymous)
Why do you bother with such obviously broken proprietary hardware at all? PS: Posting with a Launchpad OpenID is broken.

Re: Why?

From: (Anonymous) - Date: 2012-05-25 12:25 pm (UTC) - Expand


Date: 2012-05-25 12:06 pm (UTC)
From: (Anonymous)
Big thank you to you and everyone else who has worked on this!

Re: Sweet!

Date: 2012-05-25 01:35 pm (UTC)
From: (Anonymous)
Seconded, and thanks for the write-up. (jmtd)


Date: 2012-05-25 08:38 pm (UTC)
From: (Anonymous)
Thanks for the hard work. I'm sure many people will be happy, after all Apple makes great computer hardware. =)

Fedora 17 RC4 on MacBookPro 5,5 freezes

Date: 2012-05-26 12:07 pm (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawkQvZi-u-QQPWlASR6yfoPMEukpMSx8MA4

i'm very happy that efi usb stick boot is now possible. great work.

but at the moment the live session created with "https://fedoraproject.org/wiki/Livecd-iso-to-disk" is freezing after 1-5 minutes. i can't determine the source of this. i tried booting with noapic and/or acpi=off with no effect.

the suspicious thing is that the mouse/touchpad stills moves.

i'm looking forward using fedora 17 on my mbp.

i hope this issue can be solved soon.

fedora 17 rc4 gold x64
macbookpro 13 5,5
128gb ssd
8gb ram

Re: Fedora 17 RC4 on MacBookPro 5,5 freezes

Date: 2012-06-15 02:47 pm (UTC)
From: (Anonymous)
the same is happening to me with the official release of fc17.

I'd like to use it on my macbook :-(

Re: Fedora 17 RC4 on MacBookPro 5,5 freezes

From: (Anonymous) - Date: 2012-07-30 12:10 pm (UTC) - Expand

Date: 2012-05-26 06:05 pm (UTC)
From: [personal profile] vaurora
Thanks for the hard work! Even if you did mock me for running Linux on a Macbook Air a year or two ago. :)

Does this apply to the liveCD spin too?

Date: 2012-05-27 11:30 am (UTC)
From: (Anonymous)
Can those images be dd'd to a USB stick and work?

I've just tried a nightly (20120525.09) desktop spin

From: (Anonymous) - Date: 2012-05-28 09:54 am (UTC) - Expand

In Fedora 17 final desktop spin too

From: (Anonymous) - Date: 2012-05-29 06:55 pm (UTC) - Expand


From: (Anonymous) - Date: 2012-05-29 08:14 pm (UTC) - Expand

Google's Chromebooks are even worse

Date: 2012-05-27 01:57 pm (UTC)
From: (Anonymous)
Have you tried to get Fedora to install on a Chromebook? Google makes it like 4 times harder than Macs, but they don't get any slack for it. Why??

Re: Google's Chromebooks are even worse

Date: 2012-05-27 09:23 pm (UTC)
From: (Anonymous)
Do you mean flak?

Re: Google's Chromebooks are even worse

From: (Anonymous) - Date: 2012-05-28 04:27 am (UTC) - Expand


Date: 2012-05-28 12:17 am (UTC)
From: (Anonymous)
Will all of these enhancements make it upstream so that other distros can benefit from your incredible work?

Keep up the great work!

Date: 2012-05-28 03:06 am (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawkm46lig1pr_aVZUIqZolJxB6ixN7Qz3KQ
All of this is the exact reason that I have been continuing to "triple" boot my macbook pro. First I have the standard OS X install, second I have a copy of windows 7 that has been booted a grand total of one time, and third I have an Wubi install that allows Ubuntu to live in the EFI's pretend BIOS land none the wiser. It's ugly, but at least it works 100% of the time with limited effort on my part. However, I have always longed to get rid of this stupid windows partition and instead run only OS X and Fedora side-by-side without having to resort to all sorts of terrifying EFI black magic or the increasingly divergent Ubuntu. Thank you for putting in the work to make this all so much easier!

Radeon kernel driver power management bugs

Date: 2012-05-28 08:15 am (UTC)
From: (Anonymous)
Quote: "Second, we seem to have fairly significant trouble with Radeon hardware on a lot of Macs."

Also the radeon opensource driver in Linux kernel is quite broken regarding power management. On multiple non-Apple laptops the default radeon driver power_profile "default" makes the laptop overheat and do an emergency thermal shutdown. The "workaround" is to switch to using power_profile "low", but sometimes the machine will crash due to overheating before you even get to userspace to change that power_profile!

Upstream freedesktop.org bug about the broken radeon power management:

Fedora bugzilla entries about the broken radeon power management:

RHEL6 bugzilla about the broken radeon power management:

Date: 2012-05-28 07:01 pm (UTC)
From: (Anonymous)
Is there any linux distro that can:

a) boot from UEFI
b) install to GPT disk without messing up Windows 7
c) boot from GPT disk using UEFI

Public wants to know.
From: [identity profile] http://www.skierpage.com/openid/
What a story! Infocom should turn it into a text adventure game for Fedora 18 ;-) Grub2 can run simple .ZIL (Zork Interactive Language) files...

nouveau/EFI conflict

Date: 2012-05-29 08:16 pm (UTC)
From: (Anonymous)
On a MacBookPro the nouveau driver seems to be conflicting with the EFI VGA driver causing the boot to halt shortly after the kernel says it is removing the generic driver...

sad ending (known bug)

Date: 2012-05-29 08:35 pm (UTC)
From: (Anonymous)

Looks like there's no clean fix for EFI booters with NVIDIA only hardware. Help?

Re: sad ending (known bug)

From: (Anonymous) - Date: 2012-06-08 02:56 pm (UTC) - Expand

Fedora 17 on Macbook Pro

Date: 2012-05-31 10:00 pm (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawl1Nvg1FZRZOOq1gmODzwXcAd1cSQkt_tc
Just did a complete install of Fedora 17 on my Macbook Pro via USB flash drive I created using sudo dd if=Fedora-17-x86_64-Live-Desktop.iso of=/dev/disk3. In my case, I used rEFInd found at http://www.rodsbooks.com/refind/ as my boot loader. Worked great!

Thanks Matthew!

Date: 2012-06-02 09:16 pm (UTC)
From: (Anonymous)
I'm glad to see that someone actually knows how this works, also really glad you are writing about this. Was trying to figure out how to get Arch Linux to natively boot on Macs, like you've done with Fedora, but there wasn't much to find on Google..

Working on a 2009 Mac Mini

Date: 2012-06-08 08:15 am (UTC)
From: (Anonymous)
Just wiped everything OSX off the machine, ran the live CD, told Fedora to grab the whole disk and installed. It just works, other than the annoying 30 second wait.

Date: 2012-06-13 01:19 am (UTC)
From: (Anonymous)
i don't know what he talking about when he says that you can't put the bootloader on a regular fat partition. i just compiled grub_efi and put it in /efi/boot and it works just fine. btw, i tried fedora 17 on efi. pretty freaking sweet.


Date: 2012-06-16 08:59 am (UTC)
From: (Anonymous)
that's really a wonderful notice, i'll give it a try, thanks a lot

New MacBook Pro failiure

Date: 2012-07-06 10:44 am (UTC)
From: (Anonymous)
When I tried this out using Fedora 17 on a 13-inch, Mid 2012 Macbook Pro (MacBookPro9,2) I found the kernel wouldn't start (no messages or screen swap after grub). An Ubuntu 12.04 image on the same machine started but had no keyboard or trackpad...

Solution - noapic

Date: 2012-07-22 01:23 pm (UTC)
From: (Anonymous)
On the same machine when booting from a CD the kerel panics and prints the message:
kernel panic - not syncing : timer doesn't work through interrupt - remapped IO - APIC
but booting with the noapic option solved the issue on USB and CD.

Any luck with MacBookPro10,1?

Date: 2012-08-10 02:08 pm (UTC)
From: (Anonymous)
On a mid-2012 MacBook Pro (MacBookPro10,1), when I try the Fedora 17 Live CD (http://mirrors.servercentral.net/fedora/releases/17/Live/x86_64/Fedora-17-x86_64-Live-Desktop.iso) in an attached USB optical drive (Apple Superdrive), I get the grub screen, which says

"Booting Fedora-17-x86_64-Live-Desktop.is in xxx seconds...".

When the countown ends, it either hangs forever or times out after a while and boots OS X. Whether or not it times out seems to be random.

The same happens with the minimal boot efiboot.img from the full distribution's images directory, dd'ed to a USB drive.

Has anyone had any luck with MacBookPro10,1? If so, is there any special trick, boot parameter, etc. that needs to be used?


Re: Any luck with MacBookPro10,1?

From: (Anonymous) - Date: 2012-08-12 12:19 am (UTC) - Expand

Re: Any luck with MacBookPro10,1?

From: (Anonymous) - Date: 2012-08-12 04:20 am (UTC) - Expand

Re: Any luck with MacBookPro10,1?

From: [identity profile] joshuabrown.myopenid.com - Date: 2012-10-17 04:47 am (UTC) - Expand

Possible Fix

Date: 2012-11-08 06:37 am (UTC)
From: (Anonymous)
Developer's, download OCZ Bootable Tools for Mac.


They finally got firmware update working for OS X customers. It's Custom Live Disk which restores FAT32.dmg to FAT32(MBR) FlashDrive. It boots USB with out issue on all 3 of my Mac's (2010 MacPro, 2011 Early MacBookPro, & 2011 Mid-MacMini)

Re: Possible Fix

Date: 2012-11-08 06:56 am (UTC)
From: (Anonymous)
My post was cut off… Here rest of it.

Developers, it might be worth taking look at for future updates for Mac user's.

Here look at grub.cfg, not sure if it will help user still having issue.

loadfont unicode
insmod part_apple
insmod part_bsd
insmod part_gpt
insmod part_msdos
insmod search
insmod all_video
insmod gfxterm
#insmod gfxmenu

set gfxmode=640x480x32
set gfxpayload=1024x768x32
terminal_output gfxterm
insmod fixvideo

#Timeout for menu
set default=0
set timeout=5

#search --no-floppy --fs-LABEL --set=root LINUX

#FrameBuffer Menu Entry
menuentry " EFI Desktop Mode with kernel mode Touchpad driver " {
linux /boot/linux64/vmlinuz64 loglevel=3 tce=LABEL=LINUX vga=792 waitusb=12 noswap tz=GMT psmouse.proto=imps blacklist=bcma blacklist=ssb blacklist=b43
initrd /boot/linux64/core64.gz

#FrameBuffer Menu Entry
menuentry " EFI nomodeset (video recovery) " {
linux /boot/linux64/vmlinuz64 loglevel=3 nomodeset tce=LABEL=LINUX vga=792 waitusb=12 noswap tz=GMT psmouse.proto=imps blacklist=bcma blacklist=ssb blacklist=b43
initrd /boot/linux64/core64.gz

#Text Mode Menu Entry
menuentry " EFI Text Mode (minimal noapic) " {
linux /boot/linux64/vmlinuz64 loglevel=3 tce=LABEL=LINUX vga=792 waitusb=12 noswap text tz=GMT noapic nolapic
initrd /boot/linux64/core64.gz