<div dir="ltr"><div>Ok, so I have a patch.  It is a terrible patch, but it demonstrates roughly how to restore snponly capability.  My patch is horrible because it explicitly breaks the efforts to do efipci, but I thought it would be best to have code to backup how I suggest it be done.  In short, just efi_image.c should change.<br>
<br>Basically, efi_image.c should go ahead and try the last_opened_snpdev. If that works, put its devpath and handle into some variables.  If that should not work, do the same thing snpbus_probe does (check loaded image for SNP protocol).  If loaded_image has an SNP, then store the relevant devpath and handle into the aforementioned variables to add the relevant slick IPXE protocols to it and pass it through (slick ones being the download and exceptionally cool filesystem one, which I confirmed will work snponly with this strategy).  Ignore the irrevelant ones (HII, Loadfile, etc) which only have sane meaning when part of efirom or efidrv.<br>
<br></div>This patch commits the sin of skipping the check and bludgeoning things the snponly way.   The part about switching between snpdev and snponly and still failing is straightforward, but I didn't take the time (will take the time if no one else does).  I'dd also make the bludgeoning of the DeviceHandle optional (though I don't claim to quite understand why I must do it).<br>
<div><br></div><div>I put the patch into xCAT's repository under a branch for posterity:<br><a href="https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/19447d9c39e06c3d5aabd198736cd23d8e40c870">https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/19447d9c39e06c3d5aabd198736cd23d8e40c870</a><br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 11, 2013 at 11:40 PM, Jarrod Johnson <span dir="ltr"><<a href="mailto:jarrod.b.johnson@gmail.com" target="_blank">jarrod.b.johnson@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">><span style="font-family:arial,sans-serif;font-size:13px"> Some care would need to be taken to avoid</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> recursion.</span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div><span style="font-family:arial,sans-serif;font-size:13px">On this, I think the correct answer would be for the IPXE protocols, check and uninstall if already there prior to installing new instance of the protocol. No new device handle needed, just replace the relevant protocols and leave any ohter protocols alone, therefore no risk of too much recursion (yes, snponly.efi would rip out bits of ipxe when chained from an already ipxe capable device, but that would be expected behavior as presumably the chainloaded instance is customized and/or better tested for that environment compared to flashed instance...)</span></div>

</div>
</blockquote></div><br></div></div>