Boot from specified partition (or FS) UUID without knowing Device ID
I want to have a fallback boot situation where boot is first tried from one partition, and then from another partition (on a different device) if the first partition isn't available (eg, if the first device fails).
Can I boot from a specific FS UUID or a partition UUID without knowing a particular device ID? (I'm not sure if my devices will always be detected in a repeatable order).
Can fatload be used with only a partition UUID? Or can I somehow get the dev number from the UUID?
Thanks in advance,
Tom
On Fri, Feb 18, 2022 at 02:01:41PM +0700, Tom Hale wrote:
I want to have a fallback boot situation where boot is first tried from one partition, and then from another partition (on a different device) if the first partition isn't available (eg, if the first device fails).
Can I boot from a specific FS UUID or a partition UUID without knowing a particular device ID? (I'm not sure if my devices will always be detected in a repeatable order).
Can fatload be used with only a partition UUID? Or can I somehow get the dev number from the UUID?
As UUIDs are unique per device but our device probe order is (nominally, there's counter examples) static, this would be a more board specific way of going than knowing which media is which device.
On 2/18/22 18:07, Tom Rini wrote:
On Fri, Feb 18, 2022 at 02:01:41PM +0700, Tom Hale wrote:
I want to have a fallback boot situation where boot is first tried from one partition, and then from another partition (on a different device) if the first partition isn't available (eg, if the first device fails).
Can I boot from a specific FS UUID or a partition UUID without knowing a particular device ID? (I'm not sure if my devices will always be detected in a repeatable order).
Can fatload be used with only a partition UUID? Or can I somehow get the dev number from the UUID?
The UEFI boot manager uses device paths which comprise the partition GUIDs. Currently we use the full device path.
Windows and efibootmgr just store the partition and the file path in boot options and non-U-Boot UEFI implementation will work fine with this. E.g.
HD(2,GPT,12345678-1234-5678-ABCD-123456789ABC,0x109000,0x32000)/File(\EFI\debian\shimx64.efi)
I think this approach should also be adopted for U-Boot when the file is on a GPT partition.
Would this solve your problem?
Best regards
Heinrich
As UUIDs are unique per device but our device probe order is (nominally, there's counter examples) static, this would be a more board specific way of going than knowing which media is which device.
On Fri, Feb 18, 2022 at 06:41:18PM +0100, Heinrich Schuchardt wrote:
On 2/18/22 18:07, Tom Rini wrote:
On Fri, Feb 18, 2022 at 02:01:41PM +0700, Tom Hale wrote:
I want to have a fallback boot situation where boot is first tried from one partition, and then from another partition (on a different device) if the first partition isn't available (eg, if the first device fails).
Can I boot from a specific FS UUID or a partition UUID without knowing a particular device ID? (I'm not sure if my devices will always be detected in a repeatable order).
Can fatload be used with only a partition UUID? Or can I somehow get the dev number from the UUID?
The UEFI boot manager uses device paths which comprise the partition GUIDs. Currently we use the full device path.
Windows and efibootmgr just store the partition and the file path in boot options and non-U-Boot UEFI implementation will work fine with
What do you mean by "efibootmgr"? It sounds to be the name of U-Boot's implementation of UEFI Boot Manager.
this. E.g.
HD(2,GPT,12345678-1234-5678-ABCD-123456789ABC,0x109000,0x32000)/File(\EFI\debian\shimx64.efi)
This is called a short path and already supported in U-Boot UEFI implementation. See efi_dp_find_obj().
I think this approach should also be adopted for U-Boot when the file is on a GPT partition.
To be clear, setting a device path in a boot option is not boot manager's responsibility, but efidebug's, at least for now. So even now, if efidebug is modified to allow for a short path, it should work with current "efibootmgr" (although I have never tried it before).
# FYI, the current implementation of creating a "full" device path from # U-Boot's probe mechanism/DM has a fatal problem of uniqueness. I have # mentioned the issue partially in my "removable media" support RFC but # will have to address it fully in the future.
-Takahiro Akashi
Would this solve your problem?
Best regards
Heinrich
As UUIDs are unique per device but our device probe order is (nominally, there's counter examples) static, this would be a more board specific way of going than knowing which media is which device.
Am 19. Februar 2022 02:51:10 MEZ schrieb AKASHI Takahiro takahiro.akashi@linaro.org:
On Fri, Feb 18, 2022 at 06:41:18PM +0100, Heinrich Schuchardt wrote:
On 2/18/22 18:07, Tom Rini wrote:
On Fri, Feb 18, 2022 at 02:01:41PM +0700, Tom Hale wrote:
I want to have a fallback boot situation where boot is first tried from one partition, and then from another partition (on a different device) if the first partition isn't available (eg, if the first device fails).
Can I boot from a specific FS UUID or a partition UUID without knowing a particular device ID? (I'm not sure if my devices will always be detected in a repeatable order).
Can fatload be used with only a partition UUID? Or can I somehow get the dev number from the UUID?
The UEFI boot manager uses device paths which comprise the partition GUIDs. Currently we use the full device path.
Windows and efibootmgr just store the partition and the file path in boot options and non-U-Boot UEFI implementation will work fine with
What do you mean by "efibootmgr"?
It is the Linux program used to set boot options.
https://manpages.ubuntu.com/manpages/xenial/man8/efibootmgr.8.html
Best regards
Heinrich
It sounds to be the name of U-Boot's implementation of UEFI Boot Manager.
this. E.g.
HD(2,GPT,12345678-1234-5678-ABCD-123456789ABC,0x109000,0x32000)/File(\EFI\debian\shimx64.efi)
This is called a short path and already supported in U-Boot UEFI implementation. See efi_dp_find_obj().
I think this approach should also be adopted for U-Boot when the file is on a GPT partition.
To be clear, setting a device path in a boot option is not boot manager's responsibility, but efidebug's, at least for now. So even now, if efidebug is modified to allow for a short path, it should work with current "efibootmgr" (although I have never tried it before).
# FYI, the current implementation of creating a "full" device path from # U-Boot's probe mechanism/DM has a fatal problem of uniqueness. I have # mentioned the issue partially in my "removable media" support RFC but # will have to address it fully in the future.
-Takahiro Akashi
Would this solve your problem?
Best regards
Heinrich
As UUIDs are unique per device but our device probe order is (nominally, there's counter examples) static, this would be a more board specific way of going than knowing which media is which device.
participants (4)
-
AKASHI Takahiro -
Heinrich Schuchardt -
Tom Hale -
Tom Rini