Out of curiosity, did it work without issue if you didn't have multiple efi executables in play?
I've not had a reason to try that use case myself, I just chain esxboot.efi (modified for iPXE DL protocol) or elilo (also modified for IPXE DL protocol support). I also had shell working with the simple filesystem support. I tried to get microsoft efi boot manager to work, but it seems eager to jump on the network aspect of a chained device. When I tried to start with a new device handle and put only simple file system support on it, it wasn't happy either. I have not had reason to bother with microsoft bootloader in the 'tftp wim down' case, so I don't know how that would go (without ipxe protocol support, skipping ipxe makes sense) On Sun, Aug 25, 2013 at 3:24 PM, Niket Kandya <[email protected]> wrote: > Hi, > > I was wondering if any of you guys ran into/worked around this problem. > > Following my previous query about UEFI image execution, > I enabled snponly.efi image execution, partly from Jarrod's patch and > partly my own. > > My addition there was: > If you try to run 2 efi images 1 after the other, the second image wont > execute because protocol installation will fail on the device handle as > protocols are already installed. So I added a check before installation in > efi_image_exec in efi_file_install and efi_download_install. And similarly > to uninstall only when it was installed for that image. > > To simulate this easily, you can just try autoboot from the shell as the > first command and then after you have reached the shell AGAIN!, chain your > normal efi image. > > However I ran into a wierd issue, after the autoboot, when i try to load > an efi image, the cwuri is changed to the one from previous autoboot. > > > Thanks and Regards, > Niket Kandya, > Graduate Student CS, > Columbia University, NY > > > On Wed, Aug 7, 2013 at 5:36 PM, Jarrod Johnson <[email protected] > > wrote: > >> If trying to use snponly.eif, the following two patches will help: >> >> https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/73d1ff05b058a2507fda0119825715fa2253d722 >> and >> >> https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/f411dcea1ce12ddcdfafa3fa2a89566a16f86bce >> >> I still have been meaning to make snponly.efi work from non chian booted >> scenarios (e.g. local vfat) but snponly.efi works fine with these two >> patches. >> >> Perhaps one day Michael will have spare time to double check my work, >> make sure I did it right, probably fudge it a tad, and merge it. In the >> meantime it's been working swimmingly for me. >> >> >> On Mon, Jul 29, 2013 at 5:20 PM, Niket Kandya <[email protected]>wrote: >> >>> >>> Hi, >>> >>> I was trying to chain boot an efi image. >>> My setup is all like traditional PXE with snponly.efi as the PXE file. >>> >>> While chainloading an EFI file, I always fail at last_opened_snpdev() as >>> it internally tries to find a PCI SNP device which it does not find. Is the >>> problem here itself ?? >>> >>> Or what I understood that this can be the case as this is a software >>> interface with no PCI address. To fix that I tried installing the protocols >>> onto a new handle (initially NULL) and then loading the image, however the >>> image never finds any files to read. So I tried doing this on the >>> efi_image_handle itself. And this failed again with none of these protocols >>> even being found on the device handle of the new image. I also tried using >>> any efi_pci_device, but none is found. >>> >>> Any suggestions?? >>> >>> Regards >>> >>> Thanks and Regards, >>> Niket Kandya, >>> >>> _______________________________________________ >>> ipxe-devel mailing list >>> [email protected] >>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel >>> >>> >> >
_______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
