Re: [PATCH] efi/libstub: populate LoaderDevicePartUUID

Hi Ard,

This is a resend of:

  https://lore.kernel.org/all/[email protected]/

My SMTP server detected your message as spam and prefixed the message
subject with:

  *** SPAM ***

And this stayed in the subject of my reply. Now, I am worried that you
may not have gotten it because of that, thus this resend.

Aside from the fixed email subject, this is the same message.

On 01/08/2026 at 15:47, Ard Biesheuvel wrote:
> Hi Vincent,
> 
> On Sat, 25 Jul 2026, at 01:11, Vincent Mailhol wrote:
>> The Boot Loader Interface [1] defines LoaderDevicePartUUID. That
>> variable contains the GPT partition UUID of the device path from which
>> the boot loader was loaded.
>>
>> This is used for example by systemd-gpt-auto-generator [2] to identify
>> the disk the boot loader was launched from and automatically detect and
>> mount partitions on it.
>>
>> GRUB populates it [3], but most EFI firmware implementations do not.
>> Because of that, the variable is missing when booting the kernel from
>> the EFI stub.
>>
>> Read the loaded image device path, extract the GUID signature from its
>> GPT HD() device path node and publish it as LoaderDevicePartUUID under
>> the Linux loader entry vendor GUID. Do not overwrite an existing
>> variable, so a boot loader supplied value keeps precedence.
>>
>> Use a volatile variable with boot-service and runtime access so the
>> value remains available to user space services such as systemd, without
>> persisting stale boot state across resets.
>>
>> Install the efi_bli_set_variables() hook in both the generic efi-stub.c
>> path and the x86-specific x86-stub.c path.
>>
>> [1] The Boot Loader Interface
>> Link: https://systemd.io/BOOT_LOADER_INTERFACE/
>>
>> [2] systemd-gpt-auto-generator
>> Link: 
>> https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
>>
>> [3] GRUB -- §16.2 bli
>> Link: 
>> https://www.gnu.org/software/grub/manual/grub/html_node/bli_005fmodule.html
>>
>> Signed-off-by: Vincent Mailhol <[email protected]>
>> ---
>> Here is a bit of extra context around this patch. I recently installed
>> coreboot on my machine with edk2 as the payload. After booting the
>> kernel directly from the EFI stub instead of booting it from GRUB, I
>> noticed that some partitions which were previously mounted automatically
>> were not mounted anymore.
>>
>> Upon investigation, I found that those partitions were mounted
>> automatically using DPS [4]. DPS needs the LoaderDevicePartUUID EFI
>> variable, which was set by GRUB but not by edk2.
>>
>> I first proposed a series to add that variable in edk2 [5]. The change
>> was not well received because BLI is perceived as too specific to Linux
>> systems. Upon reflection, I concluded that the kernel EFI stub is the
>> best location to implement it because it resolves the problem for EFI
>> firmware implementations in one place.
>>
> 
> So it is the bootloader that sets this variable, and you want to boot
> without a bootloader, right?

Kind of.

In my view, when booting through the EFI stub, the EFI stub becomes the
boot loader. I can also quote Documentation/admin-guide/efi-stub.rst:

  Since the EFI boot stub performs the jobs of a boot loader, in a
  certain sense it IS the boot loader.

which supports that idea.
 
> What about systemd-boot, does it set this variable?

Yes, it sets it in its efi_main().

Link: https://github.com/ivandavidov/systemd-boot/blob/master/project/src/sd-boot/boot.c#L1760-L1762

But IMHO, using systemd-boot kind of defeats the purpose of directly
booting the kernel from its EFI stub.

 
Yours sincerely,
Vincent Mailhol