[ipxe-devel] Relative interest in snponly.efi?
Jarrod Johnson
jarrod.b.johnson at gmail.com
Mon Jul 7 18:48:06 UTC 2014
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.
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).
On Mon, Jul 7, 2014 at 1:44 PM, Ben Hildred <42656e at gmail.com> wrote:
> 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 (http://unboot.hildred.us/) 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).
>
>
> On Mon, Jul 7, 2014 at 11:16 AM, Jarrod Johnson <
> jarrod.b.johnson at gmail.com> wrote:
>
>> 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"
>>
>> 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...
>>
>>
>>
>> _______________________________________________
>> ipxe-devel mailing list
>> ipxe-devel at lists.ipxe.org
>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>>
>>
>
>
> --
> --
> Ben Hildred
> Automation Support Services
> 303 815 6721
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20140707/5d026afb/attachment.htm>
More information about the ipxe-devel
mailing list