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

[aaron.young at oracle.com]

  Ping?


On 03/07/2019 07:41 AM, aaron.young at oracle.com wrote:
>
>  Ping.
>
>  This patch has been in the queue for a month with no review/response.
>
>  Is there anyone doing patch reviews on this list?
>
>  Thanks,
>
>  -Aaron
>
>
> On 02/05/2019 04:47 PM, Aaron Young wrote:
>> This patch series adds support to boot a locally attached
>> UEFI disk. The disk must installed with a EFI System Partition
>> and filesystem.
>>
>> This improves upon the current solution to boot a local UEFI
>> disk from iPXE - which requires one to exit out of iPXE to fallback
>> into the EFI boot manager. This solution allows iPXE to boot a
>> UEFI disk directly and stay in control if the boot fails.
>>
>> Example syntax to boot a local UEFI disk:
>>
>>> sanboot --no-describe --drive 0 --filename \EFI\redhat\grubx64.efi
>> This syntax is very similar and consistent with the
>> syntax currently used to boot a local legacy HDD, i.e.:
>>
>>> sanboot --no-describe --drive 0x80
>> The extra --filename argument is required for UEFI as the UEFI
>> spec allows the bootloader to be located in non-standard
>> locations on the disk. The --filename is optional and if omitted,
>> the standard spec defined default filepath will be used, e.g.
>> \EFI\BOOT\BOOTX64.efi on x86_64.
>>
>> This patch series also includes a new efimap command which
>> displays a map of all locally attached UEFI filesystems.
>> Example output of the efimap command is as follows:
>>
>> iPXE> efimap
>> Drive#  [Volume Label] Path
>> ------  -------------------
>> 0       [ORACLE LINUX] 
>> PciRoot(0x0)/Pci(0x3,0x0)/HD(2,MBR,0x2E0E0369,0xBBC,0x3708)
>> 1       [DATA DISK3] 
>> PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,F82F29A0-...,0x800,0x64000)
>> 2       [NO VOLUME LABEL] 
>> PciRoot(0x0)/Pci(0x6,0x0)/HD(1,GPT,F82F29A0-...,0x64000)
>>
>> Note that in the event that the UEFI EFI_DEVICE_PATH_TO_TEXT protocol is
>> not implemented on a system, the output of the efimap will contain a hex
>> string dump of the device path, like so:
>>
>> iPXE> efimap
>> Drive#  [Volume Label] Path
>> ------  -------------------
>> 0       [ORACLE LINUX] 02010c00d041030a0000000001010600000304012a0002...
>> 1       [DATA DISK3] 02010c00d041030a0000000001010600000404012a000100...
>> 2       [NO VOLUME LABEL] 02010c00d041030a0000000001010600000504012a0...
>>
>> The drive# from the efimap command can be passed as an argument to the
>> sanboot command --drive option to specify which disk/filesystem to boot.
>>
>> Note that the mappings are sorted by device path which gives a
>> PCI BDF ordering as the device paths typically begin with
>> PciRoot()/Pci() nodes. This sorting will help to give a consistent
>> mapping between boots.
>>
>> Testing:
>> This patchset was testing in a virtual/cloud environment with QEMU
>> attached PV disks and also on a baremetal system.
>>
>> v2 Changes:
>>      - Removed 1st (strcmp/strncmp fix) patch from original series 
>> since it was pulled.
>>      - Improved efimap output to include the Volume Label (if 
>> present) to
>>        aid in identifying boot drives/filesystems.
>>
>> Aaron Young (3):
>>    Implement scaffolding for new efimap command.
>>    Call efi_boot_local() from efi_block_boot()
>>    Complete implementation of efi_boot.c
>>
>>   src/config/config_efi.c       |   8 +
>>   src/config/general.h          |   1 +
>>   src/hci/commands/efimap_cmd.c |  77 +++++++
>>   src/include/usr/efiboot.h     |  15 ++
>>   src/interface/efi/efi_block.c |   8 +-
>>   src/interface/efi/efi_boot.c  | 475 
>> ++++++++++++++++++++++++++++++++++++++++++
>>   6 files changed, 583 insertions(+), 1 deletion(-)
>>   create mode 100644 src/hci/commands/efimap_cmd.c
>>   create mode 100644 src/include/usr/efiboot.h
>>   create mode 100644 src/interface/efi/efi_boot.c
>>
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel