OS X dual boot criterion problems

[Adam Williamson]

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 :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net