On Di, 30.06.20 19:15, Gerd Hoffmann (kraxel@redhat.com) wrote:

  Hi,

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.

Right.

Preferably the installer should detect and setup the system either with
sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI )

I have my doubts that building on sd-boot and drop grub2 is going to fly.

One problem with sd-boot is that the kernels must stay on the ESP, which
can be a problem for dual-boot installs (where Fedora has to run with
the existing ESP and can't just create one which is big enouth).

Nah, that's not true. Hasn't been for quite a while.

sd-boot checks for kernels in the ESP first, and then on a second
partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR
partition is simply a partition with type UUID
bc13c2ff-59e6-4262-a352-b275fd6f7172.

This means installers have two options:

1. Create a large ESP and just use that. Everything is nice and simple

2. If the ESP already exists and there's no interest in growing it,
   just add in an XBOOTLDR partition and use that instead.

The latter (2) is presumably what manufactures would want OS and their installers to default to.

As in don't destroy or resize ( which could risk destroying it ) the existing ESP that comes from the factory and may contain manufacturers specific tools instead keep it as it is and place only the boot manager ( sd-boot ) on the existing ESP while OS specific kernels ( and any other stuff the OS might want to place on the ESP ) is placed on a separate XBOOTLDR partition.

The above is probably also the best compatibility scenario for dual boot or multi boot scenarios.

Another problem is that grub2 covers more architectures than sd-boot.
What is the plan for armhfp, ppc64, s390x?

sd-boot is uefi only, but it should work fine with any arch that is
supported by uefi.

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
from /boot/loader.

My suggestion would be: don't standardize on boot loaders, standardize
on the boot loader spec. And I mean, the real boot loader spec, i.e
not this terrible template language that Fedora now supports in Grub,
which is just the same old grub complexity again. They stole the "Boot
Loader Spec" name and turned it into something that is not related at
all to the real thing.

Supporting the boot loader spec has various benefits, including that
systemd's "systemctl kexec" will just work and understand these tiems.

Yeah I was going to look at that as well ( how far off Fedora is from the boot loader specification and where it's going off the rails ) while I'm looking at this.

JBG