[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