[ipxe-devel] UEFI efi_image_exec path

James A. Peltier jpeltier at sfu.ca
Tue Sep 17 21:44:55 UTC 2013


Can I please see an example of how you are chaining these together. I have yet to get iPXE to be able to chainload an EFI image for CentOS or any other OS for that matter 

----- Original Message -----

| 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
| | | 
| | 
| 

| _______________________________________________
| ipxe-devel mailing list
| ipxe-devel at lists.ipxe.org
| https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

-- 

James A. Peltier 
Manager, IT Services - Research Computing Group 
Simon Fraser University - Burnaby Campus 
Phone : 778-782-6573 
Fax : 778-782-3045 
E-Mail : jpeltier at sfu.ca 
Website : http://www.sfu.ca/itservices 

“A successful person is one who can lay a solid foundation from the bricks others have thrown at them.” -David Brinkley via Luke Shaw 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20130917/19cb9e85/attachment.htm>


More information about the ipxe-devel mailing list