Hi folks. We've had a discussion going for a few months now over on test@ about release criteria for dual/multi-booting with other Linux installations. I actually thought this discussion had made it here to a-d-l at some point, but it seems I was mistaken in that.
So I mistakenly proposed an F21 Final criterion requiring dual-boot with Fedora to work (on the false assumption everyone was already working under that expectation already). I'm withdrawing it as a proposal for F21, but I think it makes sense for F22, so I'm keeping it as a live proposal, and I'll re-post it here:
===
When installing to a system containing an existing installation of the same Fedora release or either of the two previous releases, the installer must configure the new installation's bootloader such that it can successfully boot the existing installation.
[Footnote] Typical configurations only: This criterion applies only to installations (both existing and new) using default or very common storage and bootloader configurations.
[Footnote] Platforms: This criterion applies to all supported configurations described in [[Fedora_22_Alpha_Release_Criteria#Release-blocking_images_must_boot|the Alpha criteria]], but does not apply to mixed configurations, e.g. it does not require that a UEFI native installation of one Fedora release be able to configure its bootloader to boot a BIOS native installation of another Fedora release.
===
What do folks think about that as an F22 Final criterion? In the test@ discussion there's a rather broader proposal from cmurf which covers dual booting with other distros and is less restrictive as to the supported configurations, but I thought it might be easier to get consensus for something more restricted at least as a starting point.
On 11/07/2014 04:17 PM, Adam Williamson wrote:
Hi folks. We've had a discussion going for a few months now over on test@ about release criteria for dual/multi-booting with other Linux installations. I actually thought this discussion had made it here to a-d-l at some point, but it seems I was mistaken in that.
So I mistakenly proposed an F21 Final criterion requiring dual-boot with Fedora to work (on the false assumption everyone was already working under that expectation already). I'm withdrawing it as a proposal for F21, but I think it makes sense for F22, so I'm keeping it as a live proposal, and I'll re-post it here:
===
When installing to a system containing an existing installation of the same Fedora release or either of the two previous releases, the installer must configure the new installation's bootloader such that it can successfully boot the existing installation.
[Footnote] Typical configurations only: This criterion applies only to installations (both existing and new) using default or very common storage and bootloader configurations.
[Footnote] Platforms: This criterion applies to all supported configurations described in [[Fedora_22_Alpha_Release_Criteria#Release-blocking_images_must_boot|the Alpha criteria]], but does not apply to mixed configurations, e.g. it does not require that a UEFI native installation of one Fedora release be able to configure its bootloader to boot a BIOS native installation of another Fedora release.
===
What do folks think about that as an F22 Final criterion? In the test@ discussion there's a rather broader proposal from cmurf which covers dual booting with other distros and is less restrictive as to the supported configurations, but I thought it might be easier to get consensus for something more restricted at least as a starting point.
I agree.
However, there is some clarification I need.
1. How about multiboot between Fedora and RHEL? I am think more in the idea of Fedora booting a RHEL/CentOS installation rather than the opposite. To say that this was not supported is also reasonable.
2. I assume that this applies to a single bootloader and that bootloader is grub2. We are not talking about multiboot extlinux or about booting extlinux from grub2. IIRC, both of these are possible but I consider them to be beyond the scope of the problem we are trying to solve.
3. We are talking about being able to multiboot OS X or Windows. Windows implemented as chainload +1 and OS X as ? where the approach is better described by Chris Murphy.
4. While there once was a very reasonable requirement to multiboot other distributions and systems including *BSD, I consider that the current virtualization technology has greatly reduced the need to support booting such systems. If it works, that is fine and if it does not work out of the box, the need will likely involve an "expert" who will be able to make it work.
And then there is linux16/initrd16 versus 32 bit linux/initrd. Is there some configuration where linux16/initrd16 will *not* work? That is, is there some situation where a feature in the 32 bit implementation is needed?
BTW, is linuxefi/initrdefi a 16 bit or a 32 bit implementation? My guess: 32 bit.
Adam, I believe you have basically nailed what the criteria should be. This is in complete agreement with my Rule Number One: *do not destroy a working system to install a new system*! And this rule is why I do fresh installs rather than (fedup) upgrades.
Gene
On Sat, 2014-11-08 at 11:20 -0500, Gene Czarcinski wrote:
However, there is some clarification I need.
This is a *criterion* discussion, note, not a technical implementation discussion.
- How about multiboot between Fedora and RHEL? I am think more in the idea of Fedora booting a RHEL/CentOS installation rather than the opposite. To say that this was not supported is also reasonable.
Not covered by this. If everyone wanted to cover it, it would be a fairly obvious amendment. Thoughts?
- I assume that this applies to a single bootloader and that bootloader is grub2. We are not talking about multiboot extlinux or about booting extlinux from grub2. IIRC, both of these are possible but I consider them to be beyond the scope of the problem we are trying to solve.
Correct.
- We are talking about being able to multiboot OS X or Windows. Windows implemented as chainload +1 and OS X as ? where the approach is better described by Chris Murphy.
We already have criteria for both OS X and Windows dual boot. We've already agreed minor changes to them earlier in the cycle. See https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Windows_dual... and https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#OS_X_dual_bo... .
And then there is linux16/initrd16 versus 32 bit linux/initrd. Is there some configuration where linux16/initrd16 will *not* work? That is, is there some situation where a feature in the 32 bit implementation is needed?
I'd say that's out of scope for this discussion. FWIW, though, I haven't been able to divine a specific reason yet, but upstream seems to consider the 16-bit loader to be 'legacy', whatever that means.
From: Adam Williamson awilliam@redhat.com To: anaconda-devel-list@redhat.com Sent: Friday, November 7, 2014 4:17 PM Subject: Release criteria for dual/multi-booting with other Fedora and other Linux installs
Hi folks. We've had a discussion going for a few months now over on test@ about release criteria for dual/multi-booting with other Linux installations. I actually thought this discussion had made it here to a-d-l at some point, but it seems I was mistaken in that.
So I mistakenly proposed an F21 Final criterion requiring dual-boot with Fedora to work (on the false assumption everyone was already working under that expectation already). I'm withdrawing it as a proposal for F21, but I think it makes sense for F22, so I'm keeping it as a live proposal, and I'll re-post it here:
===
When installing to a system containing an existing installation of the same Fedora release or either of the two previous releases, the installer must configure the new installation's bootloader such that it can successfully boot the existing installation.
[Footnote] Typical configurations only: This criterion applies only to installations (both existing and new) using default or very common storage and bootloader configurations.
[Footnote] Platforms: This criterion applies to all supported configurations described in [[Fedora_22_Alpha_Release_Criteria#Release-blocking_images_must_boot|the Alpha criteria]], but does not apply to mixed configurations, e.g. it does not require that a UEFI native installation of one Fedora release be able to configure its bootloader to boot a BIOS native installation of another Fedora release.
===
What do folks think about that as an F22 Final criterion? In the test@ discussion there's a rather broader proposal from cmurf which covers dual booting with other distros and is less restrictive as to the supported configurations, but I thought it might be easier to get consensus for something more restricted at least as a starting point.
On Fri, 2014-11-07 at 13:17 -0800, Adam Williamson wrote:
Hi folks. We've had a discussion going for a few months now over on test@ about release criteria for dual/multi-booting with other Linux installations. I actually thought this discussion had made it here to a-d-l at some point, but it seems I was mistaken in that.
So I mistakenly proposed an F21 Final criterion requiring dual-boot with Fedora to work (on the false assumption everyone was already working under that expectation already). I'm withdrawing it as a proposal for F21, but I think it makes sense for F22, so I'm keeping it as a live proposal, and I'll re-post it here:
===
When installing to a system containing an existing installation of the same Fedora release or either of the two previous releases, the installer must configure the new installation's bootloader such that it can successfully boot the existing installation.
[Footnote] Typical configurations only: This criterion applies only to installations (both existing and new) using default or very common storage and bootloader configurations.
[Footnote] Platforms: This criterion applies to all supported configurations described in [[Fedora_22_Alpha_Release_Criteria#Release-blocking_images_must_boot|the Alpha criteria]], but does not apply to mixed configurations, e.g. it does not require that a UEFI native installation of one Fedora release be able to configure its bootloader to boot a BIOS native installation of another Fedora release.
===
What do folks think about that as an F22 Final criterion? In the test@ discussion there's a rather broader proposal from cmurf which covers dual booting with other distros and is less restrictive as to the supported configurations, but I thought it might be easier to get consensus for something more restricted at least as a starting point.
This is definitely a good strategy and I think the criterion above is a good starting point. It would be nice to put there Windows and OS X as "required to keep working out of the box", but there have been so many issues with these that I'm quite sure it would mean slips for Fedora 22 and we would still not catch all the quirks.
So ACK from me.
What do folks think about that as an F22 Final criterion? In the test@ discussion there's a rather broader proposal from cmurf which covers dual booting with other distros and is less restrictive as to the supported configurations, but I thought it might be easier to get consensus for something more restricted at least as a starting point.
This is definitely a good strategy and I think the criterion above is a good starting point. It would be nice to put there Windows and OS X as "required to keep working out of the box",
We have had Windows and OS X dual boot criteria for a long time :-) https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Windows_dual... https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#OS_X_dual_bo...
That's one of the reasons why people push for Linux dual boot criterion as well (or, at least, Fedora dual boot).
On Mon, 2014-11-10 at 03:16 -0500, Kamil Paral wrote:
What do folks think about that as an F22 Final criterion? In the test@ discussion there's a rather broader proposal from cmurf which covers dual booting with other distros and is less restrictive as to the supported configurations, but I thought it might be easier to get consensus for something more restricted at least as a starting point.
This is definitely a good strategy and I think the criterion above is a good starting point. It would be nice to put there Windows and OS X as "required to keep working out of the box",
We have had Windows and OS X dual boot criteria for a long time :-) https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Windows_dual... https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#OS_X_dual_bo...
I meant something like "Windows, Fedora X-1, Fedora X, Ubuntu" multiboot or something like that with OS X instead of Windows.
On Nov 7, 2014, at 2:17 PM, Adam Williamson awilliam@redhat.com wrote:
What do folks think about that as an F22 Final criterion? In the test@ discussion there's a rather broader proposal from cmurf which covers dual booting with other distros and is less restrictive as to the supported configurations, but I thought it might be easier to get consensus for something more restricted at least as a starting point.
I think it’s inappropriate to stomp on the bootability of other distros, more than stomping on ourselves. Breaking Fedora n-1 bootability is kinda perversely amusing, but it’s just bad manners to do it to another OS. That’s why there’s Windows and OS X criteria to make sure we don’t render them unbeatable. It’s just not a good experience.
My broader idea was restricted to that of “if upstream grub works” but Fedora’s grub breaks boot, then it’s our bug and we should block on such a bug until it’s fixed. This does burden the tester to build upstream grub to demonstrate that it would have worked in a case where Fedora’s grub doesn’t. Arguably that’s an unfair burden, I’m open to a more fair metric.
And also, upstream grub isn’t exactly elegant with its solution. It creates generic boot entries for “other” Linux OS’s rather than merely pointing to each distro’s grub.cfg which contains distro specific boot parameters. And it’s the only grub.cfg that’s updated when that distro’s kernels are updated. We have to manually run grub2-mkconfig for those new kernels to show up in the current grub.cfg. A consequence of not having a shared boot among distros.
Chris Murphy
anaconda-devel@lists.stg.fedoraproject.org