On 4/7/22 15:30, Chris Murphy wrote:
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.
Can the disk be partitioned so that it is valid for *both* MBR and GPT?