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