[ipxe-devel] [PATCH 0/4] Local UEFI disk boot support

[aaron.young at oracle.com]

  Note that I do have a new version of the code to add a volume label to 
the efimap output (suggestion #2 below), like so:


iPXE> efimap
Drive#  [Volume Label] Path
------  -------------------
0       [ANACONDA] 
PciRoot(0x0)/Pci(0x3,0x0)/HD(2,MBR,0x2E0E0369,0xBBC,0x3708)
1       [DATA DISK3] 
PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,F82F29A0-0A75-404F-B0D3-437753C70E75,0x800,0x64000)
2       [NO VOLUME LABEL] 
PciRoot(0x0)/Pci(0x6,0x0)/HD(1,GPT,F82F29A0-0A75-404F-B0D3-437753C70E75,0x800,0x64000)

And, I have confirmed that when the EFI_DEVICE_PATH_TO_TEXT_PROTOCOL is 
not present, the efimap output is like so:

iPXE> efimap
Drive#  [Volume Label] Path
------  -------------------
0       [ANACONDA] 
02010c00d041030a0000000001010600000304012a0002000000bc0b000000000000083700000000000069030e2e0000000000000000000000000101
1       [DATA DISK3] 
02010c00d041030a0000000001010600000404012a000100000000080000000000000040060000000000a0292ff8750a4f40b0d3437753c70e750202
2       [NO VOLUME LABEL] 
02010c00d041030a0000000001010600000504012a000100000000080000000000000040060000000000a0292ff8750a4f40b0d3437753c70e750202


   I could happily resubmit the patches with this new efimap Volume 
Label field if that would aid in acceptance.

   Thanks again,

   -Aaron

On 02/04/2019 11:49 AM, aaron.young at oracle.com wrote:
> Ping. Any response to below suggestions?
>
> Thanks,
>
>  -Aaron
>
> On 01/16/2019 10:54 AM, aaron.young at oracle.com wrote:
>>
>>
>> On 01/15/2019 06:23 AM, Michael Brown wrote:
>>> On 09/01/2019 19:35, Aaron Young wrote:
>>>> Example output of the efimap command is as follows:
>>>>
>>>> iPXE> efimap
>>>> Drive#    Path
>>>> ------    ----
>>>> 0 PciRoot(0x0)/Pci(0x3,0x0)/HD(2,MBR,0x2E0E0369,0xBBC,0x3708)
>>>> 1 PciRoot(0x0)/Pci(0x4,0x0)/HD(1,GPT,F82F29A0-...,0x800,0x64000)
>>>> 2 PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,F82F29A0-...,0x800,0x64000)
>>>> 3 PciRoot(0x0)/Pci(0x6,0x0)/HD(1,GPT,F82F29A0-...,0x800,0x64000)
>>>> 4 PciRoot(0x0)/Pci(0x7,0x0)/HD(1,GPT,F82F29A0-..,0x800,0x64000)
>>>
>>> It's reasonably common to have UEFI systems that do not provide 
>>> EFI_DEVICE_PATH_TO_TEXT_PROTOCOL, which is why efi_devpath_text() is 
>>> used only in DBG() statements.
>>>
>>> How is this feature expected to behave (both in terms of drive 
>>> ordering and in terms of efimap output) if the protocol is not 
>>> available?
>>>
>>> Thanks,
>>>
>>> Michael
>>
>>  Thanks for the review.
>>
>>  That's a good point. I didn't realize DEVICE_PATH_TO_TEXT protocol 
>> was commonly not provided (it's part of the UEFI spec - section 10.6).
>>
>>  Currently, the code (i.e. efi_devpath_text()), when there's no 
>> DEVICE_PATH_TO_TEXT protocol, will use a raw hex string as the text 
>> (via base16_encode()):
>>
>> <snip>
>>     /* If we have no DevicePathToText protocol then use a raw hex 
>> string */
>>     if ( ! efidpt ) {
>>         DBG ( "[No DevicePathToText]" );
>>         len = efi_devpath_len ( path );
>>         base16_encode ( path, len, text, sizeof ( text ) );
>>         return text;
>>     }
>> <\snip>
>>
>>
>>  So, the code still works, it just isn't very user friendly.
>>
>>  Do you have a suggestion on how to rectify this?
>>
>>  Seems we could either:
>>
>> 1. leave code as is - i.e. on systems with no provided protocol, they 
>> get ugly raw not-humanly-readable hex strings.
>> 2. Add a volume label field to the efimap output which may help in 
>> identifying/distinguishing the HDDs.
>> 3. Include DEVICE_PATH_TO_TEXT protocol implementation directly in 
>> iPXE (or a simplified version of it) for use when the protocol isn't 
>> available.
>>
>>  Do you have a preference?
>>
>>  Thanks,
>>
>>  -Aaron
>>
>>
>> _______________________________________________
>> ipxe-devel mailing list
>> ipxe-devel at lists.ipxe.org
>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel