On Tue, 2020-06-30 at 19:15 +0200, Gerd Hoffmann wrote:
> > So I can't say I'm thrilled about a future that depends on EFI for
> > virt, but I'm resigned to the fact this is the direction the world
> > is taking. So we're not likely to have any choice and will have to
> > work to mitigate any downsides it brings.
> Preferably the installer should detect and setup the system either with
> sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI )
Another problem is that grub2 covers more architectures than sd-boot.
What is the plan for armhfp, ppc64, s390x?
This part wouldn't really be a problem in the scheme Johann suggests
above, because 'sdboot' would just be another bootloader class in
anaconda in this case, along the several we have already.
IMHO a better preparation for deprecating BIOS would be to make new
installs bootable with both BIOS and UEFI. Which isn't hard at least
for the "[x] use all space" case where Fedora can partition the disk as
it pleases: Use gpt. Create a bios boot partition, install grun-pc
there. Create a ESP partition, install grub-efi there. Create a
partition for the /boot filesystem. Have both grubs pick up BLS config
That would have to be implemented as another class too, probably. :)
is where all this is implemented at present (mostly, the classes there
do pull in various bits of config and info from other places). There's
already quite a mess there, anything we add without taking a way any
existing capabilities will make it a slightly bigger mess...
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net