[syslinux] PATH directive searches in reverse order with wrong separator

[Ady Ady]

> I've been trying to get syslinux.efi working in my environment again...
> 
> Found what look like a bunch of little bugs that are very frustrating...
> 
> First, the documentation on the Wiki says that as of 5.11, the list
> separator is space, not colon.  But I can find no evidence that 5.11
> was ever officially released or that a commit to git was made to make
> this change.  6.00 and following still use colon as the separator in
> the parse routine.  This should fix that.
 
 
 (snip) 
 
 
A minor note (for readers), just in case... the current git repo is 
located at:
 http://repo.or.cz/syslinux.git 
Many users/readers still think that kernel.org is always up-to-date, 
which is not the case. We can never be sure which base (6.03? 
6.04-pre1? some commit?) is being used for patches, unless explicitly 
noted.


Now, if I may...

I don't recall any user presenting a practical real-world situation in 
which multiple paths were actually needed as arguments for the PATH 
directive.

On the other hand, I do recall several conversations / reports / 
problems caused by the supposed capability of having multiple paths 
available in the PATH directive. The reported problems were not only 
related to the capability itself (and how it was coded) but also 
related to the specific selection of path separator (or entry 
separator).

One alternative, in an attempt to reduce potential issues, was/is the 
recommendation to use multiple PATH directives, each in a different 
line/row in the configuration file, instead of using the path separator 
within one same PATH directive.

In other words, the PATH directive accepts:

PATH first_path
PATH second_path

and the paths are appended to the list of searched-for paths (looking 
for c32 (library) modules). I would suggest trying this alternative for 
a test, independently of how the code might parse / mess up this 
notation anyway.

Yet, again, real-world cases were not presented here.


Important reminder: the "Current Working Directory" is supposed to be 
the first searched-for directory, always; the specific location of the 
main c32 file does not modify the priority of the searched-for list of 
its dependencies.
 
 
 (snip) 
 
 
> 
> While trying to figure all that out, I found this in
> generic_mangle_name() which looks wrong to me.  When collapsing repeat
> slashes (should we also be stripping repeat backslashes here?), we
> decrement i which is the "space left" count, but we haven't actually
> copied a character.  I think that means that later, we'll end up
> padding with the incorrect number of characters.
> 
> diff --git a/core/fs/lib/mangle.c b/core/fs/lib/mangle.c
> --- a/core/fs/lib/mangle.c
> +++ b/core/fs/lib/mangle.c
> @@ -23,7 +23,6 @@ void generic_mangle_name(char *dst, const char *src)
>          if (*src == '/') {
>              if (src[1] == '/') {
>                  src++;
> -                i--;
>                  continue;
>              }
>          }
 
 
Hmm, for some reason your words reminded me of:
"chrreplace: Don't skip the first character"
 commit/779a4c85252de59b3134d39961c3f63c99d0ea2e 

Very possibly it has nothing to do here, but...
 
 
> 
> Even with these fixes or workarounds in my testing, the ldlinux
> searching seems broken.  Specifically, I have my DHCP server configure
> to send "/efi/syslinux.efi" as the "filename" and placed ldlinux.e64
> in that same directory under the assumption that the documentation is
> right and syslinux will look in the same directory as the filename for
> ldlinux.EXT.  The code appears to do that, but what the TFTP server
> sees is a second request for /efi/syslinux.efi and then ldlinux.e64
> searched for in the hard coded search_directories list which doesn't
> match my network configuration.
> 
> If I change the DHCP configuration to use pathprefix set to /efi/ then
> it finds ldlinux.e64 and can find my configfile, but I want to follow
> the layout recommended in the wiki documentation where I could have
> all three of bios, e32 and e64 versions of com32 modules in
> subdirectories of the same parent expecting a PATH directive to find
> he right version.  But that  doesn't seem to work either.
> 
> TLDR:
> If I could get a second pair of eyes on this, I'll turn them into a
> series of smaller commits in git and submit a pull request.
 
 
In addition, there is a known issue in the PATH directive. The PATH 
directive parses its own paths as "absolute", and the result is "as 
expected" when other directives use relative paths. But when there are 
absolute paths being used by other directives, then the resulting PATH 
is incongruous. Whether the issue should be considered a "bug" or an 
expected / desired result, that has never been clarified. See bug #58 
in Syslinux's bug tracker.

Finally, from the user's perspective, alternative (new) directives have 
been proposed, reducing the complexity (for users). See:
 http://www.syslinux.org/archives/2016-June/025224.html 

Being realistic, if the goal is to make syslinux.efi work in your 
environment, then probably posting your complete set of configuration 
files might be relevant, considering the known problems and the 
frequent misunderstandings we have seen over the years about the 
multi-platform setup.

At any rate, I would certainly welcome active improvement of the source 
code.
 
 
> 
> Phil P.
> 
 
Regards,
Ady.