Re: [RFC PATCH] ArmPkg: add driver to add distro installer HTTP boot options

[Laszlo Ersek <lersek@redhat.com>]

On 10/24/17 14:36, Leif Lindholm wrote:
> On Tue, Oct 24, 2017 at 02:10:44PM +0200, Laszlo Ersek wrote:
>> On 10/21/17 15:10, Ard Biesheuvel wrote:
>>> To make it easier for power users to provision a 'desktop' system [as
>>> opposed to a VM or server] from scratch, introduce a driver that adds
>>> boot options to the boot menu that can launch network installers over
>>> HTTP straight off the Internet.
>>>
>>> Currently, this only supports the 'mini.iso' style netboot installers
>>> that Debian/Ubuntu provide: larger images that need to be mounted by
>>> the installer when running under the Linux kernel are only supported
>>> on ACPI systems with support for the NFIT table, and this was enabled
>>> only recently (Linux v4.14) for arm64. For DT boot, there is currently
>>> no way at all to expose ramdisks created by UEFI as block devices in
>>> Linux.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> ---
>>>
>>> Posted as an RFC because:
>>> a) Where does this belong? Surely not in ArmPkg but I had to put it somewhere
>>> b) Currently, the way the options are created results in them taking priority
>>>    if no real boot options were set (i.e., for GRUB).
>>> c) Is there a use case for downloading 300-500 MB installers off the Internet
>>>    for a one shot installation? Or should we just stick to the mini.iso flavors.
>>> d) Did I miss any distros we may care about?
>>>
>>>  ArmPkg/Drivers/OsInstallerMenuDxe/OsInstallerMenuDxe.c   | 228 ++++++++++++++++++++
>>>  ArmPkg/Drivers/OsInstallerMenuDxe/OsInstallerMenuDxe.inf |  42 ++++
>>>  2 files changed, 270 insertions(+)
>>
>> https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot
>>
>> If the HTTP Boot stack is built into the firmware, it is possible to
>> navigate to:
>>
>>   Device Manager
>>     Network Device List
>>       MAC:xx:xx:xx:xx:xx:xx
>>         HTTP Boot Configuration
>>
>> On this dialog, we have
>> - "Input the description"
>> - "Internet protocol"
>> - "Boot URI"
>>
>> The help text says, "A new Boot Option will be created according to this
>> Boot URI".
>>
>> Therefore, I think the functionality already exists (for power users
>> that are willing to pick a NIC and to type a URL, anyway).
>>
>> Is the goal of your patch to provide more convenience, or to provide the
>> base functionality?
> 
> Convenience. And given that I only noticed yesterday that the boot
> fails on HTTP redirects, of somewhat restricted value.
> 
> Is that an official policy decision, or just a restriction of the
> implementation?

Hm, I'm unsure; the following seems to imply that HttpBootDxe intends to handle redirects:

        if (HttpBootIsHttpRedirectStatusCode (HttpMessage->Data.Response->StatusCode)) {
          //
          // Server indicates the resource has been redirected to a different URL
          // according to the section 6.4 of RFC7231 and the RFC 7538.
          // Display the redirect information on the screen.
          //
          HttpHeader = HttpFindHeader (
                 HttpMessage->HeaderCount,
                 HttpMessage->Headers,
                 HTTP_HEADER_LOCATION
                 );
          if (HttpHeader != NULL) {
            Print (L"\n  HTTP ERROR: Resource Redirected.\n  New Location: %a\n", HttpHeader->FieldValue);
          }

Can you perhaps capture a packet trace and discuss it with Siyuan and Jiaxin? Perhaps the server returns a status code that is not handled by HttpBootDxe right now.

Thanks
Laszlo

> 
>> Also, I think that creating baked-in boot options belongs with the
>> platform's PlatformBootManagerLib instance, not a separate UEFI_DRIVER
>> module. (That's where the UEFI shell boot option is created already, for
>> example.) Platform BDS is responsible for connecting NICs (none of them,
>> some of them, all of them -- and recursively or non-recursively), so if
>> you want to look at specific NIC-related protocol instances, you know
>> exactly when to look.
>>
>> If the goal is really to save the user the typing of one URL, then I
>> suggest to implement this feature as a small, standalone library, under
>> edk2-platforms; with a sole API called CreateOsInstallerBootOptions().
>>
>> Then, interested platforms may invoke CreateOsInstallerBootOptions() in
>> their PlatformBootManagerLib instances.
>>
>> (This would be similar to:
>>
>>   OvmfPkg/Include/Library/QemuBootOrderLib.h
>>   OvmfPkg/Library/QemuBootOrderLib/
>>
>> and how we call SetBootOrderFromQemu() in ArmVirtPkg's and OvmfPkg's
>> PlatformBootManagerLib instances.)
>>
>> Perhaps you can introduce the lib class, with a Null instance, in edk2
>> as well; and then call the new API in
>>
>>   ArmPkg/Library/PlatformBootManagerLib
>>
>> at the right spot. (I think adding the API / lib class to edk2 makes
>> sense, but I also think the lib instance with the actual URLs should
>> live under edk2-platforms, somewhere.)
>>
>> Just my two cents.
> 
> These were exactly the kinds of things I meant about "how best to
> implement" (without trying to answer them myself).
> 
> Regards,
> 
> Leif
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>