On Thursday, 07 April 2022 at 18:42, Robbie Harwood wrote:
Michael Catanzaro mcatanzaro@gnome.org writes:
On Wed, Apr 6 2022 at 03:35:38 PM -0400, Jared Dominguez jaredz@redhat.com wrote:
This seems like a strong assumption to me considering that aside from the largest cloud providers (with whom Red Hat is directly working with on UEFI boot features and bug reports), cloud providers are using off-the-shelf hypervisors that support UEFI boot.
I'm going to ask the proposal authors to at least mention this as a risk in the Feedback section of the change proposal. Maybe cloud providers will all see this as a good opportunity to enable UEFI on their platforms, and we'll be perfectly fine. I rather suspect it's not going to happen quite so smoothly, though....
I have appended added my analysis of this to the Feedback section. For clarity, it's copied here:
During mailing list discussion of this change, concern was expressed that some of the smaller hosting providers who do not provision with UEFI today and do not also support Windows would drop Fedora rather than enabling UEFI. Given that the major virtualization solutions (vsphere, kvm, xen, bhve, virtualbox, ...) all support UEFI today,
...latest versions of... And the provider in question might not be running the latest version.
this would likely be exposing an existing capability rather than making a sweeping change.
It's equally likely that they'd have to upgrade their virtualization platform to the latest version first and then update their internal UI/tooling to expose UEFI. I'd call that a sweeping change while you're downplaying the scope of it.
That said, it is always possible that providers may elect to drop Fedora rather than adjust their setups - be it for this change or any other change Fedora makes.
That's completely unnecessary. It adds nothing but attempt to dilute the impact of this change.
Regards, Dominik