Syslinux - Apr 2014 - Issues with syslinux_run_command(str) and parameters

> 
> Thanks Ady, you were spot on, and I should have tested that scenario! 
> I narrowed the issue down to a line in my config: 
> 
> 
> ALLOWEDOPTIONS 0
> 
> 
> The comment next to it in my config indicates this was added to 
> disallow users dropping to the console with Escape or Tab, a 
> restriction I would like to keep. BUT, when this is set whichsys 
> fails to function in the manner I described. And similarly if I end 
> up at the console prompt for any other reason and try to run 
> something, no parameters make it through).
> 
> 
> Is this expected? Seems a bit odd.?
> 
> Thank you very much!
> 
> --Ian
The directive you are referring to is "ALLOWOPTIONS 0" (no
"ED"),
which prevents users from editing commands. In other words, the user 
can only execute LABELs "as-is". Yet, I doubt this is the (only) 
problem.

My guess is that you are using another directive, "NOESCAPE 1", 
which, when combined with additional directives ("PROMPT 0" and/or 
"UI"), prevents the possibility of "forcing" the
"boot:" prompt (with
either SHIFT / ALT / CAPS LOCK / NUM LOCK) at boot time.

In practice, "NOESCAPE 1" forces either the DEFAULT command or the UI 
directive (the latter takes precedence), thus preventing the 
possibility of using the CLI at *any* time, even after executing some 
other command.

So, take for example "ls.c32". Normally, after executing
"ls.c32" you
would end (back) at the CLI. But with "NOESCAPE 1", you jump 
immediately to the UI directive (or, if UI is not used, to the 
DEFAULT command); the CLI is not allowed.

My guess is that something in your cfg is being (automatically) 
executed and then it is exiting (whether after failure or success) 
back to Syslinux. Since the CLI is not allowed (by "NOESCAPE 1"), the 
Syslinux menu is seen again. Once the menu is loaded, the same entry 
is again automatically executed... producing a loop.

I don't really know yet whether you are actually using "NOESCAPE
1".
Whichever the case, I would repeat my suggestion to post the content 
of your cfg file, so we might find out which command is failing (and 
therefore sending you to a loop).

Additionally, it could be helpful to double check the paths to your 
images. For instance, if you have "APPEND initrd=/myimage", is 
"myimage" really located in "/"?

Regards,
Ady.

I don't think that's it, but fair enough, try this sample config:
************************************************# Test File: isolinux.cfg
default vesamenu.c32
ALLOWOPTIONS 0
LABEL Test	kernel whichsys.c32	append -iso- memdisk initrd=fdboot.img -sys-
initrd=fdboot.img
MENU END************************************************

I am using binaries from 6.03-pre11 from kernel.org. I used vesamenu.c32 and
fdboot.img (FreeDOS) for the example but they are not required.
Accepting that this is a silly use of whichsys.c32, running the same thing in
both cases, it does illustrate the issue. When ALLOWEDOPTIONS is set to 0,
memdisk errors "No ramdisk image specified!" as it does not receive
the additional parameter. If you comment out ALLOWEDOPTIONS 0, then memdisk
loads the image without any trouble.
Similarly, if I use a config that only has the ALLOWOPTIONS 0 line (no vesamenu,
etc.), "memdisk initrd=fdboot.img" will error "No ramdisk image
specified!". Again commenting out ALLOWOPTIONS 0 resolves this.

My apologies for not providing the sample config previously!
--Ian
> From: ady-sf at hotmail.com
> To: syslinux at zytor.com
> Date: Wed, 30 Apr 2014 02:32:05 +0300
> Subject: Re: [syslinux] Issues with syslinux_run_command(str) and
parameters
> 
> 
> > 
> > Thanks Ady, you were spot on, and I should have tested that scenario! 
> > I narrowed the issue down to a line in my config: 
> > 
> > 
> > ALLOWEDOPTIONS 0
> > 
> > 
> > The comment next to it in my config indicates this was added to 
> > disallow users dropping to the console with Escape or Tab, a 
> > restriction I would like to keep. BUT, when this is set whichsys 
> > fails to function in the manner I described. And similarly if I end 
> > up at the console prompt for any other reason and try to run 
> > something, no parameters make it through).
> > 
> > 
> > Is this expected? Seems a bit odd. 
> > 
> > Thank you very much!
> > 
> > --Ian
> 
> The directive you are referring to is "ALLOWOPTIONS 0" (no
"ED"),
> which prevents users from editing commands. In other words, the user 
> can only execute LABELs "as-is". Yet, I doubt this is the (only) 
> problem.
> 
> My guess is that you are using another directive, "NOESCAPE 1", 
> which, when combined with additional directives ("PROMPT 0"
and/or
> "UI"), prevents the possibility of "forcing" the
"boot:" prompt (with
> either SHIFT / ALT / CAPS LOCK / NUM LOCK) at boot time.
> 
> In practice, "NOESCAPE 1" forces either the DEFAULT command or
the UI
> directive (the latter takes precedence), thus preventing the 
> possibility of using the CLI at *any* time, even after executing some 
> other command.
> 
> So, take for example "ls.c32". Normally, after executing
"ls.c32" you
> would end (back) at the CLI. But with "NOESCAPE 1", you jump 
> immediately to the UI directive (or, if UI is not used, to the 
> DEFAULT command); the CLI is not allowed.
> 
> My guess is that something in your cfg is being (automatically) 
> executed and then it is exiting (whether after failure or success) 
> back to Syslinux. Since the CLI is not allowed (by "NOESCAPE 1"),
the
> Syslinux menu is seen again. Once the menu is loaded, the same entry 
> is again automatically executed... producing a loop.
> 
> I don't really know yet whether you are actually using "NOESCAPE
1".
> Whichever the case, I would repeat my suggestion to post the content 
> of your cfg file, so we might find out which command is failing (and 
> therefore sending you to a loop).
> 
> Additionally, it could be helpful to double check the paths to your 
> images. For instance, if you have "APPEND initrd=/myimage", is 
> "myimage" really located in "/"?
> 
> Regards,
> Ady.
> 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux

Apologies for how that formatted. Also on pastebin: http://pastebin.com/EXSq75yX
--Ian
> From: ian at internals.io
> To: ady-sf at hotmail.com; syslinux at zytor.com
> Date: Tue, 29 Apr 2014 19:09:09 -0500
> Subject: Re: [syslinux] Issues with syslinux_run_command(str) and
parameters
> 
> I don't think that's it, but fair enough, try this sample config:
> ************************************************# Test File: isolinux.cfg
> default vesamenu.c32
> ALLOWOPTIONS 0
> LABEL Test	kernel whichsys.c32	append -iso- memdisk initrd=fdboot.img -sys-
initrd=fdboot.img
> MENU END************************************************
> 
> I am using binaries from 6.03-pre11 from kernel.org. I used vesamenu.c32
and fdboot.img (FreeDOS) for the example but they are not required.
> Accepting that this is a silly use of whichsys.c32, running the same thing
in both cases, it does illustrate the issue. When ALLOWEDOPTIONS is set to 0,
memdisk errors "No ramdisk image specified!" as it does not receive
the additional parameter. If you comment out ALLOWEDOPTIONS 0, then memdisk
loads the image without any trouble.
> Similarly, if I use a config that only has the ALLOWOPTIONS 0 line (no
vesamenu, etc.), "memdisk initrd=fdboot.img" will error "No
ramdisk image specified!". Again commenting out ALLOWOPTIONS 0 resolves
this.
> 
> My apologies for not providing the sample config previously!
> --Ian
> 
> > From: ady-sf at hotmail.com
> > To: syslinux at zytor.com
> > Date: Wed, 30 Apr 2014 02:32:05 +0300
> > Subject: Re: [syslinux] Issues with syslinux_run_command(str) and
parameters
> > 
> > 
> > > 
> > > Thanks Ady, you were spot on, and I should have tested that
scenario!
> > > I narrowed the issue down to a line in my config: 
> > > 
> > > 
> > > ALLOWEDOPTIONS 0
> > > 
> > > 
> > > The comment next to it in my config indicates this was added to 
> > > disallow users dropping to the console with Escape or Tab, a 
> > > restriction I would like to keep. BUT, when this is set whichsys 
> > > fails to function in the manner I described. And similarly if I
end
> > > up at the console prompt for any other reason and try to run 
> > > something, no parameters make it through).
> > > 
> > > 
> > > Is this expected? Seems a bit odd. 
> > > 
> > > Thank you very much!
> > > 
> > > --Ian
> > 
> > The directive you are referring to is "ALLOWOPTIONS 0" (no
"ED"),
> > which prevents users from editing commands. In other words, the user 
> > can only execute LABELs "as-is". Yet, I doubt this is the
(only)
> > problem.
> > 
> > My guess is that you are using another directive, "NOESCAPE
1",
> > which, when combined with additional directives ("PROMPT 0"
and/or
> > "UI"), prevents the possibility of "forcing" the
"boot:" prompt (with
> > either SHIFT / ALT / CAPS LOCK / NUM LOCK) at boot time.
> > 
> > In practice, "NOESCAPE 1" forces either the DEFAULT command
or the UI
> > directive (the latter takes precedence), thus preventing the 
> > possibility of using the CLI at *any* time, even after executing some 
> > other command.
> > 
> > So, take for example "ls.c32". Normally, after executing
"ls.c32" you
> > would end (back) at the CLI. But with "NOESCAPE 1", you jump
> > immediately to the UI directive (or, if UI is not used, to the 
> > DEFAULT command); the CLI is not allowed.
> > 
> > My guess is that something in your cfg is being (automatically) 
> > executed and then it is exiting (whether after failure or success) 
> > back to Syslinux. Since the CLI is not allowed (by "NOESCAPE
1"), the
> > Syslinux menu is seen again. Once the menu is loaded, the same entry 
> > is again automatically executed... producing a loop.
> > 
> > I don't really know yet whether you are actually using
"NOESCAPE 1".
> > Whichever the case, I would repeat my suggestion to post the content 
> > of your cfg file, so we might find out which command is failing (and 
> > therefore sending you to a loop).
> > 
> > Additionally, it could be helpful to double check the paths to your 
> > images. For instance, if you have "APPEND initrd=/myimage",
is
> > "myimage" really located in "/"?
> > 
> > Regards,
> > Ady.
> > 
> > _______________________________________________
> > Syslinux mailing list
> > Submissions to Syslinux at zytor.com
> > Unsubscribe or set options at:
> > http://www.zytor.com/mailman/listinfo/syslinux
>  		 	   		  
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux