[gPXE] Pushing GPXE script to HTTP server

[Gene Cumm]

On Fri, Nov 5, 2010 at 08:18, David Geary <dgeary2 at une.edu.au> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> It worked well for what I wanted if I do single boot, however I couldn't
>> get the multi-boot menu to work.
>
> Well done getting single boot working.
>
>> So my gpxe.conf looks like this:
>>
>> #!gpxe
>> chain vesamenu.c32 multibootmenu.conf
>>
>> The station tries to switch graphics mode for a second and reboots.
>>
>> I guess that's because (vesa)menu.c32 of Syslinux couldn't find
>> multibootmenu.conf (or whatever file it was supposed to read as its
>> argument). I placed multibootmenu.conf and (vesa)menu.c32 in the same
>> directory as gpxe.conf (which is hard-coded to the ROM).
>
> Perhaps (vesa)menu.c32 suffers the same filename limitations as the rest
> of Syslinux. Syslinux is limited to filenames in the 8.3 format. This
> explains not finding the configuration file.

SYSLINUX 3.70+ supports long file names however might not like some
characters.  Prior to this, I believe EXTLINUX, PXELINUX, and ISOLINUX
could use long names.

http://syslinux.zytor.com/wiki/index.php/Common_Problems#What.27s_the_real_name_of_that_file.3F

Personally, I normally try to make file names that can sit on all
variants happily.  [a-z0-9_] as the main character set (normally I
prefer "-" over "_" but make an exception for boot stuff) with a limit
of 1 "." and at most 31 characters in length (including the "."; can't
remember why this length; Mac OS maybe?).  I also apply the same rule
to LABELs (but love abusing MENU LABELs)

> I have seen this in other areas where I've used Syslinux and have formed
> the habit of using only 8.3 filenames when Syslinux is involved in any way.
>
> I am using vesamenu.c32 from Syslinux 4.01 as well.

I just came to the realization this morning that (probably) the reason
that COM32R modules (Syslinux 4.00+) fail in gPXE's native COMBOOT
environment is that any attempt to use the protected mode calls (all
file I/O unless written poorly with intcall(), among others) results
in some sort of error.  I haven't nailed it down but I don't think
it's worthwhile troubleshooting.

-- 
-Gene