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

[Matthew Helton]

Quite a few people have experienced the "Try to free Memory without
Signature" error when using ipxe.pxe. If there isn't a native driver loaded
which works, you have ~at best~, a machine which can only reboot into the
same environment over and over. Most of the time, you have a hung machine
with that error message.

This is why I would like to see an alternative undionly kernel placed in
memory as escape mechanism if the ipxe.pxe kernel cannot find a Natively
driven NIC.


On Sun, Dec 23, 2012 at 1:28 AM, Joshua Oreman <oremanj at mit.edu> 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.
>
> Josh
>
> >
> > Matt
> > --
> > There is never time enough to do it right, but there always seems to be
> > enough time to do it again.
> >
> > _______________________________________________
> > ipxe-devel mailing list
> > ipxe-devel at lists.ipxe.org
> > https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
> >
>



-- 
There is never time enough to do it right, but there always seems to be
enough time to do it again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20121223/99d0adfb/attachment.htm>