[syslinux] Strange behavior

Roy Marantz roy.marantz at vonage.com
Tue Nov 22 11:14:05 PST 2011


On 11/21/11 5:18 PM, "Gene Cumm" <gene.cumm at gmail.com> wrote:

> On Mon, Nov 21, 2011 at 08:30, Roy Marantz <roy.marantz at vonage.com> wrote:
>> On 11/18/11 8:04 PM, "Gene Cumm" <gene.cumm at gmail.com> wrote:
>> 
>>> On Fri, Nov 18, 2011 at 08:42, Roy Marantz <roy.marantz at vonage.com> wrote:
>> ...
>>>> I've done more testing and I agree with you that the issue is due to
>>>> something in the networks involved in my setup.  I've tried using a VM on
>>>> other networks and had everything work as expected.  I will be looking into
>>>> that with our networking group.
>>> 
>>> I'd call that good news/bad news.  Good that you have a direction; bad
>>> that there's something still failing.  I'd still be curious at a
>>> packet capture, more to make sure gPXE and PXELINUX are behaving as
>>> expected, in light of the underlying networking issue (retries and
>>> all).
>> The packet capture didn't show, but Ill have to do them again and look more
>> closely.
> 
> Things like did gPXE get an HTTP 404, socket closed, etc.

I'm still working with our firewall guy to try to understand the symptoms,
but I don't see http packages reliably getting to the server.

>>>> I'd appreciate hearing any suggestions for how to eliminate any of the
>>>> downloads (gpxelinux, menu.pl, menu.c32, menu.pl) that my current procedure
>>>> uses.  I know that I can tell Vmware to use gpxelinux.0 in place of it
>>>> native pxe code, but I need to check on the supportability of that.  I.e.
>>>> Will Vmware balk at supporting such a change.  I was hoping to eliminate
>>>> the
>>>> 2nd menu.pl download.
>>> 
>>> I don't believe you can tell a VM to use alternate code very easily,
>>> especially gpxelinux.0 (which depends on the underlying UNDI) or a VM
>>> on ESXi.  The best suggestion I can think of is replacing the first
>>> config file with a tiny static config that does something like "UI
>>> menu.c32 menu.pl".  Transfer/parsing would be mildly faster and your
>>> httpd might also be a little faster (but probably not enough to really
>>> notice).
>> So you are saying I should replace gpxelinux.0 builtin behaviour of
>> automatically loading pxelinux.0.  The only ways of doing that that I know
>> of are to use undionly.0 (from gpxe distribution) with some dhcpd.conf magic
>> or rebuild gpxelinux.0 with a different builtin script.
> 
> Not at all.  Set DHCP option 209 to static.conf where static.conf
> contains "UI menu.c32 menu.pl" and possibly some small simple fallback
> options.

I'm already setting DHCP options 208, 209, and 210:
        next-server 10.250.50.72;
        vendor-option-space pxelinux;
        option pxelinux.magic f1:00:74:7e;
#       option pxelinux.configfile "menu.pl";
        option pxelinux.configfile "boot.conf";
        option pxelinux.pathprefix "http://10.250.50.72/tftpboot/gpxe/";
        filename "gpxe/gpxelinux.0";

Boot.conf contains a single line of "UI menu.c32 menu.pl"

If DHCP filename is "gpxe/pxeloinux.0" then only tftp will be used so I am
leaving it at gpxelinux.0.  Is this what you were trying to tell me?  Once I
get http working more reliably I'll be able to test how well this works
more.
Thanks.
Roy





More information about the Syslinux mailing list