> On Apr 7, 2022, at 2:31 AM, Neal Gompa <ngomp...@gmail.com> wrote: > > On Thu, Apr 7, 2022 at 2:20 AM Gerd Hoffmann <kra...@redhat.com> wrote: >> >> Hi, >> >>> On the cloud side, it's been very difficult to articulate any benefits >>> for supporting UEFI when the majority of the consumers of Fedora Cloud >>> don't have any pressing need to do it and things like hibernation and >>> snapshotting are non-functional. Last year, I changed Fedora Cloud to >>> hybrid boot[6] so that our image artifacts support both boot modes. >> >> Any chance for regular anaconda installs doing a hybrid boot setup too? >> >> The installed systems will look pretty much the same (gpt with both >> bios-boot and efi-esp partition) no matter how they where installed, >> and it'll be trivial to switch from BIOS to UEFI without reinstalling >> the system. >> >> We can fade out some stuff already (mbr support), and painless switching >> to UEFI for systems which where installed in BIOS mode for whatever >> reason should also help UEFI adaption. >> > > Anaconda can absolutely do it, after all, the cloud image build > currently runs Anaconda (!!!) to build the image. > > In this scenario, grub2-pc, shim, and grub2-efi always get installed, > too. This became possible with the unified config introduced in Fedora > Linux 34. > > The problem is that right now Anaconda has some hardwired assumptions > about what kind of bootloader and partitioning to request for all the > default partitioning modes. It shouldn't be difficult to fix, though. > Additionally, by switching to GPT by default for everything, we > probably want to replace inst.gpt with inst.mbr for forcing legacy > MBR. > > If we did this now (in F37), we could then more easily fade out BIOS > support when the adoption curve is better off. >
And this is exactly what we need in my opinion. It sounds like there has been a great deal of thought put into what the developers can manage on the supporting team, but it also appears that issues have prevented direct contribution based on some sort of misconfiguration in the repository, though it sounds like this is fixed as of this discussion. It still speaks to more than a year of complication in contribution. Is Neal really the only one who was impacted by the inability to submit a PR? I think that creating choice is the right response and that’s exactly why we created a dually supported boot model in the cloud (soon-to-be-edition again) working group (thank you Neal and Gerd). Choice is our best tool in the freedom toolkit. I have heard many say that there is no rush to remove support for hardware that is in use by those of the community that may not be capable of switching. I would like to see a period of joint support in Fedora with the promise that the legacy-bios support will be removed when it no longer serves the community, but not before that time is clear. It obviously does have an end date consistent with F37 release. VMware’s deprecation does not set a date. It sets the promise of announcing a date at a later time. I think we should follow suit. A future, as yet undetermined, Fedora release will not have legacy-bios and we understand that it is expected to follow a concerted effort to make moving to UEFI as easy as possible. If you have to fallback, there should be an immediately available option like Gerd and Neal have implemented in their changes. In the meantime, this is obviously going to require a rally of community support. As a community, we are going to have to limit the amount of explaining we need to do. To loosely quote the agile manifesto: It is better to focus on working code than to focus on comprehensive documentation. I see that as a directive to ship support for both boot models in all editions for at the very least, one release and better to provide a minimum of two. - David _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
