Yes it does work with single efi image. Thanks and Regards, Niket Kandya, Graduate Student CS, Columbia University, NY
On Sun, Aug 25, 2013 at 4:13 PM, Jarrod Johnson <[email protected]>wrote: > 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
