Syslinux - Sep 2015 - Chaining to pxelinux.0 6.0.3 from iPXE - ldlinux.c32

On 9/23/2015 2:08 PM, Ady via Syslinux wrote:
> Even if it still hangs with this test, does it hang exactly as before 
> (i.e. shows only one character and hangs immediately)?
It happens with one entry, or two entries, or three.
The configuration  works otherwise perfectly on any other environment.

If I simplify to the the following, it still hangs after outputting the
one visible character:

SERIAL 0
default menu.c32

label bootlocal
  localboot 0

label discovery
  kernel util/vmlinuz
  append boot=live netboot=http fetch=http://10.22.165.41/iso/util.iso
ip=dhcp initrd=::util/initrd.img

All this works OK on the menu.c32 in 6.x.  I'm just stuck, since I can't
upgrade because ipxe chainloading won't work in 6.x.  If I could resolve
either way, I'm good.   It's looking like my only fallback position is
go with 6.x and abandon ipxe support...

> On 9/23/2015 2:08 PM, Ady via Syslinux wrote:
> 
> > Even if it still hangs with this test, does it hang exactly as before 
> > (i.e. shows only one character and hangs immediately)?
> 
> It happens with one entry, or two entries, or three.
> The configuration  works otherwise perfectly on any other environment.
> 
> If I simplify to the the following, it still hangs after outputting the
> one visible character:
> 
> SERIAL 0
> default menu.c32
> 
> label bootlocal
>   localboot 0
> 
> label discovery
>   kernel util/vmlinuz
>   append boot=live netboot=http fetch=http://10.22.165.41/iso/util.iso
> ip=dhcp initrd=::util/initrd.img
> 
> All this works OK on the menu.c32 in 6.x.  I'm just stuck, since I
can't
> upgrade because ipxe chainloading won't work in 6.x.  If I could
resolve
> either way, I'm good.   It's looking like my only fallback position
is
> go with 6.x and abandon ipxe support...
> 
 
My guess would be that Gene and others (myself included) would be 
interested in solving the ldlinux.c32 issue more than anything else 
(next-server?, proxy?, setting off other nics?, ...).

Regarding some fallback method, you could use PROMPT 1, several SAY 
lines, and/or a DISPLAY file, and moving the menu.c32 option from 
DEFAULT to a LABEL. That would at least provide the option to avoid 
loading menu.c32, and using labels from the CLI (together with TIMEOUT, 
the ENTER key, F1-F12 keys, ONTIMEOUT...) for those having some issue 
with menu.c32. The other users, not having problems with menu.c32, 
would be able to load the menu as option, depending on the directives 
and their own action (or by timer).

Regarding ipxe, I would suggest asking in its mailing list, instead of 
assuming anything.

Unfortunately, the KVM issues, plus multiple nics, plus some specific 
hardware / firmware having problems (that cannot always be replicated 
under other environments), plus ipxe chaining, make the potential 
narrow down of the issues not so easy. PXELINUX might have its own 
issues with each of them, independent of this case, combining all of 
them.

BTW, I have read some posts in the HP support forum about some HP 
servers working correctly with manual setup / commands, but failing 
when doing it by some equivalent "automatic" method. Also, the
firmware
updates (whether for the main "BIOS" or for a network card) seem to be
very relevant.

Regards,
Ady.
 
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>

On 9/23/2015 3:32 PM, Ady via Syslinux wrote:
> 
>> On 9/23/2015 2:08 PM, Ady via Syslinux wrote:
>>
>>> Even if it still hangs with this test, does it hang exactly as
before
>>> (i.e. shows only one character and hangs immediately)?
>>
>> It happens with one entry, or two entries, or three.
>> The configuration  works otherwise perfectly on any other environment.
>>
>> If I simplify to the the following, it still hangs after outputting the
>> one visible character:
>>
>> SERIAL 0
>> default menu.c32
>>
>> label bootlocal
>>   localboot 0
>>
>> label discovery
>>   kernel util/vmlinuz
>>   append boot=live netboot=http fetch=http://10.22.165.41/iso/util.iso
>> ip=dhcp initrd=::util/initrd.img
>>
>> All this works OK on the menu.c32 in 6.x.  I'm just stuck, since I
can't
>> upgrade because ipxe chainloading won't work in 6.x.  If I could
resolve
>> either way, I'm good.   It's looking like my only fallback
position is
>> go with 6.x and abandon ipxe support...
>>
>  
> My guess would be that Gene and others (myself included) would be 
> interested in solving the ldlinux.c32 issue more than anything else 
> (next-server?, proxy?, setting off other nics?, ...).
I'd be completely thrilled to help debug, if you can advise what I can
do to help.   Unfortunately been 30+ years since I read ASM code, so a
little lost in there.

Is there any possibility under ipxe that pxelinux unloads UNDI support
prematurely, therefore shooting itself in the foot before it can try to
load ldlinux.c32?   Almost what it looks like, it throws the error
instantly, with no apparent attempt to hit the network.
> 
> Regarding some fallback method, you could use PROMPT 1, several SAY 
> lines, and/or a DISPLAY file, and moving the menu.c32 option from 
> DEFAULT to a LABEL. That would at least provide the option to avoid 
> loading menu.c32, and using labels from the CLI (together with TIMEOUT, 
> the ENTER key, F1-F12 keys, ONTIMEOUT...) for those having some issue 
> with menu.c32. The other users, not having problems with menu.c32, 
> would be able to load the menu as option, depending on the directives 
> and their own action (or by timer).
> 
Yeah... or abandon ipxe and use TFTP.  At least 6.0.3 works for that...
> Regarding ipxe, I would suggest asking in its mailing list, instead of 
> assuming anything.
I've referred to the iPXE mailing list... for quite some time, there has
been a quandry there why chaining to pxelinux 6.x fails due to the
ldlinux load fail.   No one there knows how to solve it, and has not
been able to find a solution.
> BTW, I have read some posts in the HP support forum about some HP 
> servers working correctly with manual setup / commands, but failing 
> when doing it by some equivalent "automatic" method. Also, the
firmware
> updates (whether for the main "BIOS" or for a network card) seem
to be
> very relevant.
Except, as I've noted - it's not specific to HP.   It fails generally.
And the only variable, FWIW, is the pxelinux version... same firmware in
play for pxelinux 4.x vs. 6.x...