<div dir="ltr"><div>We've been using it in xCAT without much issue.  We pretty much now have UEFI and BIOS on equal footing for our Windows, ESXi, and Linux support.  We patched elilo to provide a bridge to execute linux kernels with iPXE capabilities when said kernel does not have a viable CONFIG_EFI_STUB facility.  We don't test distros older than Ubuntu 12.04, RHEL6, and SLES11, and I think RHEL5 explicitly didn't work for example.<br>
<br></div><div>I personally like the end result behavior enough to merrily recommend it over BIOS style boot (at least when you have some ipmi implementation to help override boot sequence at will).<br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Jul 7, 2014 at 1:44 PM, Ben Hildred <span dir="ltr"><<a href="mailto:42656e@gmail.com" target="_blank">42656e@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">I haven't become fully familiar with netbooting EFI which as far as i can tell looks great on paper, but has in several communities been dismissed with don't bother, too much work. I am trying to build a framework for netbooting everything (<a href="http://unboot.hildred.us/" target="_blank">http://unboot.hildred.us/</a>) and ipxe is a critical component in several architectures, and it appears that snponly.efi is also going to be critical for efi platforms, but I have limited resources for testing (a mac mini with a 32 bit processor).</div>

<div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Mon, Jul 7, 2014 at 11:16 AM, Jarrod Johnson <span dir="ltr"><<a href="mailto:jarrod.b.johnson@gmail.com" target="_blank">jarrod.b.johnson@gmail.com</a>></span> wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div dir="ltr"><div>Since I'm rebasing to recent iPXE, thought I'd take the opportunity to ask if there is general disinterest in snponly.efi?  Notably I see that I must continue to apply my dance to check loaded image for SNP when last_opened_snpdev finds nothing in efi_image.c and also have to revert "Disable SNP devices when running iPXE as the application"<br>


<br></div><div>I will confess to not fully understanding what f473b9c3f66a2166129e1f60774f56e673423c5a buys, but I'm presuming it is trying to suspend a 'factory' SNP implementation to avoid conflicting with iPXE when iPXE has a driver built in?  I really didn't read much more than the commit message since firmware development is still a bit too magical for my brain...<br>


</div><div><br></div><div><br></div></div>
<br></div>_______________________________________________<br>
ipxe-devel mailing list<br>
<a href="mailto:ipxe-devel@lists.ipxe.org" target="_blank">ipxe-devel@lists.ipxe.org</a><br>
<a href="https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel" target="_blank">https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>--</div><div><div>Ben Hildred</div><div>Automation Support Services</div></div><div><a href="tel:303%20815%206721" value="+13038156721" target="_blank">303 815 6721</a></div>

</font></span></div>
</blockquote></div><br></div>