On Mon, Jun 24, 2013 at 1:28 PM, Laszlo Ersek <[email protected]> wrote:
> On 06/24/13 16:53, Duane Voth wrote:
> > ... if the Shell is, for example, the payload for a PXE
> > boot, the call to GetDevicePathsForImageAndFile() in Shell.c fails
> > (because the shell.efi binary cannot be accessed locally) and the Shell
> > code ASSERTs.
>
> I just tested Shell2 as PXE payload (using the built-in edk2 PXE
> implementation) and it starts fine. (SVN r14442.)
>
> Were you testing Shell2 as PXE payload for the iPXE implementation?
>
In this case no, the shell.efi *is* my dhcp-named tftped-bootp payload.
(ya, iPXE as I recal provides a "simple file system: through which the
shell can be transported. efi binaries (like the shell) are embedded into
the ipxe payload so it all comes over in the initial bootp transfer)
> After PXE-booting Shell2 I can't start "shim.efi":
>
> FS0:\EFI\fedora\> shim.efi
> Fetching Netboot Image
> Unable to fetch TFTP image
> Fetching Netboot Image
> Unable to fetch TFTP image
>
This looks like some uefi device driver you have which provides a tftp
(readonly) "file system"?
> But I *can* start "grubx64.efi", surprisingly. Does that involve
> Execute() too?
>
If from a shell command line then yes. But where does grubx64.efi reside?
On a local hard disk? usb? flash?
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
