On Thu, Apr 7, 2022 at 2: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?
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.
-- 真実はいつも一つ！/ Always, there's only one truth!