similar to: 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

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

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 -0500 > Subject: [syslinux] Issues with

> 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

Yes, MENU HIDE would work as well, but still requires additional entries for each case (possible entries for pxe, syslinux, isolinux, cpu architectures, PCI devices, lua scripting scenarios, etc.) By blocking modules, I meant that as long as I disable user editing of menu commands via ALLOWOPTIONS 0, I cannot use any of the following com32 modules without creating duplicate LABEL entries for each

>> >> >From the perspective of a final user, breaking the prior behavior of >> directives needs 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: >

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 intended functionality that modules such as whichsys

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

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

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

Hi I'm using syslinux 5.01 and is installing our bootloader using "extlinux --install /boot". In the extlinux.conf I've specified that the kontron_wdt.c32 program should boot another label once it has been executed but 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

Op 2014-05-05 om 23:20 schreef Ady: > > > 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 /

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

> >> > >> >From the perspective of a final user, breaking the prior behavior of > >> directives needs 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: > >

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

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 wrote a new module "whichsys.c32" which detemines which command to execute, based on the Syslinux bootloader variant. In the near future it should/can be replaced by a lua script. But for people who want small binaries: whichsys.c32 is +/- eighty times smaller than lua.c32, atm. Usage: whichsys.c32 [-iso- command] [-pxe- command] [-sys- command] Examples: whichsys.c32 -iso-

gfxboot uses those three calls, but currently doesn't really handle returns from them. syslinux_boot_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?

On Tue, Aug 13, 2013 at 3:21 AM, Bj?rn Damstedt Rasmussen <bjra at terma.com> wrote: > Hi > > I'm using syslinux 5.01 and is installing our bootloader using "extlinux --install /boot". In the extlinux.conf I've specified that the kontron_wdt.c32 program should boot another label once it has been executed but it never calls the second label. Did you build all of

> Hi > > I'm using syslinux 5.01 and is installing our bootloader using > "extlinux --install /boot". In the extlinux.conf I've specified that > the kontron_wdt.c32 program should boot another label once it has been > executed but it never calls the second label. > > Here's my extlinux.conf: > > default wdt > timeout 5 > prompt 1 >