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

> More context to this: syslinux_run_command calls into load_kernel(), and
somewhere behind load_kernel things break. This is also broken at the boot:
console prompt. Any commands executed at the boot: prompt also lose all
parameters.
> 
> > With the latest 6.03pre I'm seeing an issue where no parameters
are passed to the image executed via syslinux_run_command().
> > An example of this is whichsys.c32, which uses this. E.g., using an
example from the wiki page - whichsys.c32 -iso- chain.c32 hd0 -sys- chain.c32
hd1 swap - results in a loop back to the isolinux menu as chain.c32 receives no
parameters. Similarly, using -iso- memdisk initrd=/myimage.ima displays a
memdisk error saying no No ramdisk image specified!
> > As an awkward test to confirm the problem lies somewhere behind
syslinux_run_command, I replaced whichsys.c's call to
syslinux_run_command(str) with create_args_and_load(str). In this situation, the
whichsys chain.c32 example works without issue. (Of course, create_args_and_load
only supports com32 modules, so much of whichsys's load functionality is
lost. Not a good solution :).
> > 
> > Any ideas why parameters are being lost with syslinux_run_command?
> > --Ian 		 	   		  
 
Testing 6.03-pre11 official pre-built binaries (from kernel.org), in 
a BIOS-based VirtualBox 4.2.x VM, booting with either SYSLINUX or 
ISOLINUX, I don't see a problem.

I have not tested PXE nor EFI scenarios.

Have you tried using 6.03-pre11 (the latest ATM)? Are you using the 
official pre-built binaries from kernel.org?

Perhaps you might want to post the exact content of your cfg file.

Regards,
Ady.

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
> From: ady-sf at hotmail.com
> To: syslinux at zytor.com
> Date: Wed, 30 Apr 2014 00:14:39 +0300
> Subject: Re: [syslinux] Issues with syslinux_run_command(str) and
parameters
> 
> 
> > More context to this: syslinux_run_command calls into load_kernel(),
and somewhere behind load_kernel things break. This is also broken at the boot:
console prompt. Any commands executed at the boot: prompt also lose all
parameters.
> > 
> > > With the latest 6.03pre I'm seeing an issue where no
parameters are passed to the image executed via syslinux_run_command().
> > > An example of this is whichsys.c32, which uses this. E.g., using
an example from the wiki page - whichsys.c32 -iso- chain.c32 hd0 -sys- chain.c32
hd1 swap - results in a loop back to the isolinux menu as chain.c32 receives no
parameters. Similarly, using -iso- memdisk initrd=/myimage.ima displays a
memdisk error saying no No ramdisk image specified!
> > > As an awkward test to confirm the problem lies somewhere behind
syslinux_run_command, I replaced whichsys.c's call to
syslinux_run_command(str) with create_args_and_load(str). In this situation, the
whichsys chain.c32 example works without issue. (Of course, create_args_and_load
only supports com32 modules, so much of whichsys's load functionality is
lost. Not a good solution :).
> > > 
> > > Any ideas why parameters are being lost with
syslinux_run_command?
> > > --Ian 		 	   		  
>  
> Testing 6.03-pre11 official pre-built binaries (from kernel.org), in 
> a BIOS-based VirtualBox 4.2.x VM, booting with either SYSLINUX or 
> ISOLINUX, I don't see a problem.
> 
> I have not tested PXE nor EFI scenarios.
> 
> Have you tried using 6.03-pre11 (the latest ATM)? Are you using the 
> official pre-built binaries from kernel.org?
> 
> Perhaps you might want to post the exact content of your cfg file.
> 
> Regards,
> Ady.
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux

> 
> 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.