On Thu, Apr 7, 2022 at 12:20 AM Gerd Hoffmann kraxel@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?
Anaconda is used for this purpose to make dual firmware supporting VM images. Cloud edition does it, and it's also done within RHEL and CentOS.
I would sooner expect optical boot support to go away before BIOS boot. But I only have anecdotes to go on.
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.
There have been two prior attempts to move to GPT by default (i.e. drop MBR by default when legacy BIOS is detected), and due to firmware bugs, it never progressed to any Fedora release. I can't guess what percent of hardware in the Fedora community is BIOS vs UEFI, and it's even harder to estimate what percent of BIOS hardware are affected by the GPT bug.
But I suppose that can being kicked down the road has also lead to the pressure resulting in this change proposal. Hindsight being 20/20, maybe moving to GPT by default would have been OK after all, because those users could just boot the installer with inst.mbr. I'm not sure whether it makes sense to deprecate this now though.