[syslinux] Strange behavior

[Roy Marantz]

I just tried it using syslinux 4.04 on a physical machine and everything
worked reliably.  So I would conclude that there is some race condition
between vCenter 4.10  and SYSLINUX 4.04.  How close is SYSLINUX 4.10 to
being available or is there any plan to backport that patch to SYSLINUX
4.04?

BTW, I was still seeing requests for menu.c32.{cbt,com,c32}.  I did "ln -s
menu.c32 menu.c32.c32" to work around that.

I can write up my setup in detail if you guys want some documentation.  I
made some small changes to dhcpd.conf, apache2 conf, and a custom perl cgi
script to hack a pxelinux/menu config.
Thanks.
Roy


On 11/16/11 6:07 PM, "Gene Cumm" <gene.cumm at gmail.com> wrote:

> Sorry, I must have misread things at first.  You're talking VMware
> ESX(i) 4.1.0 with vCenter 4.1.0 (irrelevant) using Syslinux-4.04.  I
> thought you had somehow also meant Syslinux-4.10-pre* was having
> issues but 4.04 worked.
> 
> Version strings can be confusing sometimes.
> 
> On Wed, Nov 16, 2011 at 15:23, Roy Marantz <roy.marantz at vonage.com> wrote:
>>> There's a race condition with at least some VMware products that I solved
>>> last month.  HPA committed the fixes to the lwip branch but I don't believe
>>> he's released a new 4.10 prerelease yet.
>> 
>> I'll try using a physical box to see if it makes a difference.
>> Assuming that works, is the patch available against 4.04 or how stable is
>> 4.10-pre?  I'd like to use this in production soon.
>> 
>>>> What might cause menu.c32.{0,com,cbt,c32} to be requested?
>> 
>>> Default name fallback mechanism.  If it can't find the specified file,
>>> attempt appending certain extensions.
>> That makes sense except that the real filename was never requested.
> 
> Have you tried a packet capture on the vSwitch?  It's possible the
> first request is sent but there's an error.
> 
>> On 11/16/11 5:04 PM, "Gene Cumm" <gene.cumm at gmail.com> wrote:
>> 
>>> On Nov 16, 2011 3:35 PM, "Roy Marantz" <roy.marantz at vonage.com> wrote:
>>>> 
>>>> I'm using syslinux 4.04 with dynamically generated menus configuration
>>> based
>>>> on info found in various web pages.  I'm doing my testing using a vCetner
>>>> 4.10 Vmware virtual machine.  This works some of the time, but not always.
>>>> I just copied the prebuilt modules from the syslinux 4.04 distribution for
>>>> gpxelinx.0, menu.c32, reboot.c32, and pxelinux.0
>>> 
>>> There's a race condition with at least some VMware products that I solved
>>> last month.  HPA committed the fixes to the lwip branch but I don't believe
>>> he's released a new 4.10 prerelease yet.
>>> 
>>>> When I boot a machine dhcpd says to boot gpxelinux.0 with
>>>> pxelinux.pathprefix "http://10.250.50.72/tftpboot/gpxe/" and
>>>> pxelinux.configfile "menu.pl" so that menu.pl generates the real
>>>> configuration information for the chain loaded pxelinux.0.
>>>> 
>>>> I see the startup messages from gpxelinux.0 and pxelinux 4.04, a message
>>>> saying that menu.pl was loaded OK, and the output of  a SAY statement in
>>> the
>>>> generated configuration.
>>>> 
>>>> In the generated configuration is a UI menu.c32 line and a few LABEL
>>>> stanzas.
>>>> 
>>>> I'm watching the logs from my apache server and see that sometimes it get
>>>> requests for loading /tftpboot/gpxe/menu.c32.0, /tftpboot/gpxe/
>>> menu.c32.com,
>>>> /tftpboot/gpxe/menu.c32.cbt, or /tftpboot/gpxe/menu.c32.c32 before
>>> aborting
>>>> and saying:
>>>> Could not find kernel image: menu.c32
>>>> I can work around that by creating /tftpboot/gpxe/menu.c32.c32 or putting
>>>> "UI menu" in the configuration file, but it still tries to load all the
>>>> other files first.
>>>> 
>>>> What might cause menu.c32.{0,com,cbt,c32} to be requested?
>>> 
>>> Default name fallback mechanism.  If it can't find the specified file,
>>> attempt appending certain extensions.
>>> 
>>>> It seems to take a "long" time (say 30 seconds) between the time the SAY
>>>> messages shows up and the menu is displayed?  Why?  That seems to be when
>>> it
>>>> is trying to load all the difference menu.c32 files.
>>> 
>>> It takes a while for it to fail.
> 
> Take a look at your Apache HTTPd and a packet capture.  It's possible
> that something is delaying the return of the error as I've seen things
> progress much faster on my VMware platforms.
> 
>>>> BTW, I have a LABEL setup to use reboot.c32 and while that causes the boot
>>>> process to restart, it only tries to load menu.0 and menu.com.  I'll worry
>>>> about this later thought.
>>>> 
>>>> Thanks for any help or ideas.
>>>> Roy
>>> 
>>> Hope this helps.