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