On Aug 24, 2014, at 11:23 AM, Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: > We think these issues need to be treated very seriously, > since we do not expect Workstation users to be able to recover an > operating system when it is missing from the boot menu. [snip] > Fedora will not become widely popular if it remains dangerous to install. At least it doesn't seem more dangerous than any other distribution, but I agree being trustworthy in this area makes it more likely people will install it. > > Windows > ======= > > Our current release criterion is: > > "The installer must be able to install into free space alongside an > existing clean Windows installation and, when performing a BIOS (not > UEFI) installation, install a bootloader which can boot into both > Windows and Fedora." > > I propose the language be amended to the following: > > "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." > > Rationale: many modern Windows systems no longer have a boot menu that > is accessible before the system boots. If Fedora Workstation were > installed on such a system, the user would not be able to recover > Windows. > > Open bugs that would be covered by this criterion: > > https://bugzilla.redhat.com/show_bug.cgi?id=986731 > https://bugzilla.redhat.com/show_bug.cgi?id=1010704 The above two I think are Ok being covered by a final release criterion. This new one I think ought to be covered by an existing, or new, beta criterion: Windows NTFS volume corrupted beyond repair during installation https://bugzilla.redhat.com/show_bug.cgi?id=1120964 This one is mostly a question if ntfsresize is doing the right thing, whether the user really needs to do something manually: After ntfsresize is used, Windows 8.1 chkdsk doesn't clear the dirty bit https://bugzilla.redhat.com/show_bug.cgi?id=1134142 Because of the above bugs, the risks, the unknowns, the fact anaconda devs and QA know the risks and consider resizing a "best effort" case, but users don't know any of these things; this is set for Rawhide not F21: Rawhide RFE: Dual-boot Windows installation should convey resize risk, encourage Windows based resizing https://bugzilla.redhat.com/show_bug.cgi?id=1134102 > > OS X > ==== > > We currently do not have any release criterion that applies to dual > booting with OS X. Since our Mac support is very poor and has no > prospect of near term improvement -- in particular, we have concerns > that running Fedora on a Mac has caused at least one Mac to overheat and > die -- the consensus seems to be that dual booting with OS X should not > be a requirement. However, it's also not OK to destroy the user's OS X > without warning. I propose the following final release criterion: > > "The installer must be able to install into free space alongside an > existing clean OS X installation and install a bootloader which can boot > into both OS X and Fedora, OR the installer must prominently warn the > user that he may be unable to boot OS X after installation, allowing the > user to cancel installation and reboot to OS X." > > I think that requirement should be easy to meet, so I won't include > links to the OS X bugs. tl;dr My suggestion for F21 is to suppress creating the broken OS X GRUB menu entries, and document the option-key boot manager way of getting back to OS X. And hopefully for F22 we get a GRUB menu entry for OS X that work. For those who want the details (the list size/verbosity makes it seem like it's worse than it really is): a. Upstream GRUB2 xnu bootloader modules don't support signature checking, therefore can't be included in the prebaked grubx64.efi Fedora ship signed for Secure Boot. The xnu modules also can't boot encrypted OS X installs, or new unencrypted installs starting in about a month [1] so I think it's a dead end. b. The workaround mjg59 and I prefer is chainloading the OS X bootloader, because this solves all of the above issues. Chainloading the OS X bootloader used to work, but it's not anymore. So I need to do some regression testing. c. Getting grub2-mkconfig to create chainloader entries instead of xnu entries may be non-trivial. I'm not sure. Ergo this is probably an F22 time frame thing anyway. But maybe a simple patch is possible that would suppress the creation of the current entries which definitely don't ever work. d. The installer only needs to inform the user how to get the built-in firmware's boot manager activated: option-key at startup chime. Now they can choose OS X. Easy. I don't think they need a warning with an opt out. e. Is it realistic to add (and translate) this info dialog in the F21 time frame? And also it may be obviated by the F22 time frame anyway if we get the preferred chainloading option to work. f. There's a lack of dire user complaint and confusion how to boot OS X in dual-boot scenarios. So yeah, we need to do better on Macs, or just drop supporting them at all even a little bit (clear line in the sand). If we're going to give support a shot, I'd still take baby steps, rather than consume resources and maybe add delays just for F21, that might get unwound for F22 if we find a better way forward by then. > > Linux > ===== > > We currently do not have any release criterion that applies to dual > booting with other Linux systems. Dual booting with other Linux systems > is NOT a requirement in the Workstation technical specification, but the > consensus seems to be that it should have been. Therefore I propose the > following criterion: > > "The installer must be able to install into free space alongside > existing GNU/Linux installations and install a bootloader which can boot > into the previously-installed systems and Fedora." > > I have no doubt that you will need to tweak the wording here, but the > intent should be clear. If such a broad requirement isn't technically > feasible, then let's discuss what would be. > > We want the criterion to cover these bugs: > > https://bugzilla.redhat.com/show_bug.cgi?id=825236 > https://bugzilla.redhat.com/show_bug.cgi?id=964828 Criterion language should make clear we're responsible for providing a proper environment [2] for os-prober and grub2-mkconfig to do what they're designed to do; including responsibility for our own GRUB2 patches. The above two bugs fit into these two categories. What we're not responsible for, are upstream GRUB2 deficiencies in its capability (OK we do sign up for this for things like Secure Boot and BLS, but we shouldn't make it a criterion, IMO.) [1] Apple appears likely to use their equivalent of LVM by default, which right now nothing on Linux, including GRUB, understands. So xnu can't find and load xnu anyway. [2] dm-crypt volumes unlocked, LVM and md raid devices active/assembled, filesystems in kernel/initramfs: ext234, btrfs, xfs, fat, ntfs, possibly reiserfs (?). Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
