On Di, 30.06.20 19:15, Gerd Hoffmann (kraxel@xxxxxxxxxx) 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
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
