Proposing new dual booting release criteria

[Chris Murphy]

On Sep 8, 2014, at 5:29 PM, Adam Williamson <adamwill at fedoraproject.org> wrote:

> On Mon, 2014-09-08 at 12:05 -0600, Chris Murphy wrote:
>> Also, any bug that "hinders execution of required Beta test plans or
>> dramatically reduces test coverage" can block release. An example bug
>> I think qualifies:
>> 
>> "Windows NTFS volume corrupted beyond repair during installation"
>> https://bugzilla.redhat.com/show_bug.cgi?id=1120964 
> 
> There is also the data corruption criterion,
> https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Data_corruption :
> 
> "All known bugs that can cause corruption of user data must be fixed or
> documented at Common F21 bugs."

> 
> which can obviously be used to cover issues that cause active damage to
> other-OS data.

Sure. But I'm looking to get this particular type of bug to block beta: fix it or disable NTFS resize. Could just yank ntfs-3g from lorax, haha. (Yes I realize it's not an ntfs-3g bug, but removing that package means the installer would face plant rather than data loss happening.) I hit this bug most attempts.



> 
>> 
>> 
>> Dual boot OS X + Fedora
>>>> 
>>>> "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 this potentially puts too much work on the installer and test
>> teams for Fedora 21, for minimal benefit. For example with encrypted
>> OS X installs, the above binds us to detect this, and then UI to warn
>> the user. 
> 
> It depends to an extent on the definition of 'clean', of course. Does
> enabling encryption count as a 'clean' install of OS X? Is encryption
> the default for OS X?

I think we need to avoid the idea of detecting and distinguishing what is a clean install of OS X.

Encryption is not the default, today. For one it's just an example, two it's a post-install live conversion so it's really easy to do. Certainly many users with laptops use it. Another example is the option to buy Macs preconfigured with the OS X equivalent of LVM dmcache. Right now nothing on linux recognizes or seed inside these "CoreStorage" volumes whether or not they're encrypted. And it's reportedly going to be the default layout for the next version of OS X due this fall.




> 
>> At the most, for Fedora 21, I'd say the installer could detect if it's
>> Apple hardware, and refer the user to this URL no matter their current
>> disk layout: http://support.apple.com/kb/HT1310 which shows them how
>> to boot OS X. Perhaps this could be put in release notes, or common
>> bugs, or the install guide instead?

By the way, to boot Fedora from dd'd USB stick, the user likely knows about the option-key boot chime trick to get the startup manager already.

>> 
>> Suggest the following.
>> 
>> {
>> 
>> 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; and if offered, also boot OS X.
>> 
>> }
>> 
>> - This means non-working OS X entries [1] need to be removed somehow
>> [2].
>> - It allows a future fix that includes an OS X boot entry.
>> 
>> [1]
>> https://bugzilla.redhat.com/show_bug.cgi?id=893179
>> https://bugzilla.redhat.com/show_bug.cgi?id=982847
>> 
>> [2]
>> Option a: We already detect Macs as part of mactel-boot support; so if
>> it's a Mac, then /etc/default/grub should contain a line:
>> GRUB_DISABLE_OS_PROBER=true
>> A consequence of this is any Mac with an existing Linux would not get
>> boot entries for that Linux instance; violating the Linux + Fedora
>> criteria if there's also no OS X on the system. But a Mac without OS
>> X? Rare.
>> 
>> Option b: Patch /etc/grub.d/30_os-prober deleting just the OS X
>> entries creation.
> 
> This approach does seem workable for Macs, as unlike PCs, we can rely on
> and document the firmware's behaviour to a reasonable extent (we don't
> know if they'll change it in future, but you know, that's a risk you
> often run). "Make it work or don't do it" seems like a reasonable
> standard.

Right. The firmware startup manager has been there a very long time along with its current UI, for something like a decade. Certainly things could change should they one day support UEFI Secure Boot, or whim.

I'll float the two options on anaconda-devel@ to see which one they might prefer.

Chris Murphy