search for: allowoptions

Hello, At the boot prompt ALLOWOPTIONS 0 is only applied to implicit kernels and not to labels. For configuration which want to allow selection, but prevent customization of the kernel command line, this behaviour is bad. Also the IMPLICIT 0 is applied to both the boot prompt and configuration setting (like DEFAULT); but one could argu...

I have some questions about "ALLOWOPTIONS 0". [quote] ALLOWOPTIONS flag_val If flag_val is 0, the user is not allowed to specify any arguments on the kernel command line. The only options recognized are those specified in an APPEND) statement. The default is 1. [/quote] My understanding of the behavior of "ALLOWOPTIONS 0&quo...

My summary: reviewing ALLOWOPTIONS found reasons for further reviewing 'ALLOWOPTIONS' Op 2014-07-12 om 04:35 schreef Ady: > > > I have some questions about "ALLOWOPTIONS 0". > > > > [quote] > > ALLOWOPTIONS flag_val > > If flag_val is 0, the user is not allowed to specify an...

> I have some questions about "ALLOWOPTIONS 0". > > [quote] > ALLOWOPTIONS flag_val > If flag_val is 0, the user is not allowed to specify any arguments on > the kernel command line. The only options recognized are those > specified in an APPEND) statement. The default is 1. > [/quote] > > My understandin...

Good day, If I set allowoptions to 0 to hide editing menu entries and then select to run lua.c32 from menu , run_command() from inside the script it seems to invoke kernel/com32 modules without any parameter. For example pxechn.c32 will never be happy no matter what the command line is. But if you set allowoptions to 1 everything...

...rhaps holding > shift to get to the console.. Hmm.) > > I would appreciate any suggestions :) > > Thank you,--Ian > >From the perspective of a final user, breaking the prior behavior of directives needs to have very clear advantages. The NOESCAPE (related to [esc]) and ALLOWOPTIONS (related to [tab]) directives have clear (and independent from each other) behaviors. Instead of changing their behaviors, the alternatives would be: _ to find available workarounds (which was already proposed); or, _ to add new directives. IIRC, there are no "Global Directives" that a...

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

...ble 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 will not work under ALLOWOPTIONS 0? A strict reading of the wiki would allow for this, as the subsequently loaded module does not have parameters in an append label: http://www.syslinux.org/wiki/index.php/SYSLINUX#ALLOWOPTIONS_flag_val Naturally given my situation here, I think it would be ideal if we could separate disabling use...

Hi, I have tried several different line options, but I cannot seem to get the pxe master password option to work? I have basically tried all combinations of: DEFAULT local PROMPT 0 ALLOWOPTIONS 1 TIMEOUT 500 MENU TITLE sometitle MENU MASTER PASSWD somepassword But just can't seem to get the menu to prompt for a password. version I have is pxe 3.31 Thanks for any help at all. Jer

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 possible scenario. All of these modules use syslinux_run_cmd() so parameters on the command line will not be received: - gfxboot.c32- cmd.c32- lua.c32- ethersel.c32- ifcpu.c32- ifcpu64.c32- ifmemdsk...

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

...ciate any suggestions :) > > > > Thank you,--Ian > > > > >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: 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...

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

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

...t; 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 possible scenario. All of these modules use syslinux_run_cmd() so parameters on the command line will not be received: > - gfxboot.c32- cmd.c32- lua.c32- ethersel.c32- ifcpu.c32- ifcpu64.c32- ifm...

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

Peter, Paulo reported some problems with his config files under ISOLINUX and PXELINUX - basically TIMEOUT and TOTALTIMEOUT were broken. The patches I've pushed to the elflink branch fix this and also fix parsing of the ALLOWOPTIONS config directive. The following changes since commit d5e02fb16a11bfdbce1e90a39e6cb5f2ad925389: get_key: Valid key values are positive (2012-04-17 11:25:53 -0700) are available in the git repository at: git://git.zytor.com/users/mfleming/syslinux.git elflink Matt Fleming (3): ldlinux:...

...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 will not work under ALLOWOPTIONS 0? A strict reading of the > wiki would allow for this, as the subsequently loaded module does not > have parameters in an append > label:?http://www.syslinux.org/wiki/index.php/SYSLINUX#ALLOWOPTIONS_fl > ag_val > > > Naturally given my situation here, I think it would be...

Hi all, I can't suppress TAB menu prompt and I wonder if this feature is working or not. I'm using extlinux and here is a cut from extlinux.conf: UI menu.c32 prompt 0 MENU TITLE MYPC MENU AUTOBOOT Automatic boot in # second{,s}... MENU NOTABMSG timeout 100 TOTALTIMEOUT 1800 label main MENU DEFAULT MENU LABEL Linux Kernel 3.x ... I'm using latest code from the git tagged as

...================================================================== --- syslinux-3.71-27-g3d39943.orig/core/keywords.inc 2008-08-31 22:45:26.000000000 +0200 +++ syslinux-3.71-27-g3d39943/core/keywords.inc 2008-08-31 22:45:28.000000000 +0200 @@ -75,6 +75,7 @@ keyword onerror, pc_onerror keyword allowoptions, pc_setint16, AllowOptions keyword noescape, pc_setint16, NoEscape + keyword labelcompl, pc_setint16, LabelCompl keyword f1, pc_filename, FKeyN(1) keyword f2, pc_filename, FKeyN(2) keyword f3, pc_filename, FKeyN(3) Index: syslinux-3.71-27-g3d39943/core/parseconfig.inc ==============...