[syslinux] ifcpu64.c32 not working properly when used in a menu include file

[John N. Newman]

Thank you!  This seems to solve my problem entirely. There were several other options
inadvertently not getting parsed because I was doing a "MENU INCLUDE" rather than a 
plain old "INCLUDE", as you suggested - after taking care of these minor issues, I will
have a 100% working setup.

Again, my thanks,

--
John


On Sep 4, 2012, at 11:02 AM, Gert Hulselmans <hulselmansgert at gmail.com> wrote:

> 2012/9/4 John Newman <jnnewman at peer1.com>:
>> The following is a pxelinux problem, specifically to do with
>> including config files with the menu include directive and the
>> ifcpu64.c32 com module.
>> 
>> I have a working ifcpu64.c32 setup that jumps to the label rescue64
>> in the case of a 64-bit CPU. The label "rescue64" defines a 64-bit
>> kernel and a 64-bit initrd.img. The setup jumps to a label named
>> "rescue32" in the case of a 32-bit CPU, which is also a label, this
>> time defining a 32-bit vmlinuz and a 32-bit initrd.img/userland.
>> 
>> It looks more or less like the following:
>> 
>> # rescue_dev
>> LABEL rescue
>>  IPAPPEND 2
>>  MENU LABEL ^rescue (Auto-detect CPU type)
>>  KERNEL ifcpu64.c32
>>  APPEND rescue64 -- rescue32
>>  TEXT HELP
>>     Load appropriate image
>>  ENDTEXT
>> LABEL rescue64
>>  MENU HIDE
>>  IPAPPEND 2
>>  KERNEL images/vmlinuz64
>>  APPEND initrd=images/initrd64.img init=/linuxrc root=/dev/ram0 rw
>> devfs=nomount console=ttyS0,115200 console=tty0 ksipaddr=kickstart
>> LABEL rescue32
>>  MENU HIDE
>>  IPAPPEND 2
>>  KERNEL images/vmlinuz32
>>  APPEND initrd=images/initrd32.img init=/linuxrc root=/dev/ram0 rw
>> devfs=nomount console=ttyS0,115200 console=tty0 ksipaddr=kickstart
>> 
>> 
>> This all works perfectly when the code above is directly
>> in the pxe target file that is being used. However, when I use the
>> "MENU INCLUDE" directive in a file that defines some more
>> options to suck this bit in, the label parsing/jumping by ifcpu64.c32
>> stops working properly. When I select the "rescue (Auto-detect CPU
>> type)" option from the menu, instead of jumping to the label
>> rescue64, it tries to shove first the literal file rescue64 at me,
>> then when that isn't found it looks for rescue64.cbt, rescue64.0,
>> rescue64.com, rescue64.c32 and maybe a few others. Basically,
>> it is ignoring the rescue64 label and trying to directly spit
>> a rescue64 file out at me. I can see this from the tftpd logs.
>> 
>> Has anyone else seen similar behaviour? Any tips or ideas?
>> 
>> Greatly appreciated,
>> John
>> 
>> --
>> John Newman
>> Product Engineering - Peer1 Hosting
>> _______________________________________________
>> Syslinux mailing list
>> Submissions to Syslinux at zytor.com
>> Unsubscribe or set options at:
>> http://www.zytor.com/mailman/listinfo/syslinux
>> Please do not send private replies to mailing list traffic.
>> 
> 
> Hi John,
> 
> Can you try with:
>  INCLUDE filename
> instead?
> 
> In Syslinux versions lower than 5, there are 2 config parsers:
>  - one in the core, written in assembler
>  - one in (vesa)menu.c32, written in C
> 
> Only (vesa)menu.c32 processes MENU ... keywords.
> The config parser in C doesn't see your MENU INCLUDE.
> 
> When ifcpu64.c32 is called, it only sees the LABELs that are seen by the
> core config parser, and is thus unaware of everything specified in the file
> that you included with MENU INCLUDE.
> 
> - Gert
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
> 

--
John Newman
Product Engineering