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 < [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 -- James A. Peltier Manager, IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : [email protected] 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
_______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
