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 <[email protected]>
>>> ---
>>>
>>> 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
> [email protected]
> https://lists.01.org/mailman/listinfo/edk2-devel
>
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
