On 06/24/13 16:53, Duane Voth wrote: > When Shell2 (ShellPkg) is started it records the ImageDevPath and > FileDevPath for itself for use in gEfiShellProtocol->Execute() (which > any other app is allowed to call to parse and execute a shell command > line). However 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? > Older shells didn't ASSERT and this made them usable as PXE payloads. > Shell2 can also be used as a PXE payload if the ASEERT is removed - all > shell functions work as intended except for Execute(). > > However, to get Execute() to work on a system where Shell2 is the PXE > Payload, a copy of the Shell.efi needs to be accessible locally (on a > volume that get's mapped one way or another while the boot shell is > executing), and then the boot shell must launch this second shell as > follows: > > fs0:\> Shell.efi -nomap -nostartup > UEFI Interactive Shell v2.0 UEFI v2.31 (EDKII, xxx). Revision 1.02 > fs0:\> > > This new prompt, running in a second shell, has ImageDevPath and > FileDevPath set correctly so Execute() can now be called from subsequent > apps. 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 But I *can* start "grubx64.efi", surprisingly. Does that involve Execute() too? The "shim.efi" symptoms don't change if I run a successful "ifconfig -s eth0 dhcp" first. > Likewise, I suspect that if the boot volume with shell.efi goes away > somehow, starting a second copy of the shell from a different volume may > avert some errors when Exexcute() is used by other apps. IIRC Andrew may have stated at one point that *some* shell is required at all times for fundamental UEFI functionality. What you're seeing could be per-design. (I only use Shell2 as PXE payload because PXE boot is easy to verify with it; my OVMF.fd usually embeds Shell1.) Laszlo ------------------------------------------------------------------------------ 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
