Fedora 19 and Apple hardware [LWN.net]

By Jonathan Corbet
July 3, 2013

The Fedora 19 release brings a lot of goodies for Fedora users, but there is one class of users that may be a bit less happy: those who want to run Fedora on an Apple Mac system in a dual-boot configuration with OS X. A late bug in the Anaconda installer makes the creation of such systems nearly impossible. One might wonder why Fedora 19 shipped with this kind of problem; a look at the reasons gives a few insights into how the Fedora release process works.

The decision to proceed with the Fedora 19 release was announced on June 27. Unfortunately, bug #979205 had been filed shortly before. The installer fails to create the needed partitions for a dual-boot system on an OS X machine, causing the installation to fail. As Matthew Garrett put it when calling attention to the problem: "This is rather frustrating, since Fedora's the only distribution with any significant support for running on Apple hardware." A glance at any Linux-related conference will show that Apple systems are popular among developers; it seems a bit strange that a distribution that has put significant effort into working on that hardware would ship with a known problem of this nature. The explanation for what happened involves a number of separate issues.

The first is that the bug was introduced very late in the development cycle; according to Adam Williamson, it went into Anaconda 19.30.10, which first saw wide testing in the RC1 release on June 25. Naturally, the patch that caused the problem was a response to another bug; even so, the patch was the subject of some discussion before being merged into the otherwise-frozen Anaconda source. In the end, the patch was deemed to be sufficiently low-risk to be accepted — a judgment which, like many, is easy to criticize after the fact. At the time, though, it looked like a way to fix a known problem in the release.

The new code took several days to find its way into a build that would see wider testing; it was committed on a Thursday, and the build did not happen until after the following weekend. That left a period of about two days between the bug's general availability and the Fedora 19 go/no-go decision — not very long for an installation-time issue to surface. Some participants have suggested that, in the future, the time between an RC release and the go/no-go decision should be lengthened to increase the chances of catching a last-minute problem. But that probably would not have helped in this case.

The fact that the Fedora quality-assurance team only appears to have a single Mac system, and that they don't test it for dual-boot installations, also did not help. There was a clear hole in the QA net that this problem slipped through. One might argue that this does not necessarily indicate a problem: as Chris Murphy pointed out, Macs are not officially supported by the distribution. So it is not surprising that the testing resources available are unable to catch every problem. It also means that, even if the problem had been found before the go/no-go decision, it would not have been entitled to "blocker" status and, thus, might not have affected that decision.

While not saying that the release should have been delayed to fix this problem, Matthew did question one interesting bit of Fedora policy: once the go/no-go decision has been made in the "go" direction, the process becomes unstoppable. That means that, even if this bug were deemed to have a "blocker" level of severity, it still would not have blocked the release. Kevin Fenzi defended this policy, describing the long series of events that starts to unfold once the decision to make the release has been made. The explanation was not satisfying to everybody, but the policy exists and doesn't appear to be subject to change.

So Fedora 19 simply will not install properly in a dual-boot OS X configuration without a lot of extra work. And things are likely to stay that way; an installer problem cannot be fixed through the normal Fedora update process. There was some talk of a 19.1 release, but, as Kevin put it, "We are currently pretty unsetup for any kind of point releases." So this problem is likely to remain in the official Fedora distribution until Fedora 20. Not an ideal outcome by any means, but one that may have been hard to avoid.

to post comments

Fedora 19 and Apple hardware

Posted Jul 4, 2013 7:09 UTC (Thu) by gdt (subscriber, #6284) [Link] (2 responses)

I have been waiting for so long for an EFI dual boot Linux install on Mac that the laptop is six months shy of being out of its three year warranty.

Fedora 19 and Apple hardware

Posted Jul 5, 2013 19:54 UTC (Fri) by AdamW (subscriber, #48457) [Link] (1 responses)

It worked fine in F17 and F18, so I'm not sure what you were waiting for. (Unless you happen to have Mac hardware that the kernel doesn't support so well, which is a separate issue).

Fedora 19 and Apple hardware

Posted Jul 6, 2013 0:31 UTC (Sat) by gdt (subscriber, #6284) [Link]

Both of those had issues such that people who wanted Fedora to "just work" on Mac hardware were asked to wait for the next release.

Fedora 19 and Apple hardware

Posted Jul 4, 2013 7:27 UTC (Thu) by danielpf (guest, #4723) [Link] (6 responses)

One should not forget that Fedory is some kind of beta release for RedHat and therefore one should not expect too much on the side of quality insurance.

Fedora 19 and Apple hardware

Posted Jul 4, 2013 9:13 UTC (Thu) by affix (guest, #91710) [Link] (5 responses)

Fedora is NOT just a beta release for RedHat Enterprise.

Fedora is the Platform sponsored by redhat as a community project. Fedora sets the pace for other linux distributions and tries to introduce the latest technologies.

It is true that redhat do use fedora as a way to gauge user reactions to new technologies but it is not true that there is no quality assurance.

If you have issues with the quality of fedora we would be delighted to have your comments just email the QA team or come to #fedora-qa on freenode.

Fedora 19 and Apple hardware

Posted Jul 4, 2013 10:16 UTC (Thu) by danielpf (guest, #4723) [Link] (2 responses)

I wrote "some kind of beta" and I didn't wrote there is no quality insurance, but that "one should not expect too much on the side of quality insurance".

I can tell this because since 1994 I use and have used many types of distributions, including RedHat, Fedora, Mandrake/Mandriva, Mageia, Debian, to name the principal ones, on hardware going from phones to clusters. Therefore I can compare rather well how the different distributions behave when used in practice.

I like Fedora for its bleeding edge character, excellent for testing the latest kernels and applications. However I know that using recent software necessarily, always, implies some surprises and eventual difficulties, despite the quality insurance efforts deployed by the developers. To me Fedora looks like a beta version of some better-tested other distributions, in the sense that often it works as expected but some details do not work and some secondary surprises remain.
It is important that users understand this otherwise they become frustrated.
The article about Fedora 19 and Apple hardware sounded a bit like the author was surprised of such a problem, to me the problem appears "normal". As I have no Apple hardware I will soon happily test Fedora 19 on a Thinkpad laptop.

Fedora 19 and Apple hardware

Posted Jul 5, 2013 20:07 UTC (Fri) by AdamW (subscriber, #48457) [Link] (1 responses)

I am not aware of any distro which supports, or tests the support for, UEFI Macs better than Fedora. Ubuntu certainly doesn't:

https://bugs.launchpad.net/elementaryos/+bug/1182933
https://help.ubuntu.com/community/ubuntuprecisequantalon2...
https://help.ubuntu.com/community/MactelSupportTeam/Apple...

So, who's the beta project again? :)

Fedora 19 and Apple hardware

Posted Jul 6, 2013 23:54 UTC (Sat) by danielpf (guest, #4723) [Link]

Do you evaluate a distro by just one feature among 1000's ?

I just installed Fedora 19 on my laptop and experienced that among many many nice aspects the localization went wrong, a typical weak point of Fedora and RedHat as experienced over the years. Also it insists to use the US keyboard by default. This is however not sufficient to characterized Fedora 19 as badly tested in general. I will form my opinion only after using it for several weeks. If the quirks show to be more numerous than in competing distros I will be able to tell which distro is better tested for my type of usage.

Fedora 19 and Apple hardware

Posted Jul 4, 2013 13:05 UTC (Thu) by jubal (subscriber, #67202) [Link] (1 responses)

No, Fedora is not a beta release for RHEL, Fedora is, obviously, a technology preview for RHEL.

Fedora 19 and Apple hardware

Posted Jul 4, 2013 14:45 UTC (Thu) by jamielinux (subscriber, #82303) [Link]

Or you could look at it in the other direction: Red Hat is a fork of Fedora :-)

After all, Fedora has a large community of non-Red Hat contributors, so it's really a distribution in it's own right.

Fedora 19 and Apple hardware

Posted Jul 4, 2013 8:41 UTC (Thu) by ovitters (guest, #27950) [Link] (6 responses)

"We are currently pretty unsetup for any kind of point releases."

Why not make an Apple Spin with the bugfix in it? I don't have knowledge about spins, but seems like a good enough workaround.

Fedora 19 and Apple hardware

Posted Jul 4, 2013 12:46 UTC (Thu) by salimma (subscriber, #34460) [Link] (5 responses)

Spins, AFAIR, are released on the same schedule. Fedora Unity used to produce re-spins, but it appears they're no longer actively doing so.

Secondary architectures do keep different release schedules, but I don't think Apple Mac quite qualifies for that...

Fedora 19 and Apple hardware

Posted Jul 4, 2013 16:37 UTC (Thu) by jzb (editor, #7867) [Link] (4 responses)

Is there any technical hurdle to doing so, or merely policy? If there's a sufficient audience for this, it would seem silly to let a policy issue prevent producing a "spin" that is effectively Fedora 19 + a bugfix for this issue. If it's a technical issue, then it might be worth examining just how big the hurdle is vs. how many users might be able to use Fedora if the issue is dealt with.

Fedora 19 and Apple hardware

Posted Jul 4, 2013 17:09 UTC (Thu) by nirik (subscriber, #71) [Link] (3 responses)

So, my 2 cents:

First, this bug isn't as large as scope as I think people are assuming. It's (some) Apple hardware where you are also keeping osx dual boot. (As far as I can tell)

There's currently at least one suggested workaround: Install from the Beta image (that didn't have this bug) and upgrade. There may be more ways to work around it, but it's still being explored in the bug before instructions are added to the common bugs page.

There's currently not a fix noted in the bug, but once we had one we could look at creating a fixed image(s) or whatever. We have done this for specific bugs in the past. These sorts of things usually live in the alt web space or fedorapeople.org are people are pointed to them from the common bugs page.

What we haven't done in the past are point releases. ie, 19.1. We could look at doing this down the road, but when I said we weren't setup for it I meant things like: Does this mean a 19.1 version in bugzilla? What does that do to all our tools? Can fedup upgrade to 19.1? or does it assume integers? Is this worth pulling all our QA and rel-eng folks off tooling work for fedora 20 to fix one isolated Apple hardware bug? Would this open the usual can of worms with "oh? you're making a 19.1. My cowsay bug is fixed in an update, it MUST go into 19.1 too!" Does yum handle fedora release being 19.1 instead of 19? Are mirrors ok with another release just after one happened? etc, etc. So, if there's really interest in this, I'd advise interested parties to propose how this would work on the devel list and get buy in. ;)

Fedora 19 and Apple hardware

Posted Jul 4, 2013 17:17 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

All Apple hardware.

Fedora 19 and Apple hardware

Posted Jul 4, 2013 18:14 UTC (Thu) by johannbg (guest, #65743) [Link]

FYI point release discussion belong more on the relevant parties mailinglists as in Releng/QA/Spins then they do on devel since there are the people that have to step up from or join these sub-communities to make that a reality.

Fedora 19 and Apple hardware

Posted Jul 5, 2013 20:10 UTC (Fri) by AdamW (subscriber, #48457) [Link]

Don't forget that we then probably have to make sure we're GPL and other license compliant for the point release too - i.e. carry a whole extra frozen tree, do another spin-kickstarts build...

basically the simple answer to zonker's question is that there's kind of a lot of annoying busywork involved in doing a distribution release, even a 'minor' point release, and we really don't have the resources to do more than we do already.

I could see us sucking down the pain to do a point release for something world ending, but this bug really wasn't it.

Fedora 19 and Apple hardware

Posted Jul 4, 2013 9:32 UTC (Thu) by johannbg (guest, #65743) [Link]

Fedora is a community driven distribution so there is no such things as something being "officially supported" like Chris Murphy states there in the distribution it's just one of many labels that someone within Red Hat as decided to walk around with stamp various things with within the distribution.

Those labels ( Official,Recommended,Supported,Default etc. ) have no meaning to the community.

As an community driven distribution the hardware we ( the distribution ) "support" is limited to what participant in the QA community have available or access to, to test the distribution on and report any bugs that they find.

Now that means even if "Fedora's the only distribution with any significant support for running on Apple hardware."

We a) dont have many Apple hardware owners running Fedora or b) those Apple hardware users aren't participating in the QA community.

So if you care about Fedora working well on any specific hardware device you simple have to show up and participate in the QA community, test and file any reports about any issues you find just like anyone else and bring those reports you consider serious enough to the QA community in whole attention either by a mail on the test list,or as an topic on either QA meetings or the blocker bug ones for discussion which we more often than not contact the relevant maintainer(s) for further assessment and insight on relevant bug.

The earlier you participate in the QA community and in the development cycle the more likely hood the bug will be fixed at release time but it does not guarantee it because our maintainers they themselves organize their workload based on the free time they have to address that bug,the seriousness of it and their in depth knowledge how widely deployed that hardware is or might be on Fedora. ( Which has for example been routinely the case for graphics cards and is the reason why some have better "support" than others ).

Fedora 19 and Apple hardware

Posted Jul 5, 2013 19:59 UTC (Fri) by AdamW (subscriber, #48457) [Link]

Thanks for the write-up, Jon, and for being more accurate than most news sources as usual, but I do think this article slightly overstates the severity of the problem. Admittedly, I really ought to have written up a commonbugs note by now.

So here is the concise summary:

The 'autopart' algorithm in F19 is not able to correctly re-use an existing HFS-formatted EFI system partition. It tries to do so, but then an error check erroneously decides that's not a valid layout, and you get an error.

If you don't mind blowing away the existing ESP (which will render OS X unbootable, so you may as well blow away OS X too) you can go ahead and use automatic partitioning just fine.

If you want to dual boot with OS X, you have to use custom partitioning, and don't use the 'create partitions for me' link but create your layout manually, including a second EFI system partition, formatted as FAT32 (and, of course, mounted at /boot/efi ). If you do this, the install will work fine.

If you don't have sufficient knowledge to do custom partitioning, you can use the 'install F18 or F19 Beta and then upgrade' dodge, which ought to work in most cases. Note that this will still give you two EFI system partitions.