QA wants a release criterion for dual boot OS X + Fedora installations. I floated this one on test@, and it's passed initial acceptance by Adam Williamson and Michael Catanzaro.
{ 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 an OS X entry, it should boot OS X. }
The gist is that if there are OS X boot entries they should work. This email proposes two ways to make them go away, and relies mainly on the firmware's built-in boot manager [1] instead to switch between OS's. I suspect a minority aren't familiar with this interface, and many others drop GRUB2 post-install in favor of rEFInd or gummiboot. The explanation for why the underlying problem with the broken entries won't be fixed anytime soon is at the end, because it's too long and you probably don't want to read it. [2]
Option A, patch Anaconda: If platform.MacEFI, anaconda writes out /etc/default/grub to include: GRUB_DISABLE_OS_PROBER=true
Consequence: Non-Fedora boot entries won't be created. This includes OS X, pre-existing Linux distros, and Windows. Due to other bugs and limitations it's virtually certain those entries wouldn't work anyway. The alternatives to the broken entries are already primarily in use due to necessity.
Option B, patch GRUB: Modify util/grub.d/30_os-prober.in to remove (or comment out) lines 44-106. This means grub2-mkconfig simply won't create OS X entries, but will still create other OS entries.
Is there a preference for one of these options, or is there an option c. ? My opinion is to go with option A. It's the simplest patch, it's upstream and downstream tested and supported, it's more discoverable than option B, and it's the only one users can revert post-install.
Chris Murphy
[1] http://support.apple.com/kb/HT1310
[2] GRUB uses its own xnu bootloader, instead of chainloading Apple's bootloader. This xnu module doesn't support signature verification needed for Secure Boot support, so it's not included in the prebaked grubx64.efi installed on the EFI System partition. And therefore OS X boot entries in grub.cfg always fail to work on Fedora.
There's another bump in the road, even if that were fixed or worked around.
GRUB lacks support for OS X's logical volume management, called Core Storage. It's used to implement full disk encryption, and a SSD+HDD "dmcache-like" arrangement; and the next version OS X due for imminent release is purportedly going to use Core Storage by default.
Since GRUB and os-prober don't recognize this format, the xnu module isn't going to be able to find, load or boot the OS X kernel. Moving toward chainloading Apple's bootloader is being explored, but isn't happening in the F21 time frame.
On 2014-09-09 09:51 UTC-0600, Chris Murphy wrote:
QA wants a release criterion for dual boot OS X + Fedora installations.
If this is going to be done, it should have a grammatically unambigous name/title, and use grammatically unambigous language:
1-Multi-boot/multiboot is always grammatically correct if a system has more than one independent operating system installation
2-Dual-boot/dual boot is never grammatically correct if a system has more than two independent operating system installations
3-Dual-boot/dual boot is grammatically nebulous whenever it refers to a bootloader menu that has more than two selections from which to choose
If support is to exist for _more_ than one operating system installation in addition to Fedora (e.g. Windows and Debian, or two Windows installations, or Windows plus Fedora plus another Fedora), the limiting term "dual" should not be used.
Whatever the criterion is called, it should be clear from discussion whether it can cover more than two operating system installations, or is limited to two only, so that no inference can be logically made from any use of "dual" that more than two is within scope.
The language should be consistent regarding all of OS X, Linux and Windows where any differences among them might be applicable.
"Dual boot" is a PC term coined by IBM very roughly thirty years ago in conjuction with creation of its OS/2 Boot Manager. It applied "dual" to two operating system installations sharing a single (C:) "system" filesystem, to distinguish diverse installations each having unique "system" filesystems (e.g. DOS and/or Windows on C:, OS/2 on D:), to which it applied the term "multi". Multi, being inclusive of two, aka dual as a common contemporary term, is the generically more sensible term for use on >1 systems. Dual makes good sense only when two only is meant.
On Tue, 2014-09-09 at 14:38 -0400, Felix Miata wrote:
On 2014-09-09 09:51 UTC-0600, Chris Murphy wrote:
QA wants a release criterion for dual boot OS X + Fedora installations.
If this is going to be done, it should have a grammatically unambigous name/title, and use grammatically unambigous language:
1-Multi-boot/multiboot is always grammatically correct if a system has more than one independent operating system installation
2-Dual-boot/dual boot is never grammatically correct if a system has more than two independent operating system installations
3-Dual-boot/dual boot is grammatically nebulous whenever it refers to a bootloader menu that has more than two selections from which to choose
If support is to exist for _more_ than one operating system installation in addition to Fedora (e.g. Windows and Debian, or two Windows installations, or Windows plus Fedora plus another Fedora), the limiting term "dual" should not be used.
The specification of *dual* not *multi* was intentional. IIRC the discussion, anyhow.
It's not about support "existing" but us blocking release on it *working*. The code will make a best effort to configure boot for whatever OSes it finds, unless we intentionally nerf it as we may for OS x, but the criteria are about the things we absolutely require must work for us to ship the release; in this context, we decided more than two OSes was being a little too ambitious.
I would prefer multi-boot in the title, simply because I run Fedora20 (2 versions), Fedora21 (test), Windows7 and Centos7. (5 disk home system)
Regards
Leslie
Mr. Leslie Satenstein SENT FROM MY OPEN SOURCE LINUX SYSTEM.
From: Adam Williamson adamwill@fedoraproject.org To: Discussion of Development and Customization of the Red Hat Linux Installer anaconda-devel-list@redhat.com Sent: Tuesday, September 9, 2014 10:47 PM Subject: Re: F21 Workstation dual-boot release requirement OS X
On Tue, 2014-09-09 at 14:38 -0400, Felix Miata wrote:
On 2014-09-09 09:51 UTC-0600, Chris Murphy wrote:
QA wants a release criterion for dual boot OS X + Fedora installations.
If this is going to be done, it should have a grammatically unambigous name/title, and use grammatically unambigous language:
1-Multi-boot/multiboot is always grammatically correct if a system has more than one independent operating system installation
2-Dual-boot/dual boot is never grammatically correct if a system has more than two independent operating system installations
3-Dual-boot/dual boot is grammatically nebulous whenever it refers to a bootloader menu that has more than two selections from which to choose
If support is to exist for _more_ than one operating system installation in addition to Fedora (e.g. Windows and Debian, or two Windows installations, or Windows plus Fedora plus another Fedora), the limiting term "dual" should not be used.
The specification of *dual* not *multi* was intentional. IIRC the discussion, anyhow.
It's not about support "existing" but us blocking release on it *working*. The code will make a best effort to configure boot for whatever OSes it finds, unless we intentionally nerf it as we may for OS x, but the criteria are about the things we absolutely require must work for us to ship the release; in this context, we decided more than two OSes was being a little too ambitious. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Tue, 2014-09-09 at 14:38 -0400, Felix Miata wrote:
On 2014-09-09 09:51 UTC-0600, Chris Murphy wrote:
QA wants a release criterion for dual boot OS X + Fedora installations.
If this is going to be done, it should have a grammatically unambigous name/title, and use grammatically unambigous language:
1-Multi-boot/multiboot is always grammatically correct if a system has more than one independent operating system installation
2-Dual-boot/dual boot is never grammatically correct if a system has more than two independent operating system installations
3-Dual-boot/dual boot is grammatically nebulous whenever it refers to a bootloader menu that has more than two selections from which to choose
If support is to exist for _more_ than one operating system installation in addition to Fedora (e.g. Windows and Debian, or two Windows installations, or Windows plus Fedora plus another Fedora), the limiting term "dual" should not be used.
The specification of *dual* not *multi* was intentional. IIRC the discussion, anyhow.
It's not about support "existing" but us blocking release on it *working*. The code will make a best effort to configure boot for whatever OSes it finds, unless we intentionally nerf it as we may for OS x, but the criteria are about the things we absolutely require must work for us to ship the release; in this context, we decided more than two OSes was being a little too ambitious.
Adam Williamson wrote on 2014-09-09 19:48 (GMT-0700):
The specification of *dual* not *multi* was intentional. IIRC the discussion, anyhow.
Fine. That's what I thought too. But...
It's not about support "existing" but us blocking release on it *working*. The code will make a best effort to configure boot for whatever OSes it finds, unless we intentionally nerf it as we may for OS x, but the criteria are about the things we absolutely require must work for us to ship the release; in this context, we decided more than two OSes was being a little too ambitious.
Given the widespread mis-use of dual-boot to mean more than one, I was trying to make the point that the written blocking language used needs to be especially carefully crafted to ensure it *can't* be misinterpreted to mean more than two.
On Sep 9, 2014, at 9:27 PM, Felix Miata mrmazda@earthlink.net wrote:
Given the widespread mis-use of dual-boot to mean more than one,
If by widespread you actually mean uncommon, then I agree. The word dual comes from a root word that means two. Any confusion on this point is made worse by using a prefix that doesn't mean two, but rather means many or much.
I was trying to make the point that the written blocking language used needs to be especially carefully crafted to ensure it *can't* be misinterpreted to mean more than two.
Right, hence dual boot. I understand in the context of booting, the programming/engineering vernacular is multiboot. But release criteria attempts to use plain language whenever possible, and multi-boot is less specific than dual-boot.
Chris Murphy
Chris Murphy wrote on 2014-09-10 13:38 (GMT-0600):
Felix Miata wrote:
Given the widespread mis-use of dual-boot to mean more than one,
If by widespread you actually mean uncommon, then I agree.
I meant common in the common sense of the word common, as in this scenario:
1-bought PC, as most do, with Windows pre-installed 2-later navigated successfully through the shrink Windows and install *buntu process 3-still later either added a newer *buntu release, or added Debian/Fedora/Mint/openSUSE/yada, only to find "dual-boot" system remains "dual-boot" (can no longer boot original Linux distro) or has become (Linux) mono-boot?
Common can also apply in a more limited context, such as under this roof, where dual-boot machines are totally absent, mono-boot machines are scarce, and multi-boot machines are more than the fingers and toes on one human body can account for.
The word dual comes from a root word that means two. Any confusion on this point is made worse by using a prefix that doesn't mean two, but rather means many or much.
Whether worse depends on context. By using the broader term when generically speaking of a broader context, there should follow less mis-use of the narrower term, allowing it to better serve narrower contexts, as could happen on account of the decision underlying this thread.
I was trying to make the point that the written blocking language used needs to be especially carefully crafted to ensure it *can't* be misinterpreted to mean more than two.
Right, hence dual boot. I understand in the context of booting, the programming/engineering vernacular is multiboot. But release criteria attempts to use plain language whenever possible, and multi-boot is less specific than dual-boot.
Of course. But might it not serve better to capture broader audience attention first using the more inclusive term as a title, then apply the more restrictive term to drive home the point that there shall be a hard limit of two in the narrow Fedora release blocking context?
On Tue, 2014-09-09 at 09:51 -0600, Chris Murphy wrote:
QA wants a release criterion for dual boot OS X + Fedora installations. I floated this one on test@, and it's passed initial acceptance by Adam Williamson and Michael Catanzaro.
{ 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 an OS X entry, it should boot OS X. }
The gist is that if there are OS X boot entries they should work. This email proposes two ways to make them go away, and relies mainly on the firmware's built-in boot manager [1] instead to switch between OS's. I suspect a minority aren't familiar with this interface, and many others drop GRUB2 post-install in favor of rEFInd or gummiboot. The explanation for why the underlying problem with the broken entries won't be fixed anytime soon is at the end, because it's too long and you probably don't want to read it. [2]
Option A, patch Anaconda: If platform.MacEFI, anaconda writes out /etc/default/grub to include: GRUB_DISABLE_OS_PROBER=true
Consequence: Non-Fedora boot entries won't be created. This includes OS X, pre-existing Linux distros, and Windows. Due to other bugs and limitations it's virtually certain those entries wouldn't work anyway. The alternatives to the broken entries are already primarily in use due to necessity.
Option B, patch GRUB: Modify util/grub.d/30_os-prober.in to remove (or comment out) lines 44-106. This means grub2-mkconfig simply won't create OS X entries, but will still create other OS entries.
Is there a preference for one of these options, or is there an option c. ? My opinion is to go with option A. It's the simplest patch, it's upstream and downstream tested and supported, it's more discoverable than option B, and it's the only one users can revert post-install.
I'm for A for now because we can give users an easy guide how to change it and run grub2-mkconfig on their systems with proper warnings. On the other hand I think that grub shouldn't create OS X entries as long as it cannot boot them.
On 09/09/2014 11:51 AM, Chris Murphy wrote:
QA wants a release criterion for dual boot OS X + Fedora installations. I floated this one on test@, and it's passed initial acceptance by Adam Williamson and Michael Catanzaro.
{ 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 an OS X entry, it should boot OS X. }
The gist is that if there are OS X boot entries they should work. This email proposes two ways to make them go away, and relies mainly on the firmware's built-in boot manager [1] instead to switch between OS's. I suspect a minority aren't familiar with this interface, and many others drop GRUB2 post-install in favor of rEFInd or gummiboot. The explanation for why the underlying problem with the broken entries won't be fixed anytime soon is at the end, because it's too long and you probably don't want to read it. [2]
Option A, patch Anaconda: If platform.MacEFI, anaconda writes out /etc/default/grub to include: GRUB_DISABLE_OS_PROBER=true
Consequence: Non-Fedora boot entries won't be created. This includes OS X, pre-existing Linux distros, and Windows. Due to other bugs and limitations it's virtually certain those entries wouldn't work anyway. The alternatives to the broken entries are already primarily in use due to necessity.
Option B, patch GRUB: Modify util/grub.d/30_os-prober.in to remove (or comment out) lines 44-106. This means grub2-mkconfig simply won't create OS X entries, but will still create other OS entries.
Is there a preference for one of these options, or is there an option c. ? My opinion is to go with option A. It's the simplest patch, it's upstream and downstream tested and supported, it's more discoverable than option B, and it's the only one users can revert post-install.
Let me go a step further and suggest that GRUB_DISABLE_OS_PROBER=true should be the default for all installs!
1. After installation, a user can turn it back on if they want it but, by default, the "strange" /etc/grub.d/30_os-prober menuentrys would not be generated. Sometimes they work but sometimes they do not.
2. There is the additional problem in Fedora 21 due to grub2-2.02 now using linux16/initrd16 for all linux menuentrys [see https://bugzilla.redhat.com/show_bug.cgi?id=1108296 and https://bugzilla.redhat.com/show_bug.cgi?id=1108344]
3. Rather than supporting multi-boot with 30_os-prober, a user can use 40_custom or 41_custom to add menuentrys which can "chain load" using configfile rather than trying to (poorly) create a valid menuentry which will actually boot the other system(s).
4. The "nombr" anaconda patch I submitted results in grub2 being correctly installed and configured but haing the mbr *not* actually updated. Thus another installed system, which does have the mbr pointing to it, can act as a "boot director" to chainload using configfile grub.cfg or chainload +1 a boot partition.
Suggestion: If GRUB_DISABLE_OS_PROBER=true is the new default, I suggest that there be some additional documentation explaining how to create 40_custom and/or 41_custom files which will boot the other installed systems ... or not in the case of OS X where there is a better alternative of using the firmware.
Gene
anaconda-devel@lists.stg.fedoraproject.org