[ipxe-devel] "Pre-embedding" a kernel within ipxe.pxe?

Robin Smidsrød robin at smidsrod.no
Sun Dec 23 19:38:34 UTC 2012


Wherever you're using undionly.kpxe or ipxe.pxe, replace it with ipxe.kpxe. Then try to chainload it from one of the machines that doesn't have a native iPXE driver. That should trigger using the UNDI driver. If DHCP works at that point and the iPXE shell command ifstat says an "UNDI" device is in use, success!



Matthew Helton <mwhelton at gmail.com> wrote:

>I've got a pretty good lab environment. Most of it is HP G7 equipment
>(C3000/7000 Blade centers and a bunch of DL380p Rack Servers), but I do
>have a fair amount of Cisco UCS, Dell, HP Gen8, IBM xSeries M4 and some
>whitebox platforms at my disposal. If you have some ideas, I'd really
>like
>to hear about them.
>
>Best,
>
>Matt
>
>
>
>On Sun, Dec 23, 2012 at 3:21 AM, Robin Smidsrød <robin at smidsrod.no>
>wrote:
>
>> On 23.12.2012 08:28, Joshua Oreman wrote:
>> > On Sat, Dec 22, 2012 at 11:19 PM, Matthew Helton
><mwhelton at gmail.com>
>> wrote:
>> >> The stray thought occured to me that instead of scripting
>> >> whitelists/blacklists by system model, or relying on external
>detection
>> >> methods (Syslinux or HDT) for NICs, could be ipxe.pxe be altered
>to
>> carry an
>> >> alternate kernel within itself?
>> >>
>> >> The concept would be that as part of the ipxe.pxe binary; it
>already has
>> >> undionly.kpxe embedded within it.
>> >>
>> >> That way, if we do a simple check to see if the native iPXE can
>detect a
>> >> NIC, and if it fails we have a way to back out of it.
>> >>
>> >> Example:
>> >>
>> >> isset ${net0/mac:hexhyp} && goto next || boot undionly.kpxe
>> >>
>> >> Am I insane?
>> >
>> > Sure, you can embed undionly.kpxe in ipxe.pxe in the same way you'd
>> > embed a script - but ipxe.pxe already includes all drivers
>including
>> > the UNDI driver. While I haven't tested it, I believe you should be
>> > able to build ipxe.kpxe and have it automatically use a native
>driver
>> > if one is available, an UNDI driver if not.
>>
>> I always thought that ipxe.kpxe was the particular build that
>exhibited
>> that behavior, but I have still not gotten it confirmed by anyone
>else.
>> And considering all my hardware has natively supported iPXE drivers,
>it
>> is a bit hard for me to verify.
>>
>> -- Robin
>>
>>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.



More information about the ipxe-devel mailing list