On Sun, 2014-12-28 at 18:39 -0700, Chris Murphy wrote:

On Thu, Dec 4, 2014 at 12:41 AM, Adam Williamson < adamwill@fedoraproject.org> wrote:

...

Hi, folks. Talking to cmurf, our resident OS X dual boot expert, on #fedora-qa, it's become clear that when we adopted the OS X dual boot criterion a few weeks back, we didn't have a good understanding of the current state of that code and particularly upstream grub's support for booting OS X via UEFI. Basically it seems that booting OS X from grub didn't work then and doesn't work now and we can't realistically fix it, so we shouldn't have put that criterion in place because it's not something we can actually viably achieve.

cmurf, roshi, kparal and I voted +1 to removing the criterion on that basis. I'm hoping cmurf will be kind enough to look at the issue again for the F22 cycle, in consultation with pjones if necessary, so we can put a realistic requirement in place before we get into F22 Alphas.

If no-one has any objections, we'll make the removal formal ahead of tomorrow's Go/No-Go meeting for 21. Thanks folks!

Gist: EFI GRUB still gets these legacy OS X boot options that were designed to permit CSM-BIOS GRUB to EFI boot OS X. They don't work from EFI GRUB though.

As far as I can tell there's no upstream bandwidth/interest in fixing this; even if it means just suppressing the creation of the entries, rather than chainloading the Apple bootloader. So I think the issue is not a QA issue right now, but needs to be bounced back to desktop@ for the Workstation WG to maybe use some recruitment influence if they want to see this fixed. http://lists.gnu.org/archive/html/grub-devel/2014-10/msg00044.html

A challenge with grub2-mkconfig creating an entry to chainload Apple's boot.efi, is with recent on-disk format changes in OS X 10.10 since this last October. It means os-prober will need to become aware that the boot.efi it's looking for is now on an Apple Boot [1] partition. I'm not sure what's involved in doing that work compared to just suppressing the creation of entries that don't work anyway.

Thanks for the info, and sorry for the belated reply.

So, where would you say we are WRT the criteria for F22 right now? What would be a reasonable expectation?

As of right now, we have these in the F22 Final criteria:

Windows dual boot

The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora.

OS X dual boot

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; if the boot menu presents OS X entries, they must boot OS X. Installing Fedora must not inhibit the system's ability to boot OS X from the UEFI boot manager.

We do not have any Linux dual boot criterion.

Do we need to amend the OS X or Windows criteria to reflect technical reality in any way? Do we want to take another shot at adding a limited Linux dual/multi-boot criterion before we hit Alpha? If so we should revisit the F21-era proposals, agree on a wording, and run it by anaconda-devel-list ASAP.

Thanks!

On Tue, 2015-01-20 at 19:19 -0700, Chris Murphy wrote:

**NOTE**: as there's quite a bit of quoting and discussion here, I've put a tl;dr summary at the bottom of this mail which lists all the specific proposals at this time. Please skip down to it if you don't want to read all the discussion.

...

Windows dual boot

The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora.

On UEFI with Secure Boot enabled, the GRUB Windows menuentry fails. https://bugzilla.redhat.com/show_bug.cgi?id=1170245

This is working on openSUSE since ~2012 so it seems it ought to work on Fedora by now. The criteria neither requires nor exempts us from this behavior, so right now its ambiguous.

So pjones tells me he's willing in principle to use OpenSUSE's patch for this if he checks it out and finds no issues with it, but he can't guarantee that shim will be rebuilt during the F22 cycle (we try to build shim as rarely as possible as every time we do it, we have to go through the process of getting it signed by Microsoft).

On that basis we can't really require it to work for F22 at least, so I propose we add a footnote to this criterion:

"The bootloader entry part of this criterion does not apply when Secure Boot is enabled."

we can consider enforcing it for F23 or later.

...

OS X dual boot

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; if the boot menu presents OS X entries, they must boot OS X. Installing Fedora must not inhibit the system's ability to boot OS X from the UEFI boot manager.

I think this can safely be changed to just the first part before the semi-colon. It seems like removing the OS X boot entries from being created is a cosmetic change, it means grub2-mkconfig does less work. Niftier would be a reminder that rebooting with Option key will bring up the built-in boot manager from which OS X can be booted. I don't know if that's a feature change though, since it'd be nice if it's translated. But in any case it seems to me the criteria can be chopped to 1/3, basically just saying "Fedora ought to install to and boot a Mac, and that the installer expects free space to do that, i.e. no resizing."

I'm +1 to that because it sounds more or less sane and I pretty much trust your judgment when it comes to OS X boot stuff. Does anyone have any objections?

Some people on desktop@ agree there should be a Secure Boot criteria, at least for single boot (Fedora). Making this apply to chainloading (per above) met with less assurance, but this was before I tracked down that opensuse can do this. (Ubuntu fails with the same error we have.) If we have concensus here, then maybe this ought to go to the WG's. I suspect all three products want Secure Boot to work for their products, or block. Workstation is the only one that cares about SB and dual-boot.

So we do express in the Alpha criteria:

"All release-blocking images must boot in their supported configurations."

"Supported firmware types [hide]

Release-blocking images must boot from all system firmware types that are commonly found on the primary architectures."

I'd argue that to cover Secure Boot already, since it seems reasonable to consider UEFI with SB enabled as a 'commonly found' 'firmware type'. But I agree it's not 100% crystal clear, so we could amend that to simply explicitly state it:

"For the x86_64 architecture, UEFI with Secure Boot configured in accordance with Microsoft's Windows certification requirements is considered a 'commonly found' firmware type."

How does that sound? (Note for any conspiracy theorists: there is nothing evil here, we're just expressing 'we want to make sure we boot on the PCs people buy in the real world', it is what the software already does).

As for dual boot linux, it'd be great if things were friendlier. Sadly it doesn't appear to be a priority. Bootloaderspec has an upstream and mjg59 variant, presently the GRUB bls module sufficiently departs from both to be on its own set of rails, and I'm not aware of any collective distro effort to settle this. It seems like a pretty small collection of dual boot linux users and if we play the numbers game it seems like not a whole heck of a lot really care. Therefore I don't know it makes sense to put effort into this on the QA side as if we can compel what amounts to a feature to just materialize from a criterion.

That seems reasonable; 'don't change anything' is always the 'safest' choice, I guess, so we should require definite data ('lots of people want it and the devs are reasonably confident they can commit to supporting it') to support *adding* such a criterion. Is anyone really sad if we don't add one for F22, and would like to propose wording?

So for a tl;dr summary, the active proposals are:

1) Add this footnote to the Windows dual-boot criterion: "The bootloader entry part of this criterion does not apply when Secure Boot is enabled."

2) Reduce the OS X criterion to "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."

3) Add a footnote to the Alpha 'Release-blocking images must boot' criterion: "For the x86_64 architecture, UEFI with Secure Boot configured in accordance with Microsoft's Windows certification requirements is considered a 'commonly found' firmware type."

If anyone has comments on those proposals or really wants to propose a Linux dual/multi-boot criterion, please go ahead and speak up :)