[syslinux] iPXE chain to lpxelinux.0 6.03 inconsistencies and failures

[Ady]

> On 15 Nov 2014 05:06:52 +0200, Ady wrote:
> >
> > I would start by updating the BIOS.
> 
> Prudent advice. As it turns out, I'm already at the latest version.
> 
> 
> On 15 Nov 2014 07:31:27 +0100, Geert Stappers wrote:
> >
> > And would reduce 'iPXE => pxe.0 => lpxelinux.0 => "vmlinux"'
> > into 'iPXE => "vmlinux"'
> 
> That makes sense generally, but at the moment doesn't make sense for my 
> particular circumstance.
> 
> I should clarify: I do not seek a workaround that eliminates iPXE or 
> eliminates lpxelinux.0; instead, since I have a test combination that 
> exposes a bug somewhere in iPXE or lpxelinux.0 (or both), I'd like to 
> use this opportunity to assist the developers in getting that fixed.
> 
> Any iPXE or lpxelinux.0 developers who want to make the code more 
> robust? What can I do to isolate the bug?
> 
> Thanks all,
> Alex
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> 

In last July you seemed to be successful with a similar Optiplex GX620 (see 
[1]).

The typical questions (after the one about the BIOS):

_ What about trying a cold boot?
_ Are you using official prebuilt binaries downlaoded from kernel.org?
_ Have you updated *all* Syslinux-related files (including ldlinux.c32)?
_ Have you tried resetting the BIOS to default settings, then rebooting and 
reconfiguring the BIOS again? And the NIC's ROM settings?

Let's see some of the components of your current setup:

_ ipxe
_ chainloading
_ lpxelinux
_ pxelinux-options
_ the specific built-in Broadcom (this seems to be already an identified issue)

Isolating each part could narrow down the problem. So, for example:

_ Is there some update available for the Broadcom that is not yet part of the 
main BIOS version?
_ Have you tested other settings, like intentionally using a different (fixed) 
Ethernet speed (10/100/1000)?
_ Do you happen to have some other system (even another Optiplex GX620) with 
the same (or as similar as possible) Broadcom? Is the same behavior seen in 
those similar systems?
_ Have you contacted Dell about this behavior in this particular system?

_ Is there some newer / testing version of ipxe / drivers so to test the whole 
process again?
_ Can you boot the same kernel from ipxe directly (without chainloading to 
lpxelinux.0)?
_ What happens if you change lpxelinux.0 and use pxelinux.0 instead?
_ Do you have some way to test the whole chain without using the 
'pxelinux-options' tool?
_ Do you have some way to test (l)pxelinux.0 on this system without ipxe?

I should quote one question that was just asked by Geert:
_ And what is visible with a network sniffer ( tcpdump, tshark, wireshark ) at 
the client?


Some of these questions are somewhat rhetorical, and a kind of trigger for you 
to isolate the problem.

For the cases with a potential slower transfer (e.g. pxelinux.0), you don't 
actually need to load the kernel; all you need is for ldlinux.c32 to 
successfully load and then a simple configuration file. Even before loading a 
kernel, if you get to the configuration file (e.g. show a Syslinux "boot:" 
prompt) then that's already a success in the current context.

Since the issue is seen on specific hardware, the only way to narrow down the 
source of the problem is by isolating each of the aforementioned parts of your 
process (and replicate the behavior). Although apparently the behavior is seen 
between lpxelinux.0 and ldlinux.c32, the culprit could be somewhere else too 
(e.g. NIC's ROM, some timer, some BIOS setting, some "energy-saving" thingy, 
faulty hardware...).

Please let us know of any updates.

Thank you,
Ady.

[1] http://www.syslinux.org/archives/2014-July/022487.html