[syslinux] Problem with Symantec's UNDI driver and PXELINUX

[Brian H. Nelson]

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 
fail to/
 >/ initialise, ignore the loaded stack and try to load a new one from 
ROM. /
 >/ There is *no* clean way to tell whether or not a PXE stack is 
running or/
 >/ not; the API call for "get current state" has the same number as the 
API/
 >/ 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...
>
> 	-hpa
>   

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. :-)

Thanks,
-Brian

-- 
---------------------------------------------------
Brian H. Nelson         Youngstown State University
System Administrator   Media and Academic Computing
              bnelson[at]cis.ysu.edu
---------------------------------------------------