Hi Chris, Just wanted to say that David Cantrell and the Anaconda team are looking at this to see what they can do to try to improve things for F21. So thanks for putting this list together, it is very useful. Christian ----- Original Message ----- > From: "Chris Murphy" <lists@xxxxxxxxxxxxxxxxx> > To: "Discussions about development for the Fedora desktop" <desktop@xxxxxxxxxxxxxxxxxxxxxxx>, "Michael Catanzaro" > <mcatanzaro@xxxxxxxxx> > Cc: server@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Sunday, June 29, 2014 7:15:25 PM > Subject: Re: Multibooting UX, how well it ought to work > > > On Jun 27, 2014, at 10:52 AM, Michael Catanzaro <mcatanzaro@xxxxxxxxx> 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)? > > > > Yes. > > > >> 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? > > > > Yes. > > > >> 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 > > problematic? > > 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 [1], 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 > > reliably. > > 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 that > > 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 interoperability. > > Chris Murphy > > > > > [1] 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. > https://bugzilla.redhat.com/show_bug.cgi?id=825236 > > UEFI, preexisting Windows:, boot entry either not created for Windows or it > doesn't work. > https://bugzilla.redhat.com/show_bug.cgi?id=986731 ## Year old bug. > https://bugzilla.redhat.com/show_bug.cgi?id=1010704 ## 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. > https://bugzilla.redhat.com/show_bug.cgi?id=964828 > > UEFI, preexisting OS X: boot entries don't work, have never worked for me in > 3+ years. Two 18 month old bugs. > https://bugzilla.redhat.com/show_bug.cgi?id=904668 ## 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. > https://bugzilla.redhat.com/show_bug.cgi?id=893179 ## 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). > -- > desktop mailing list > desktop@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/desktop -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
