The config.c32 module (and the CONFIG directive) is not behaving as expected when using syslinux.exe 5.00pre11 as installer. To replicate: 1_ The content of the device: /dira /cat.c32 /config.c32 /ldlinux.c32 /ldlinux.sys /libcom32.c32 /pwd.c32 /syslinux.cfg /dira/dira.cfg 2_ Content of /syslinux.cfg: DEFAULT pwd1 PROMPT 0 LABEL config1 COM32 config.c32 /dira/dira.cfg APPEND /dira/ LABEL pwd1 COM32 pwd.c32 LABEL config11 CONFIG /dira/dira.cfg APPEND /dira/ 3_ Content of /dira/dira.cfg DEFAULT pwd2 LABEL pwd2 COM32 /pwd.c32 LABEL config2 COM32 /config.c32 /syslinux.cfg APPEND / LABEL config21 CONFIG /syslinux.cfg APPEND / 3_ Boot and Run "config1" label. 4_ Run config2 label 5_ Press TAB. Since "config2" should have loaded syslinux.cfg, pressing [TAB] should bring the labels in syslinux.cfg, but it doesn't. Instead, it brings again the labels from dira.cfg. 6_ Run /pwd.c32 Undef symbol FAIL: getcwd 5_ pwd.c32 (without the "/") does nothing and returns to the prompt. 6_ config2 Undef symbol FAIL: fprintf The above is just one of several ways I see config.c32 (and the CONFIG directive) failing, specially when using the second argument (to change the soon-to-be-current working directory), whether in absolute or relative notations. In addition, if I also use a DISPLAY file in syslinux.cfg, the screen is cleaned up when running step #3 above, and step #5 doesn't show any available labels. I personally don't see this clean up as necessary (and it even be inconvenient in certain situations). I don't know why using DISPLAY would affect the above procedure, but it does. In the above procedure, change step #3 to "config11" and step #4 to "config21" so to use the CONFIG directive instead of the config.c32 module. The result is even worse: after step #4; it hangs. One possibility (among many): It may be related to changing the working directory to an upper level directory. TIA, Ady.
On Wed, 2012-11-28 at 23:25 +0200, Ady wrote:> The config.c32 module (and the CONFIG directive) is not behaving as > expected when using syslinux.exe 5.00pre11 as installer. To > replicate: > > > 1_ The content of the device: > > /dira > /cat.c32 > /config.c32 > /ldlinux.c32 > /ldlinux.sys > /libcom32.c32 > /pwd.c32 > /syslinux.cfg > > /dira/dira.cfg > > 2_ Content of /syslinux.cfg: > > > DEFAULT pwd1 > PROMPT 0 > LABEL config1 > COM32 config.c32 /dira/dira.cfg > APPEND /dira/ > LABEL pwd1 > COM32 pwd.c32 > LABEL config11 > CONFIG /dira/dira.cfg > APPEND /dira/ > > 3_ Content of /dira/dira.cfg > > DEFAULT pwd2 > LABEL pwd2 > COM32 /pwd.c32 > LABEL config2 > COM32 /config.c32 /syslinux.cfg > APPEND / > LABEL config21 > CONFIG /syslinux.cfg > APPEND / > > > 3_ Boot and Run "config1" label. > > 4_ Run config2 label > > 5_ Press TAB. > > Since "config2" should have loaded syslinux.cfg, pressing [TAB] > should bring the labels in syslinux.cfg, but it doesn't. Instead, it > brings again the labels from dira.cfg. > > 6_ Run /pwd.c32 > Undef symbol FAIL: getcwd > > 5_ pwd.c32 > (without the "/") does nothing and returns to the prompt. > > 6_ config2 > Undef symbol FAIL: fprintf > > > The above is just one of several ways I see config.c32 (and the > CONFIG directive) failing, specially when using the second argument > (to change the soon-to-be-current working directory), whether in > absolute or relative notations.I just pushed out syslinux-5.00-pre12. Please test that. Note that it won't fix step 6 above, though it does fail much more gracefully. You can work around it by adding, PATH / to your dira.cfg file. However, we do need to fix that properly, so that when you type the absolute path to a module, we search in that directory for its dependencies. I'm working on a fix for that.> In addition, if I also use a DISPLAY file in syslinux.cfg, the screen > is cleaned up when running step #3 above, and step #5 doesn't show > any available labels. I personally don't see this clean up as > necessary (and it even be inconvenient in certain situations). I > don't know why using DISPLAY would affect the above procedure, but it > does.I'll look at this for the next prerelease. -- Matt Fleming, Intel Open Source Technology Center
> On Thu, 2012-11-29 at 09:25 -0800, H. Peter Anvin wrote: > > Maybe we should make the install directory (or config file root > > directory) the default PATH instead? > > Yeah, that makes sense. >How would that change affect config.c32 and the CONFIG directive when changing to a new working directory? I am thinking about different situations. One is the use of relative paths (which usually make the cfg files more "portable" regarding the directory tree). A second situation is using CONFIG (and there are other alternatives) as a "connector" between different cfg files, which originally were part of different ISO images (for example). In this case, c32 modules (and other files related to Syslinux) might be located in different directories, according to each cfg file. A third situation could be similar to the second one, but with all modules in one central directory ("/boot/syslinux/" for example) and each cfg file (each one located in different directories) using the appropriate absolute (or even relative) path. So, is the default PATH set only at boot? Or is it automatically "updated" (or "re-set") with each change of working directory (or in any other situation)? Are there any situations where PATH is automatically "updated"? (I mean "updated" without having to use a new PATH directive in each cfg file.) If such situation exist, is the new PATH replaced, or is it merged (appended) with the previous values? The reason I bring this up is because having to explicitly set PATH in each cfg file (where each cfg file may have a different working directory) _might_ be inconvenient in certain cases, specially if using relative paths in the cfg files (with "portability" in mind). And speaking about relative paths, can relative notation be used for the PATH directive? Can a new directory be added to whatever the PATH value was before, without having to repeat (or even know) the previous PATH value(s)? Or instead, each PATH directive completely replaces any previous value(s) and there is no means to "add" ("merge", "append")? Evidently, the user could manually set a new PATH directive in each cfg file to match the (relative) directory tree used in the rest of the directives in that cfg file. Are there any other alternatives? Is there any need for a "path.c32" (or some other less-ambivalent name) so to change the PATH value(s) directly from the prompt? I apologize if the above questions are trivial or dumb to you. I am just trying to understand this new PATH directive as user, and for better testing purposes. TIA, Ady.
On Wed, 2012-11-28 at 23:25 +0200, Ady wrote:> The config.c32 module (and the CONFIG directive) is not behaving as > expected when using syslinux.exe 5.00pre11 as installer. To > replicate:All the issues you highlighted in this email should now be fixed in Syslinux-5.00-pre13. Thanks. -- Matt Fleming, Intel Open Source Technology Center