Re: [systemd-devel] With UEFI secure boot and dm-verity, how does one find the user data partition?
On 10/20/25 14:20, Andrei Borzenkov wrote:
20.10.2025 21:02, Demi Marie Obenour 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)?
It is what is printed by lsblk as partuuid.
Unfortunately this isn't what is needed. Looks like UEFI variable storage is the best option. -- Sincerely, Demi Marie Obenour (she/her/hers)
20.10.2025 21:22, Demi Marie Obenour wrote:
On 10/20/25 14:20, Andrei Borzenkov wrote:
20.10.2025 21:02, Demi Marie Obenour 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)?
It is what is printed by lsblk as partuuid.
Unfortunately this isn't what is needed. Looks like UEFI variable storage is the best option.
Partition UUID is (supposed to be) unique for every partition, so it most certainly allows one to identify the device to which it belongs.
On 10/20/25 15:10, Andrei Borzenkov wrote:
20.10.2025 21:22, Demi Marie Obenour wrote:
On 10/20/25 14:20, Andrei Borzenkov wrote:
20.10.2025 21:02, Demi Marie Obenour 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)?
It is what is printed by lsblk as partuuid.
Unfortunately this isn't what is needed. Looks like UEFI variable storage is the best option.
Partition UUID is (supposed to be) unique for every partition, so it most certainly allows one to identify the device to which it belongs.
I mixed up partition UUID and partition *type* UUID. What is the best way to use it? The most obvious one requires that whenever a block device appears, one checks if either: - This has the correct partition UUID, and a device with the same diskseq and the correct partition type UUID has appeared. - This has the correct partition type UUID, and a device with the same diskseq and the correct partition UUID has appeared. Is there a simpler option? -- Sincerely, Demi Marie Obenour (she/her/hers)
On Mo, 20.10.25 15:45, Demi Marie Obenour (demiobenour@gmail.com) wrote:
Unfortunately this isn't what is needed. Looks like UEFI variable storage is the best option.
Partition UUID is (supposed to be) unique for every partition, so it most certainly allows one to identify the device to which it belongs.
I mixed up partition UUID and partition *type* UUID.
What is the best way to use it? The most obvious one requires that whenever a block device appears, one checks if either:
- This has the correct partition UUID, and a device with the same diskseq and the correct partition type UUID has appeared. - This has the correct partition type UUID, and a device with the same diskseq and the correct partition UUID has appeared.
Is there a simpler option?
The {Loader,Stub}DevicePartUUID efi var is passed in from the firmware, which has no concept of a diskseq, hence it's purely a uuid. systemd v258 and newer make the ESP booted from available via /dev/disk/by-designator/esp and XBOOTLDR as /dev/disk/by-designator/xbootldr as symlinks. Lennart -- Lennart Poettering, Berlin
participants (3)
-
Andrei Borzenkov -
Demi Marie Obenour -
Lennart Poettering