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? > 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
