Distributions

Fedora on Macs, or the lack thereof

The Fedora 25 release is close, but it wouldn't be Fedora without a schedule slip or two. So it was arguably unsurprising when the November 10 "Go/No-Go meeting" concluded that this release wasn't quite ready and the release date needed to be pushed back to November 22. The reason for the delay raised some eyebrows, though, and has led to questions about what the core release criteria for Fedora should be.

The problem that blocked the release, in short, is that dual-boot installations on some macOS systems fail. The root cause would appear to be in Fedora's "blivet" module, which is charged with management of the storage configuration as part of the system installation. Blivet gets confused about the nature of the partitions on the disk, causing it to try to reuse a partition that it should, due to the fact that said partition holds the macOS installation, not be touching at all. That attempt simply fails, leading to a broken Fedora installation. This result is unfortunate, but disappointed Apple users should take consolation in the fact that it could have been worse: the potential for wrecking the macOS installation was there if things had gone a little differently.

The problem, it seems, is reasonably well understood, and it is highly likely to be fixed by the next time the Fedora project gets around to deciding whether Fedora 25 is ready. But the decision to block the release raised some questions: should problems on Apple hardware be sufficient to block Fedora releases, and why did this problem only come to the fore at the end of the release cycle?

The Fedora community maintains a set of criteria for each release specifying the things that must be working for the distribution to be considered ready. A bug that violates one of the criteria is thus sufficient to block a final Fedora release. With regard to coexistence with macOS, the relevant criterion reads simply: "The installer must be able to install into free space alongside an existing OS X installation, install and configure a bootloader that will boot Fedora." Since the installer proved itself unable to do that, the distribution as a whole failed to meet this criterion.

The "Go/No-Go" meeting would normally be expected to delay a release when the criteria aren't met, but it does evidently have another option: modify the criteria to alter or remove the failing item(s). The meeting log shows that this option was considered, but ultimately rejected. A working macOS install is a part of the criteria for now, but it's not at all clear that things will stay that way.

Those who would like to change the criteria are working from one core observation: the macOS installation had been broken for some time, but nobody reported the issue until the day of the meeting. That suggests that nobody was testing the release on Apple hardware. As Josh Boyer put it:

If Fedora users do not actually care about dual-boot installations with macOS, the reasoning goes, there is little point in putting effort into supporting that configuration, and little justification for delaying the release (most users of which don't have Apple hardware) for this issue. But the discussion made clear that there are at least a few interested users. So it's not clear how the project should proceed.

Some users clearly think that the core Fedora developers themselves should be testing installations on Apple hardware. There are a few obstacles to that, starting with the fact that the Fedora QA team at Red Hat has an Apple hardware inventory that starts and stops at "one old Mac Mini"; this revelation led Michael Catanzaro to ask: "You work for a multibillion dollar corporation where the QA team cannot afford to buy a laptop?"

Said corporation could probably be coaxed or embarrassed into buying such a machine, though Apple support is probably fairly low on its own set of priorities. That said, it seems that no such hardware was bought after the last Apple-related Fedora failure, which also had a lack of testing hardware as one of its causes. But, even with shiny new hardware, there would still be the matter of the time it takes to actually do the testing and use the result; Fedora, like much of the free-software community, depends on its users for the bulk of that testing.

The situation is worsened in this case because owners of the relevant hardware may well be relatively unwilling to subject it to testing that could destroy the contents of the system. Apple's licensing also make testing in virtual machines impossible in the absence of Apple hardware. So this particular configuration may always be under-tested relative to others. Apple's lack of interest (to put it gently) in encouraging Linux on its hardware also doesn't help.

As a result, the Fedora project is having to consider whether it can realistically support Apple hardware going forward. And things might not stop there; Adam Williamson has let it be known that he will be looking at other release criteria as well:

Development projects rarely want to remove useful features from the list of things they support, for obvious reasons. In this case, some Fedora developers, at least, feel that Apple hardware support is an important way to bring in new users. But a failed installation is a certain way to put off potential new users, so, if Fedora wants to support this hardware, then some people, somewhere, are going to have to step up and help to test it. Free-software communities cannot be successful without broad testing; Fedora is no different from any other in that regard.

Comments (17 posted)

Distribution quotes of the week

— Stephen J Smoogen

— Guillem Jover (Thanks to Paul Wise)

— Stephen J Smoogen again

Comments (none posted)

openSUSE Leap 42.2

The openSUSE Project has announced the release of openSUSE Leap 42.2. "Leap is made to give stability-minded users and conservative technology adopters peace of mind. openSUSE Leap 42.2 is powered by the Linux 4.4 Long-Term-Support (LTS) kernel and is a secure, stable and reliable server operating system for deploying IT services in physical, virtual or cloud environments." See the features page for details.

Comments (none posted)

Oracle Linux 7.3 Available Now

The Oracle Linux and Virtualization Team has announced the general availability of Oracle Linux 7 Update 3. "This is the first Oracle Linux 7 ISO to include UEK Release 4 (UEK R4). Please note that new installations of Oracle Linux 7 Update 3 will install and boot the UEK R4 kernel by default. However, updates to existing Oracle Linux 7 environments require the user to explicitly install UEK R4 and will not automatically replace existing UEK R3 kernels."

Comments (none posted)

Discontinuing Software Collections for Scientific Linux

Scientific Linux will be discontinuing the Software Collections. The existing RPMs will be archived. Packages that were available in Software Collections are now available at SoftwareCollections.org.

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 687 (November 14)
• Linux Mint Monthly News (November)
• Lunar Linux weekly news (November 11)
• openSUSE news (November 10)
• openSUSE Tumbleweed – Review of the Week (November 11)
• Tails report (October)
• Ubuntu Weekly Newsletter, Issue 487 (November 13)

Comments (none posted)

Fedora 25 to have MP3 playback

Christian Schaller writes that, after all these years, a stock Fedora system will be able to play MP3 files. "I know this has been a big wishlist item for a long time for a lot of people so I am really happy that we are finally in a position to fulfill that wish. You should be able to download the mp3 plugin on day 1 through GNOME Software or through the missing codec installer in various GStreamer applications. For Fedora Workstation 26 I would not be surprised if we decide to ship it on the install media."

Comments (52 posted)