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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
