On Jun 27, 2014, at 10:52 AM, Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
My personal opinions:
On Thu, 2014-06-26 at 18:51 -0600, Chris Murphy wrote:
> 1a. Does preserve preexisting include providing a working menu entry
> in the boot manager (e.g. in the GRUB menu)?
> 1b. Or is it sufficient to just preserve the installation data —
> meaning it's permissible for its bootability to be either non-obvious
> or broken?
No. Users will not be able to recover from this scenario.
> 2. If the answer to 1a. is yes, and 1b. is no, does this dual-boot
> requirement apply to both BIOS and UEFI?
> 3. If resources cannot meet the dual-boot requirement by ship time,
> should the installer inform the user that their previous installation
> will be preserved but may not be bootable?
I think that would be OK, if the warning is clear and you have to click
a red button to bypass it.
Can you link to the discussion on why the above requirements are
This is it. I'm uncertain how they can be requirements without a mandate from the
Workstation WG or FESCo. The bugs aren't new , they vary from 1-3 years old, and
none made it to either freeze exception or release blocker status expressly because
there's no applicable release criteria. Hence request to clarify the scope of the tech
spec "preserve existing" language.
> 4. Why is the preservation of an existing Linux OS, including a
> previous Fedora, not explicit in the spec? Should it be?
This would be nice to have. When I tried dual-booting a year or so ago,
the status quo was that os-prober usually worked, but not really
I don't have a short explanation for this, but a lot of the problems here are bugs I
summarize below. But in addition, right now grub-mkconfig creates generic boot entries
from scratch for other Linux OS's that get found. Therefore two problems arise with
those boot entries: the distro/user specified boot parameters aren't used, and any
kernel updates in those other Linux OS's aren't reflected in the GRUB menu. GRUB
has tools to do better, it's just that they aren't being used by upstream's
own 30_os-prober script. If instead it used configfile to point to the distro specific
grub.cfg/conf, neither problem described would happen. So someone build a ship yard, but
no one's building ships. It's kinda weird.
If we adopt the bootloader spec, then it we should add a guarantee
we preserve the ability to boot other Linux systems that adhere to that
spec (which is admittedly none). But there was significant debate over
whether Fedora should adopt that spec.
Well we sorta have with respect to the implied configuration file format. Fedora
Atomic/OSTree, and the blscfg.mod patch for GRUB (since GRUB upstream rejects
bootloaderspec as written) both use the bls conf file format. The problem is the way
we're implementing it departs from the spec in some fundamental ways, in part because
the spec is so limiting (e.g. $BOOT is required to be FAT16/32) so it's instantly lost
 Summary of Fedora bootloading bugs:
BIOS, preexisting Windows: reliably has a working boot entry created. For other
combinations all bets are off:
BIOS or UEFI, preexisting Linux using LVM: boot entries not created because preexisting
OS's LV's aren't activated by the installer, so os-prober/grub2-mkconfig
don't find the preexisting OS. Two year old bug, finger pointing, no agreement on who
should fix it.
UEFI, preexisting Windows:, boot entry either not created for Windows or it doesn't
## Year old bug.
## This bug was rejected as an F20
blocker on the basis that the release criteria for Windows only applies to BIOS.
UEFI, preexisting Linux no-LVM: boot entry does not work. This is a Fedora GRUB specific
bug, over a year old, was rejected for freeze exception so it stands to reason it would
have been rejected as a blocker as well.
UEFI, preexisting OS X: boot entries don't work, have never worked for me in 3+ years.
Two 18 month old bugs.
## Kernel panic might now be fixed by
upstream, but upstream's solution is flaky and prone to breakage every time Apple
makes a kernel change. Upstream insists on using their own bootloader rather than
Apple's for unknown reasons.
## Described fix by adding GRUB xnu
modules to grubx64.efi has not been implemented. Secondary problem is that there are two
superfluous entries that don't work due to confusion resulting from Fedora's
mactel-boot support (os-prober thinks the Fedora boot entries are an OS X installation).