On Aug 24, 2014, at 11:23 AM, Michael Catanzaro <mcatanzaro(a)gnome.org> 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