[ipxe-devel] UEFI efi_image_exec path

[Jarrod Johnson]

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 <niketkandya at gmail.com> 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 <jarrod.b.johnson at gmail.com
> > 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 <niketkandya at gmail.com>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
>>> ipxe-devel at lists.ipxe.org
>>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20130825/0a9cc1a1/attachment.htm>