[ipxe-devel] Local UEFI disk boot support

[Geert Stappers]

On Tue, Feb 05, 2019 at 01:30:01PM -0800, aaron.young at oracle.com wrote:
> On 02/04/2019 11:49 AM, aaron.young at oracle.com wrote:
> > 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
> > > 
> > Ping. Any response to below suggestions?
> > 
> > Thanks,
> > 
> >  -Aaron
> > 
> 
>  Note that I do have a new version of the code to add a volume label to the
} efimap output (suggestion #2 above), 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.

Not submitting patches will surely not result in acceptance.

>   Thanks again,
> 
>   -Aaron
> 


Groeten
Geert Stappers
-- 
Leven en laten leven