From: "Ard Biesheuvel" <ardb@kernel.org>
To: "Vincent Mailhol" <mailhol@kernel.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org
Subject: Re: [PATCH] efi/libstub: populate LoaderDevicePartUUID
Date: Sat, 01 Aug 2026 15:47:14 +0200 [thread overview]
Message-ID: <0aad56b5-a650-49c6-a193-db65c4c4395e@app.fastmail.com> (raw)
In-Reply-To: <20260725-efi_stub_bli-v1-1-966e4748077f@kernel.org>
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 <mailhol@kernel.org>
> ---
> 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?
What about systemd-boot, does it set this variable?
next prev parent reply other threads:[~2026-08-01 13:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 23:11 [PATCH] efi/libstub: populate LoaderDevicePartUUID Vincent Mailhol
2026-08-01 13:47 ` Ard Biesheuvel [this message]
2026-08-01 22:23 ` *** SPAM *** " Vincent Mailhol
2026-08-04 20:05 ` Vincent Mailhol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0aad56b5-a650-49c6-a193-db65c4c4395e@app.fastmail.com \
--to=ardb@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.