search for: syslinux_run_command

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

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

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. --Ian > From: ian at internals.io > To: syslinux at zytor.com > Date: Tue, 29 Apr 2014 13:55:39 -0...

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

...it never calls the second label. Here's my extlinux.conf: default wdt timeout 5 prompt 1 label linuxfoo kernel /vmlinuz append root=/dev/sda2 #.... more options label wdt com32 kontron_wdt.c32 append timeout=120 default_label= linuxfoo When I try to debug the kontron_wdt.c32 I can see that syslinux_run_command(..) returns -1. What could cause this? I've tried the ifcpu.c32 application as well (which is a bit similar to kontron_wdt.c32) and it also cannot call syslinux_run_command(). I can see that syslinux_run_command() call create_args_and_load() but if I put any printf's there they're not...

> I didn't see any further communication here; would anyone be > against my submitting/proposing a patch for this? Contributions are always welcome. > > I can see two possible approaches. One approach would be to > isolate the restriction on user commands away from > syslinux_run_command / load_kernel. > > Another would perhaps be to add support for a 'NOTAB' or > 'NOTABTOEDIT' option. There already exists a NOESCAPE setting, so > the remaining piece would be restricting tab. (And perhaps holding > shift to get to the console.. Hmm.) > > I w...

...her communication here; would anyone be > > against my submitting/proposing a patch for this? > > Contributions are always welcome. > > > > > I can see two possible approaches. One approach would be to > > isolate the restriction on user commands away from > > syslinux_run_command / load_kernel. > > > > Another would perhaps be to add support for a 'NOTAB' or > > 'NOTABTOEDIT' option. There already exists a NOESCAPE setting, so > > the remaining piece would be restricting tab. (And perhaps holding > > shift to get to the console....

...eds to have very clear advantages. > > Reviewing the commit history, I would say that the prior behavior is currently broken. > > The ALLOWOPTIONS feature was added in 2004: > http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=975a4c3b343c09a340d95f1a2a4ece3556c57a10 > And syslinux_run_command() in 2007: > http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=0b3b862ff49ab1b0b5d5af8c15d58e3c4baaf634 > > At this point, syslinux_run_command is using the equivalent of > create_args_and_load(), a function that is *not* negatively affected > by ALLOWOPTIONS. > > The...

...ot_linux (lib/syslinux/load_linux.c) can return ("bail" label). syslinux_local_boot (lib/syslinux/localboot.c) has a comment which says "returns only on failure". The documentation for "Local boot" in doc/comboot.txt says "Does not return". Which is correct? syslinux_run_command (lib/syslinux/run_command.c) should not return according to the comment in the source file. This seems compliant with the documentation of "Run command" in doc/comboot.txt. Can i assume gfxboot only needs to handle returns from syslinux_boot_linux() ? Sebastian

I didn't see any further communication here; would anyone be against my submitting/proposing a patch for this? I can see two possible approaches. One approach would be to isolate the restriction on user commands away from syslinux_run_command / load_kernel. Another would perhaps be to add support for a 'NOTAB' or 'NOTABTOEDIT' option. There already exists a NOESCAPE setting, so the remaining piece would be restricting tab. (And perhaps holding shift to get to the console.. Hmm.) I would appreciate any suggestions :)...

...ges. > > > > Reviewing the commit history, I would say that the prior behavior is currently broken. > > > > The ALLOWOPTIONS feature was added in 2004: > > http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=975a4c3b343c09a340d95f1a2a4ece3556c57a10 > > And syslinux_run_command() in 2007: > > http://git.zytor.com/?p=syslinux/syslinux.git;a=commit;h=0b3b862ff49ab1b0b5d5af8c15d58e3c4baaf634 > > > > At this point, syslinux_run_command is using the equivalent of > > create_args_and_load(), a function that is *not* negatively affected > > by ALLO...

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

...fcpu.c32- ifcpu64.c32- ifmemdsk.c32- ifplop.c32- whichsys.c32- rosh.c32 This doesn't feel like an intended restriction of ALLOWOPTIONS 0. --Ian > From: ady-sf at hotmail.com > To: syslinux at zytor.com > Date: Wed, 30 Apr 2014 05:06:55 +0300 > Subject: Re: [syslinux] Issues with syslinux_run_command(str) and parameters > > > > > > I did confirm earlier that this does work, and combined with a MENU > > HIDDEN to hide it from the visible menu it is a possible solution. I > > originally assumed that this was due to that going down a different > > code pat...

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

Try the following and let us know. If it doesn't work, we'll try other alternatives. *** DEFAULT vesamenu.c32 ALLOWOPTIONS 0 LABEL test COM32 whichsys.c32 APPEND -iso- iso -sys- sys LABEL iso LINUX memdisk APPEND initrd=fdboot.img LABEL sys LINUX memdisk APPEND initrd=fdboot.img *** Regards, Ady.

> > I did confirm earlier that this does work, and combined with a MENU > HIDDEN to hide it from the visible menu it is a possible solution. I > originally assumed that this was due to that going down a different > code path and did not mention it, apologies.?The scale of my menu > makes doubling/tripling menu entries less ideal, though.? > > > Do we consider it

...on here, I think it would be ideal if we could separate disabling user edits & commands from blocking modules loading other modules, etc. :) --Ian > From: ady-sf at hotmail.com > To: syslinux at zytor.com > Date: Wed, 30 Apr 2014 03:36:35 +0300 > Subject: Re: [syslinux] Issues with syslinux_run_command(str) and parameters > > Try the following and let us know. If it doesn't work, we'll try > other alternatives. > > *** > > DEFAULT vesamenu.c32 > ALLOWOPTIONS 0 > > LABEL test > COM32 whichsys.c32 > APPEND -iso- iso -sys- sys > > LAB...

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

...int i; + + openconsole(&dev_stdcon_r, &dev_stdcon_w); + + for (i = 1; i < argc; i++) + len += strlen(argv[i]) + 1; + + tmp = cmd = alloca(len); + + for (i = 1; i < argc; i++) + tmp += sprintf(tmp, "%s%s", argv[i], (i == argc-1) ? "" : " "); + + syslinux_run_command(cmd); +} -- 1.5.4.3

...; > default wdt > timeout 5 > prompt 1 > > label linuxfoo > kernel /vmlinuz > append root=/dev/sda2 #.... more options > > label wdt > com32 kontron_wdt.c32 > append timeout=120 default_label= linuxfoo > > When I try to debug the kontron_wdt.c32 I can see that syslinux_run_command(..) returns -1. What could cause this? What string would the above config pass to syslinux_run_command()? Does it have a trailing line end character? terminating NUL character? > I've tried the ifcpu.c32 application as well (which is a bit similar to kontron_wdt.c32) and it also cannot ca...