[syslinux] Nested SYSLINUX configurations -- error using CONFIG directive

Rich Mahn rich at lat.com
Wed Mar 30 09:55:32 PDT 2011


Gene Cumm <gene.cumm at gmail.com> wrote:

> On Wed, Mar 30, 2011 at 10:35, Rich Mahn <rich at lat.com> wrote:
> > Rich Mahn <rich at lat.com> wrote:
> >
> >> > From: "Rich Mahn" <rich at lat.com>
> >> >
> >> > > H. Peter Anvin <hpa at zytor.com> wrote:
> >> > > >> There seems to be an error using '..' in the append portion of the
> >> > > >> CONFIG directive.
> >> > > >
> >> > > > This is a known bug in Syslinux 4.03.  It should be fixed in 4.04-pre14,
> >> > > > but if it is not, please scream.
> >> > > >
> >> > > > -hpa
> >> > > >
> >>
> >> Ok.  I have successfully recompile 4.04-pre14.  The problem still exists.  Here's
> >> another example:
> >> in root:
> >> LABEL dir1
> >>    config dir1/config.cfg
> >>    append dir1
> >> LABEL non-existant dir2
> >>    config dir2/config.cfg
> >>    append dir2
> >>
> >> in dir1
> >> LABEL up
> >>    config ../config.cfg
> >>    append ..
> >>
> >> directory structure:  /dir1/dir2 with no /dir2
> >>
> >> startup syslinux in the root directory.
> >> select dir1, menu in dir1 comes up.
> >> selet up, menu in root comes up.
> >>
> >> then select dir2.  menu in /dir1/dir2 comes up
> >>
> >> somehow the "current working directory" doesn't seem to get
> >> changed with ".." or any variant thereof.  But the config
> >> file and the other items, such as kernel, initrd, etc come
> >> from the correct directory
> >
> > I was mistaken about the kernel, initrd, etc.  They are not coming from
> > the correct directory, but instead they are coming from the directory
> > where the CONFIG directive was given.  This simplifies the
> > characterization of the error considerably:
> >
> > The processing of the change to the current directory terminates upon a
> > ".." as a component of the path.  For example, if the append portion of
> > the CONFIG directive is "A/B/../C/."  it will be processed as if it was
> > "A/B".
> 
> Since you've already grabbed 4.04-pre14, take a look at
> doc/syslinux.txt, lines 231-238.  I extended and partially rewrote
> that section based on what I understood as the behavior.  If it's not
> clear or you notice behavior contrary to that section, let us know.
> 
> Also, there's com32/modules/pwd.c32 which will show you the current
> working directory as Syslinux has stored it, com32/modules/ls.c32
> which accepts up to 1 parameter (a directory) to produce a directory
> listing and com32/rosh/rosh.c32, a read-only shell (still a work in
> progress but reasonably usable).
> 
> -- 
> -Gene
Gene,
  The description in doc/syslinux.txt looks good to me, once the behaviour
of the ".." portion has been fixed.  If it isn't fixed then we should
probably put in some warning about it.
  I used pwd.c32 to verify what I said earlier about the path 1) not being
changed if it is ".." and 2) being partially changed if it is something
like "A/../B" (where it goes to "A".
  That rosh is a nice utility.  Glad you told me about it.  When you
do "cd A", followed at some time by "cd ..", then "pwd" shows the
current path as "/A/../", which should be equivalent to "/" on most
filesystems.
   We can reproduce the CONFIG directive problem using the c32 modules
as follows:
   1. create a bootable media containing:
      a) a subdirectory named A
      b) a dummy config filed called "config.cfg"
      c) pwd.c32 and config.c32 in the root directory
   2. boot this media
   3. get to the boot: prompt to do each of the following:
     4. type "/pwd.c32"  to show "/" as the current directory
     5. type "/config.c32 /config.cfg A"  to changed to A as the current directory
     6. type "/pwd.c32"  to verify that "/A/" is the current directory
     7. type "/config.c32 /config.cfg .." to change the directory again
     8. type "/pwd.c32" to show that the current directory is still "/A/"

   I haven't been able to figure out where the code is handling this.  If it's
assembly I probably can't be of much assistance, but if it's in C I might be
able to find something.  Any pointers would be appreciated.

Rich




More information about the Syslinux mailing list