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 <mwhel...@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 <ro...@smidsrod.no>
>wrote:
>
>> On 23.12.2012 08:28, Joshua Oreman wrote:
>> > On Sat, Dec 22, 2012 at 11:19 PM, Matthew Helton
><mwhel...@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.
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
