On Mi, 08.10.25 16:21, Chris Murphy ([email protected]) wrote: > > > On Sun, Oct 5, 2025, at 7:38 AM, Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Sep 22, 2025 at 07:54:16AM +0200, Simon de Vlieger wrote: > >> Note that Neal also has ideas to move XBOOTLDR into a btrfs subvolume > >> which for > >> many of the default editions and spins would remove the problem entirely. > > > > That's the "worst of both worlds" solution. It means that the boot loader > > thas to understand and fully access the the root volume, which means that > > the boot loader must have code to read the file system. When encryption > > is used, the boot loader must implement this too. This is all very > > constraining > > and fragile. > > *shrug* (open)SUSE, macOS, and Windows do it this way. The bootloader knows > how to deal with encryption and root file system, and get on with things. > macOS and Windows do have dedicated recovery partitions. > > > And there's really no need for that. If we're creating the ESP, > > just make it large enough. If we can't grow the ESP and it's tiny, then just > > create a large-enough XBOOTLDR… > > Anaconda sets the boot partition to type XBOOTLDR for a while now. I'm not > sure about all other methods of installation. > > We still defer to fstab for mounting /boot and /boot/efi. That > should go away in favor of discoverable partitions and mounting them > on demand only when needed at /efi and /boot per BLS. > > GRUB is also looking boot by volume UUID. It's not looking for > XBOOTLDR. And that means it probably can't accomodate two XBOOTLDR's > seemlessly. I'm not sure off hand if sd-boot can. Nor do I know if > the kernel installation scripts can support multiple XBOOTLDR's > (just use the one that's the least full?)
Uh, multiple XBOOTLDR on the same disk is not spported by the spec. Multiple ESPs isn't. There can be zero or one of either, not more. Lennart -- Lennart Poettering, Berlin -- _______________________________________________ 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
