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