On Mo, 20.10.25 14:02, Demi Marie Obenour ([email protected]) wrote: > On 10/20/25 13:57, Andrei Borzenkov wrote: > > 20.10.2025 20:33, Demi Marie Obenour wrote: > >> On 10/19/25 11:36, Feli Flitzberg wrote: > >>> Hi, long time watcher, first time poster. If the bootloader supports the > >>> Discoverable Partitions Specification, all that's needed is the correct > >>> partition GUID assigned to every partition. After that, you don't need to > >>> pass any partitions or use /etc/fstab as the bootloader will read the > >>> disk it came from to mount everything. The only major limitation is that > >>> your bootloader partition MUST live on the same disk as root and usr, > >>> otherwise they won't be found. Hope this helps! > >> > >> How can the OS know which block device the system was booted from? > >> > > > > > > Bootloader compliant with BLI sets the LoaderDevicePartUUID EFI > > variable. Otherwise I assume it possible to get the current boot entry > > number from the BootCurrent EFI variable and parse the corresponding > > BootXXXX entry. > > Is this EFI variable the partition table UUID (which identifies a device) > or a partition UUID (which does not)?
LoaderDevicePartUUID reports the partition UUID of the ESP systemd-boot or systemd-stub first were invoked from. StubDevicePartUUID reports the partition UUID of the partition the UKI was invoked from (which is typically also the ESP, but could also be XBOOTLDR or in fact any oher partition). But note that the ESP/XBOOTLDR partition UUIDs should generally be understood to be as useful for identifying specific drives as the GPT partition table UUID, as the ESPs/XBOOTLDR have to be generated individually for each drive, as they are writable and recognzable by firmware, as they are referenced by firmware via their partition UUID too. Lennart -- Lennart Poettering, Berlin
