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

[H. Peter Anvin]

Brian H. Nelson wrote:
> 
> 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.
> 

I have heard that claim before (gPXE has a mode like this too, and I 
think emBoot has made this claim, too) and I've still not seen it work 
with universally in cases where the NIC is not a physically separate 
card (in which case it's relatively straightforward.)  The LOM case is 
highly problematic, in particular.

You didn't say if you had a discrete NIC in your test setup.  If you do, 
then this is a bigger concern to me.

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

Very likely.

> 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*

Indeed.  It is one of many design flaws in PXE.  However, when used with 
"keeppxe" PXELINUX does take relative care at returning the stack to the 
state it found it -- in other words, it returns the stack to the only 
available standardized state, which is the one immediately upon NBP 
initialization.

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

Sorry for the snide remark, it was more an expression of frustration. 
Isn't it funny how commercial software is assumed to not even bother 
standing by their product when used not exactly the way they want to, 
whereas free software...

I did want you do understand what you're asking of me: you're asking for 
help with a commercial piece of software which I have never even heard 
of and don't have access to, which attempts to do something that the 
specifications doesn't support.  *Anything* could have changed the way 
it behaves, including bugfixes!  There are 184 changes from 3.63 to 
3.70, and just plain guessing is going to be pointless.

If you really want to track this down, then the best way would be to do 
a "git bisect" to track it down to a specific commit, and the 
second-best way would be to at least narrow it down to a specific 
Testing release.

 > As the 'keeppxe' option seems to work fine, I'm happy to use that from
 > now on as the solution to my problem. :-)

Excellent :)  That is the Right Thing to do.

	-hpa