On Thu, 16 Oct 2025 10:47:26 +0000 Zbigniew Jędrzejewski-Szmek <[email protected]> wrote:
> On Wed, Oct 15, 2025 at 11:53:16AM -0400, Neal Gompa wrote: > > On Wed, Oct 15, 2025 at 11:43 AM Chris Murphy <[email protected]> > > wrote: > > > On Mon, Oct 13, 2025, at 10:20 AM, Lennart Poettering wrote: > > > > On Do, 09.10.25 14:51, Chris Murphy ([email protected]) wrote: > > > >> Boot Loader Spec [1] says, verbatim > > > >> > > > >> "ESP must — and the MBR boot and GPT XBOOTLDR partition should — be a > > > >> file system readable by the firmware" > > > >> > > > >> XBOOTLDR is permitted by the spec to be any file system. > > > >> > > > >> ESP and BOOTLDR are not required to be writeable by the firmware. > > > > > > > > Well, sure, we allowed some flexibility there, but made the intention > > > > clear, no? > > > > > > Super clear. Non-FAT XBOOTLDR is permitted. Non-FAT EFI file system > > > drivers to provide firmware-level support for a file system, is permitted. > > > > > > If Boot Loader Spec aims to constrain the UEFI spec, then it needs to use > > > language that does that. > > > > > > >Of course, I regret having granted the flexibility, that > > > > was a mistake. > > > > > > What about fixing the spec to reflect this? > > > > > > Because then the present behavior is a legitimately a bug and can be > > > reverted to use the generic Linux partition type GUID, or something else. > > > And stop proliferating non-FAT XBOOTLDR. > > > > > > > If that happened, then we'd permanently diverge and stop attempting to > > follow the spec for bootloader configuration. > > > > Remember that BLS is implemented in GRUB and ZIPL, both are used on > > non-UEFI architectures. > > What filesystem is used for them there? on s390x with ZIPL it can be any filesystem, the userspace zipl tool creates a (disk) block list in /boot/bootmap file when adding a new boot entry, the blocklist is then used by the actual bootloader. It merges the BLS snippets with the native /etc/zipl.conf which can be empty. on ppc64le (PowerNV aka bare-metal) the boot process uses either the BLS snippets or generated grub.cfg, it's a kexec based boot process with petitboot as the boot application in a separate Linux environment. Something like nmbl [1] is trying to achieve. on ppc64le (pseries - LPARs and KVM guests) the grub binary lives (dd-ed) in a separate partition (PReP type) and then it accesses any grub supported filesystem for /boot. Also be aware that eg. on s390x the cloud qcow2 image is created without separate /boot partition in Fedora and RHEL. [1] https://lwn.net/Articles/979789/ Dan -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
