Syslinux - Dec 2012 - Syslinux 5 (i)pxelinux.0 unnecessary PATH requests

Hi there,

i just build a new ipxelinux.0 with an EMBED=../../syslinux-5/core/pxelinux.0.
i'm trying to load up my vesamenu.c32 menu from http:.

and offcorse i want this as optimal as possible, with the least needed GET
requests.

OLD situation with v4:
PXE ROM -> ipxelinux.0 (tftp) -> menu.php (http) -> vesamenu.c32 (http)

NEW situation with v5:
PXE ROM -> ipxelinux.0 (tftp) -> /ldlinux.c32 (http 404) ->
//ldlinux.c32 (http 404) -> //boot/isolinux/ldlinux.c32 (http 404) ->
//isolinux/ldlinux.c32 etc. etc. -> menu.php (http 200) ->
/mods/vesamenu.c32 (http 200)
that can be fixed with adding ldlinux.c32 to the root of my webserver (ugly...
but oke).
but then we still have the other libraries, which it tries to fetch in the same
directories first, and yes we can add those to the root aswel as a work
around.... but i'd love to have them seperate.

menu.php has the UI directive as /mods/vesamenu.c32 and the PATH as mods
configured
but then still with that PATH directive in the menu it still tries to find the
libraries in this order:

GET /libcom32.c32 (http 404)
GET //libcom32.c32 (http 404)
GET /mods//libcom32.c32 (http 200) < --- success!
GET /libutil_com.c32 (http 404)
GET //libutil_com.c32 (http 404)
GET /mods//libutil_com.c32 (http 200) <--- success!

in my opinion these are atleast 4 unnecessary requests to the webserver before
finding the correct one.
and another thing the PATH directive can only be read after ldlinux.c32 is
loaded, so ldlinux.c32 should always be in the root?

i'm looking for a way to configure this to only search the libs and
ldlinux.c32 in ./mods/ to limit the needed GETs to the server, speed things up a
bit and have a neat directory structure.

i was already found the 'search_directories' static const in
load_env32.c, but after changing that to:
  static const char *search_directories[] = {
    "/mods",
    NULL
  };

it still does these requests:
GET /libcom32.c32
GET //libcom32.c32


Any help is appreciated.

Rgds,

Reni

On 12/11/2012 11:37, Arends, R.R. wrote:
>
> i just build a new ipxelinux.0 with an
EMBED=../../syslinux-5/core/pxelinux.0.
> i'm trying to load up my vesamenu.c32 menu from http:.
>
> and offcorse i want this as optimal as possible, with the least needed GET
requests.
>
> OLD situation with v4:
> PXE ROM -> ipxelinux.0 (tftp) -> menu.php (http) -> vesamenu.c32
(http)
>
> NEW situation with v5:
> PXE ROM -> ipxelinux.0 (tftp) -> /ldlinux.c32 (http 404) ->
//ldlinux.c32 (http 404) -> //boot/isolinux/ldlinux.c32 (http 404) ->
//isolinux/ldlinux.c32 etc. etc. -> menu.php (http 200) ->
/mods/vesamenu.c32 (http 200)
> that can be fixed with adding ldlinux.c32 to the root of my webserver
(ugly... but oke).
> but then we still have the other libraries, which it tries to fetch in the
same directories first, and yes we can add those to the root aswel as a work
around.... but i'd love to have them seperate.
>
> menu.php has the UI directive as /mods/vesamenu.c32 and the PATH as mods
configured
> but then still with that PATH directive in the menu it still tries to find
the libraries in this order:
>
> GET /libcom32.c32 (http 404)
> GET //libcom32.c32 (http 404)
> GET /mods//libcom32.c32 (http 200) < --- success!
> GET /libutil_com.c32 (http 404)
> GET //libutil_com.c32 (http 404)
> GET /mods//libutil_com.c32 (http 200) <--- success!
>
> in my opinion these are atleast 4 unnecessary requests to the webserver
before finding the correct one.
> and another thing the PATH directive can only be read after ldlinux.c32 is
loaded, so ldlinux.c32 should always be in the root?
>
> i'm looking for a way to configure this to only search the libs and
ldlinux.c32 in ./mods/ to limit the needed GETs to the server, speed things up a
bit and have a neat directory structure.
>
> i was already found the 'search_directories' static const in
load_env32.c, but after changing that to:
>    static const char *search_directories[] = {
>      "/mods",
>      NULL
>    };
>
> it still does these requests:
> GET /libcom32.c32
> GET //libcom32.c32
Are you using DHCP option 210?  It is documented in doc/pxelinux.txt and 
is related to where PXELINUX goes looking for things.  Yes, PATH cannot 
be processed until ldlinux.c32 is fetched, but option 210 is processed 
before.  - Shao

Am 11.12.2012 19:50, schrieb Shao Miller:
> Are you using DHCP option 210?  It is documented in doc/pxelinux.txt and
> is related to where PXELINUX goes looking for things.  Yes, PATH cannot
> be processed until ldlinux.c32 is fetched, but option 210 is processed
> before.  - Shao
As Arends also pointed out, this is not very helpful.

I have setups where I set 210 to the root, and set filename to
/path/to/pxelinux.0. A better alternative would be to look in the
dirname of the boot filename first.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://www.zytor.com/pipermail/syslinux/attachments/20121212/8993c5db/attachment.sig>

On 12/12/2012 07:54, Thomas B?chler wrote:
> Am 11.12.2012 19:50, schrieb Shao Miller:
>> Are you using DHCP option 210?  It is documented in doc/pxelinux.txt
and
>> is related to where PXELINUX goes looking for things.  Yes, PATH cannot
>> be processed until ldlinux.c32 is fetched, but option 210 is processed
>> before.  - Shao
>
> As Arends also pointed out, this is not very helpful.
>
> I have setups where I set 210 to the root, and set filename to
> /path/to/pxelinux.0. A better alternative would be to look in the
> dirname of the boot filename first.
That is exactly what doc/pxelinux.txt documents that PXELINUX does 
_without_ option 210.  You are _overriding_ "the dirname of the boot 
filename" by using 210.  - Shao

On 12 dec. 2012, at 17:33, "Shao Miller <sha0.miller at
gmail.com>" <sha0.miller at gmail.com> wrote:
> On 12/12/2012 11:17, Shao Miller wrote:
>> On 12/12/2012 10:48, Arends, R.R. wrote:
>>> 
>>> good idea, but imho this still involves in making extra requests to
>>> the backend and rather 'hacky' chain->chain->chain
stuff to make it
>>> harder to understand for my fellow cowokers.
>>> 
>>> if anyone can point me to the right source files to edit and
hardcode
>>> the path, i would really appreciate it. i know thats also hacky,
but
>>> thats easy to do since we already have some custom patches which we
>>> always apply.
>> 
>> As mentioned elsethread, you are overriding the path by using 210. 
That
>> is to say, you are setting the current working directory.  The current
>> working directory is used for opening files with relative paths (in a
>> few different operating systems, even).  If you don't want to do
this,
>> don't do it. :)
>> 
> 
> For example, there is no reason for you to set 210 since you can 
> hard-code the iPXE script, which you are already doing:
> 
>   #!ipxe
>   #...
>   # Do not set 210
>   set filename http://boot.xxx.nl/mods/pxelinux.0
>   chain ${filename}
> 
> Then ldlinux.c32 is searched-for where pxelinux.0 lives.
> 
> - Shao Miller
That might work, will try what it does without setting option 210 and check the
webservers logs.

Will report back next week.

- reni

On Tue, 2012-12-11 at 17:37 +0100, Arends, R.R. wrote:
> and another thing the PATH directive can only be read after
> ldlinux.c32 is loaded, so ldlinux.c32 should always be in the root?
ldlinux.c32 must be in the "installation" directory. So, for PXELINUX,
ldlinux.c32 must be in the same directory as pxelinux.0.

-- 
Matt Fleming, Intel Open Source Technology Center