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

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

On Wed, Sep 23, 2015 at 5:43 PM, Alan Sparks via Syslinux
<syslinux at zytor.com> wrote:
> On 9/23/2015 3:32 PM, Ady via Syslinux wrote:
>>
>>> On 9/23/2015 2:08 PM, Ady via Syslinux wrote:
>>> 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...
Although it means another round of testing, you could also consider
lpxelinux.0 which can support HTTP URLs on its own and probably
interacts differently with iPXE.  I am curious about a quantifiable
description of "an odd delay".
>> 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?, ...).
Agreed.  It's a regression affecting critical functionality (loading
ldlinux.c32) of a core variant (pxelinux.0).
> 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.
It's a LOT less ASM though there's still a bit of initial setup and
callbacks in ASM that mostly can't be avoided.
> 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.
Doubtful but mildly possible.  You're saying with iPXE loading
PXELINUX 6.00+ that it throws the error "Failed to load ldlinux.c32"
almost instantly and you've done a tap/mirror packet capture and saw 0
traffic?
>> 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).
"DEFAULT menu.c32" is not a good habit.  DEFAULT should point to a
real label and you should use the UI directive to call menu.c32 at
start  ( "UI menu.c32" ), introduced in 3.74.
> 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.
Now I have something I can reproduce.  Booting my same ipxe.iso to
perform an initial TFTP load shows what I saw already.  Attempting to
load a file via http results in an immediate error message with no
resulting traffic as far as I can see.

-- 
-Gene

On Thu, Sep 24, 2015 at 6:33 AM, Gene Cumm <gene.cumm at gmail.com> wrote:
> Now I have something I can reproduce.  Booting my same ipxe.iso to
> perform an initial TFTP load shows what I saw already.  Attempting to
> load a file via http results in an immediate error message with no
> resulting traffic as far as I can see.
OK.  Found it.  core/fs/pxe/pxe.h disabled all of the gPXE/iPXE
callbacks in the core, disabling HTTP and other functionality.  It
appears someone disabled it intentionally in commit ID f180d7c8 but
forgot to go back and conditionally re-enable it.  This would affect
4.10-pre*, 5.1* and 6.0*.

-- 
-Gene

On 9/24/2015 4:33 AM, Gene Cumm wrote:
> On Wed, Sep 23, 2015 at 5:43 PM, Alan Sparks via Syslinux
> <syslinux at zytor.com> wrote:
> Although it means another round of testing, you could also consider
> lpxelinux.0 which can support HTTP URLs on its own and probably
> interacts differently with iPXE.  I am curious about a quantifiable
> description of "an odd delay".
think I mentioned testing lpxelinux in previous response... It did work
better (e.g. work period) in the KVM instance.   It however hung for a
couple of minutes on the Mellanox (hardware) ipxe setup (HP hardware),
before the machine just reset.   Not sure why lpxelinux wouldn't work on
the hardware instance.   I didn't measure the delay, but just sort of
added 5 seconds to the period between pxelinux banner and menu display...
> 
> "DEFAULT menu.c32" is not a good habit.  DEFAULT should point to
a
> real label and you should use the UI directive to call menu.c32 at
> start  ( "UI menu.c32" ), introduced in 3.74.
Granted.   Old people have deep habits.   I had swapped it out for UI
for testing, to no betterment.
> 
> Now I have something I can reproduce.  Booting my same ipxe.iso to
> perform an initial TFTP load shows what I saw already.  Attempting to
> load a file via http results in an immediate error message with no
> resulting traffic as far as I can see.
> 
Very positive development...

> >> 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).
> 
> "DEFAULT menu.c32" is not a good habit.  DEFAULT should point to
a
> real label and you should use the UI directive to call menu.c32 at
> start  ( "UI menu.c32" ), introduced in 3.74.
> 
 
Perhaps you are misreading my suggestion?

With "UI menu.c32", the user has no choice but to use menu.c32 (at 
least at first), which is a problem under the current situation.

The presented configuration file showed "DEFAULT menu.c32", and my 
suggestion was to instead use DEFAULT with a LABEL, and put menu.c32 
under one LABEL, to be chosen only if desired (IOW, if menu.c32 crashes 
in a particular environment, then avoid choosing such label).

This is just a potential temporal workaround, until a better / real 
solution is found.

Regards,
Ady.