Re: [PATCH 0/2] blsuki: Add support for the XBOOTLDR partition
On Fri, Dec 12, 2025 at 1:17 PM Luca Boccassi wrote: > Yes it is extremely important to ensure the autodiscovered partition > is on the same device as the ESP where the running bootloader was > loaded from. Otherwise bad things can happen - for example, someone > can plug in a usb disk and trick you into booting something that you > never intended to. It's fundamental for autodiscovery not only in EFI > mode, but in userspace later, so please ensure this restriction is > respected. I would say in UEFI case the best approach is getting the device name via grub_efi_get_loaded_image()->device_handle. I'm just not sure if the XBOOTLDR partition can be used in non-UEFI systems that support BLS (like s390?) and what would be a way to handle those cases as well. ___ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/2] blsuki: Add support for the XBOOTLDR partition
On Fri, Dec 12, 2025 at 1:11 PM Neal Gompa wrote: > Would it be worth it to consider also searching the ROOT volume too > (in /boot/loader/entries) similarly to XBOOTLDR, especially in the > case where /boot is part of the main disk volume? This case exists in > Fedora Cloud (F44+ as a Btrfs subvolume[1]), RHEL (RHEL10+ as a folder > in the root XFS volume[2]), and SUSE distributions (where /boot is a > folder in the root subvolume and contents of it are subvolumes[3]). > > It's now common enough that basic autodiscovery of those cases makes > sense to be able to consider. My logic has been to keep as close to the spec as possible if the blscfg command is called with no parameters. Scenarios like the above can be handled using the --path parameter. ___ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/2] blsuki: Add support for the XBOOTLDR partition
On Fri, 12 Dec 2025 at 11:11, Neal Gompa wrote: > > On Fri, Dec 12, 2025 at 4:02 AM Radoslav Kolev via Grub-devel > wrote: > > > > The default ESP partition on some systems is limited in > > space and storing a number of kernel and initrd images > > can fill it up quickly. > > > > It's not always practical to increase the size of the > > existing ESP, so the Boot Loader Spec defines a new Extended > > Boot Loader Partition (XBOOTLDR) with GPT type GUID of > > bc13c2ff-59e6-4262-a352-b275fd6f7172 to be searched for BLS > > enties and UKIs in addition to the ESP. > > > > Currently searching for this partition is based on the $root > > variable, but the spec requires for this partition to be on the same > > device as the ESP. In many cases that would be the case for $root, but > > there may be exceptions. After looking into it a bit I'm thinking it may be > > better in this case to select the device to search based on $cmdpath instead > > Please let me know your oppinion on this. > > > > More datails can be found at > > https://uapi-group.org/specifications/specs/boot_loader_specification/ > > > > Radoslav Kolev (2): > > blsuki: scan XBOOTLDR partition for BLS/UKIs if it exists > > blsuki: search default location on XBOOTLDR partition, even if entries > > found on ESP > > > > grub-core/commands/blsuki.c | 95 > > include/grub/gpt_partition.h | 7 +++ > > 2 files changed, 93 insertions(+), 9 deletions(-) > > > > -- > > 2.51.1 > > > > Would it be worth it to consider also searching the ROOT volume too > (in /boot/loader/entries) similarly to XBOOTLDR, especially in the > case where /boot is part of the main disk volume? No, as that is very explicitly against the specification, so it does not belong in the blsuki module. ___ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/2] blsuki: Add support for the XBOOTLDR partition
On Fri, 12 Dec 2025 at 09:01, Radoslav Kolev wrote: > > The default ESP partition on some systems is limited in > space and storing a number of kernel and initrd images > can fill it up quickly. > > It's not always practical to increase the size of the > existing ESP, so the Boot Loader Spec defines a new Extended > Boot Loader Partition (XBOOTLDR) with GPT type GUID of > bc13c2ff-59e6-4262-a352-b275fd6f7172 to be searched for BLS > enties and UKIs in addition to the ESP. > > Currently searching for this partition is based on the $root > variable, but the spec requires for this partition to be on the same > device as the ESP. In many cases that would be the case for $root, but > there may be exceptions. After looking into it a bit I'm thinking it may be > better in this case to select the device to search based on $cmdpath instead > Please let me know your oppinion on this. Yes it is extremely important to ensure the autodiscovered partition is on the same device as the ESP where the running bootloader was loaded from. Otherwise bad things can happen - for example, someone can plug in a usb disk and trick you into booting something that you never intended to. It's fundamental for autodiscovery not only in EFI mode, but in userspace later, so please ensure this restriction is respected. Thanks ___ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 0/2] blsuki: Add support for the XBOOTLDR partition
On Fri, Dec 12, 2025 at 4:02 AM Radoslav Kolev via Grub-devel wrote: > > The default ESP partition on some systems is limited in > space and storing a number of kernel and initrd images > can fill it up quickly. > > It's not always practical to increase the size of the > existing ESP, so the Boot Loader Spec defines a new Extended > Boot Loader Partition (XBOOTLDR) with GPT type GUID of > bc13c2ff-59e6-4262-a352-b275fd6f7172 to be searched for BLS > enties and UKIs in addition to the ESP. > > Currently searching for this partition is based on the $root > variable, but the spec requires for this partition to be on the same > device as the ESP. In many cases that would be the case for $root, but > there may be exceptions. After looking into it a bit I'm thinking it may be > better in this case to select the device to search based on $cmdpath instead > Please let me know your oppinion on this. > > More datails can be found at > https://uapi-group.org/specifications/specs/boot_loader_specification/ > > Radoslav Kolev (2): > blsuki: scan XBOOTLDR partition for BLS/UKIs if it exists > blsuki: search default location on XBOOTLDR partition, even if entries > found on ESP > > grub-core/commands/blsuki.c | 95 > include/grub/gpt_partition.h | 7 +++ > 2 files changed, 93 insertions(+), 9 deletions(-) > > -- > 2.51.1 > Would it be worth it to consider also searching the ROOT volume too (in /boot/loader/entries) similarly to XBOOTLDR, especially in the case where /boot is part of the main disk volume? This case exists in Fedora Cloud (F44+ as a Btrfs subvolume[1]), RHEL (RHEL10+ as a folder in the root XFS volume[2]), and SUSE distributions (where /boot is a folder in the root subvolume and contents of it are subvolumes[3]). It's now common enough that basic autodiscovery of those cases makes sense to be able to consider. [1]: https://fedoraproject.org/wiki/Changes/BtrfsBootForCloud [2]: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/new-features-and-enhancements#Jira-RHELDOCS-18902 [3]: https://rootco.de/2018-01-19-opensuse-btrfs-subvolumes/ -- 真実はいつも一つ！/ Always, there's only one truth! ___ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
