All of lore.kernel.org
 help / color / mirror / Atom feed
* Boot from specified partition (or FS) UUID without knowing Device ID
@ 2022-02-18  7:01 Tom Hale
  2022-02-18 17:07 ` Tom Rini
  0 siblings, 1 reply; 5+ messages in thread
From: Tom Hale @ 2022-02-18  7:01 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Boot from specified partition (or FS) UUID without knowing Device ID
  2022-02-18  7:01 Boot from specified partition (or FS) UUID without knowing Device ID Tom Hale
@ 2022-02-18 17:07 ` Tom Rini
  2022-02-18 17:41   ` Heinrich Schuchardt
  0 siblings, 1 reply; 5+ messages in thread
From: Tom Rini @ 2022-02-18 17:07 UTC (permalink / raw)
  To: Tom Hale; +Cc: u-boot

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Boot from specified partition (or FS) UUID without knowing Device ID
  2022-02-18 17:07 ` Tom Rini
@ 2022-02-18 17:41   ` Heinrich Schuchardt
  2022-02-19  1:51     ` AKASHI Takahiro
  0 siblings, 1 reply; 5+ messages in thread
From: Heinrich Schuchardt @ 2022-02-18 17:41 UTC (permalink / raw)
  To: Tom Hale; +Cc: u-boot, AKASHI Takahiro, Ilias Apalodimas, Tom Rini

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.
>


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Boot from specified partition (or FS) UUID without knowing Device ID
  2022-02-18 17:41   ` Heinrich Schuchardt
@ 2022-02-19  1:51     ` AKASHI Takahiro
  2022-02-19  1:55       ` Heinrich Schuchardt
  0 siblings, 1 reply; 5+ messages in thread
From: AKASHI Takahiro @ 2022-02-19  1:51 UTC (permalink / raw)
  To: Heinrich Schuchardt; +Cc: Tom Hale, u-boot, Ilias Apalodimas, Tom Rini

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.
> > 
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Boot from specified partition (or FS) UUID without knowing Device ID
  2022-02-19  1:51     ` AKASHI Takahiro
@ 2022-02-19  1:55       ` Heinrich Schuchardt
  0 siblings, 0 replies; 5+ messages in thread
From: Heinrich Schuchardt @ 2022-02-19  1:55 UTC (permalink / raw)
  To: AKASHI Takahiro; +Cc: Tom Hale, u-boot, Ilias Apalodimas, Tom Rini

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.
>> > 
>> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-02-19  1:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-18  7:01 Boot from specified partition (or FS) UUID without knowing Device ID Tom Hale
2022-02-18 17:07 ` Tom Rini
2022-02-18 17:41   ` Heinrich Schuchardt
2022-02-19  1:51     ` AKASHI Takahiro
2022-02-19  1:55       ` Heinrich Schuchardt

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.