[syslinux] Problem with Symantec's UNDI driver and PXELINUX
Brian H. Nelson
bnelson at cis.ysu.edu
Thu Jan 22 10:12:04 PST 2009
H. Peter Anvin wrote:
> I don't know what they do, but there definitely isn't a guaranteed way
> to load the UNDI driver once it has been removed from memory. There are
> systems where it can be made to work, but it is definitely nothing that
> is guaranteed.
> I know some of those systems rely on the UNDI stack still being present
> in memory, for example; others will try to read it out of the PCI ROM
> (which doesn't work for LOM or non-PCI systems.)
From what I can guess, the Symantec driver loads the PXE and/or UNDI
stack into memory. I presume that it gets that software from the NIC
eeprom? The disk image I'm using is designed to be physically booted
from floppy. The disk loads this UNDI driver, then a packet driver on
top of that, with which ghost uses for TCP/IP connectivity. They
consider this to be 'universal' for any PXE-able network card.
> Status code 0xc5 is PXENV_STATUS_LOADER_BAD_UNDI_ROMID, which implies
> that it is trying to reinitialize UNDI from ROM somehow and failing.
> Using the keeppxe option is the right way to do this kind of stuff;
> without knowing exactly what the Symantec driver is trying to do I have
> absolutely no idea how even begin to approach this.
The keeppxe option does seem to accomplish the same thing. When using
that option, the undi_drv.exe then reports that "UNDI driver already
installed!". I will be using keeppxe from here on out until I run into
another problem. I'm still curious what changed in pxelinux 3.70 that
broke my original setup though. My suspicion is that pxelinux 3.70+ is
leaving the machine is a slightly different state than previous versions
when it passes control over to memdisk.
The only interesting thing I found on Google was this:
>/ You can happily unload the PXE stack; the UNDI driver will simply /
>/ reinstall it from the UNDI ROM. It searches for a PXE stack in memory /
>/ before looking for ROMs, so a loaded PXE stack should work./
>/ If the PXE stack has been left in a "running" state then it will
>/ initialise, ignore the loaded stack and try to load a new one from
>/ There is *no* clean way to tell whether or not a PXE stack is
>/ not; the API call for "get current state" has the same number as the
>/ call for "shutdown stack"...
/From here http://osdir.com/ml/network.etherboot.devel/2003-05/msg00032.html
I realize that it's about a completely different subject, but does seem
related to this issue. *shrug*
> I also note that you're asking here rather than asking Symantec...
Yes well, I don't imagine that Symantec would be in a hurry to help me
out with pxelinux (read: they won't support pxelinux). I reported the
issue to this list mainly as a courtesy to you. Whatever the cause, it
definitely seems to be something that changed in pxelinux itself. Now,
weather that is indicative of an actual problem/bug or it's working as
intended is beyond me, but it struck me as strange when it no longer
worked as it had in previous versions.
As the 'keeppxe' option seems to work fine, I'm happy to use that from
now on as the solution to my problem. :-)
Brian H. Nelson Youngstown State University
System Administrator Media and Academic Computing
More information about the Syslinux