similar to: ALLOWOPTIONS directive

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 any arguments on > > the kernel command line. The only

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

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 argue that only the command supplied at the prompt make sense to

Hello Syslinux Team, I have some suggestions / requests regarding global APPEND commands. These would make the behavior more consistent and more useful for practical cases. 1_ Add some functionality equivalent to "APPEND -" to the command prompt. 2_ Activate the functionality of ONERROR from [vesa]menu.c32 too. Currently, ONERROR only works from the command prompt. 3_ Add a new

I'm starting this thread to discuss what git repository should be designated as primary and which repositories should be designated as secondary. For years, git.kernel.org has been the primary repo, updated at least with every full and pre- release. git.zytor.com has been the secondary and development repo. Additionally, I've maintained my repos at github.com and git.zytor.com as

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 18/01/15 a las 13:18, Gene Cumm escribi?: > On Sun, Jan 18, 2015 at 6:44 AM, Angel <angelv64 at gmail.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> Hello. >> >> I'm trying to setup an multiboot USB, mainly to install Debian >> using netinst images. >> >>

> > http://www.syslinux.org/wiki/index.php/Common_Problems#Modules > > Shouldn't be enough copy modules from /user/lib/syslinux....? > 1_ Booting with Syslinux, in the Syslinux "boot:" prompt press "Ctrl+V" so to see relevant information. The c32 modules shall match the same version. 2_ The Current Working Directory is relevant, specially for relative

The config.c32 module (and the CONFIG directive) is not behaving as expected when using syslinux.exe 5.00pre11 as installer. To replicate: 1_ The content of the device: /dira /cat.c32 /config.c32 /ldlinux.c32 /ldlinux.sys /libcom32.c32 /pwd.c32 /syslinux.cfg /dira/dira.cfg 2_ Content of /syslinux.cfg: DEFAULT pwd1 PROMPT 0 LABEL config1 COM32 config.c32 /dira/dira.cfg APPEND /dira/ LABEL

On Sat, Jun 13, 2015 at 10:44:11PM +0300, Ady via Syslinux wrote: > > > I'm starting this thread to discuss what git repository should be > > designated as primary and which repositories should be designated as > > secondary. > > > > For years, git.kernel.org has been the primary repo, updated at least > > with every full and pre- release.

On Thu, 27 Jun, at 11:02:51PM, Thomas B?chler wrote: > Am 27.06.2013 22:08, schrieb Matt Fleming: > > I'm planning on releasing 6.01 next week. The list of changes (so far) > > are appended below. This is going to be a quick bug fix release, mainly > > because of the rather embarrassing bug in the 6.00 that prevents booting > > a Linux kernel on BIOS. The idea is to

Thanks. I've looked through all the links, and it seems everything is fine wrt. to what was mentioned there (I've disabled 64 bits in mke2fs, but it didn't help). I'd be glad to provide more details, but the error message is the only info I've got by now. It seems nothing else can be got from syslinux shell without modifiying the code. I've tried to make it load the kernel

Hi, I've just pushed out a last -pre release before 4.06 final. The purpose of this prerelease was to make sure that all the build infrastructure is configured correctly and to ensure that the win installer problem is now gone (I've done the build on an F16 machine which should have a working mingw toolchain). Barring any major problems I'll do the final release this week. -- Matt

Hello Syslinux Team, If I understand correctly (and I should emphasize that condition), the lib*.c32 library modules, when required, are initially searched-for according to the following (fallback) rules: 1_ Search for the relevant lib*.c32 file(s) in the Current Working Directory. 2_ Search for the relevant lib*.c32 file(s) in the directory where ldlinux.c32 is located. Then the lib*.c32

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

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 starts to work as expected, except the menu itself.

> 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

>Several points (please read the whole email before doing anything else): > >1_ It is not clear whether you still need/want to "avoid displaying" the menu border (i.e. make it transparent). You mentioned that you >eventually managed to do so, but then you also ask (again) about vesamenu.c regarding the menu border. Or, perhaps... Do you >actually, really, want to

Hi I have tried to install syslinux 4.06 on the SD card again, it works like a charm. I am being very carefull with c32 files from the same version bootloader. No success. I am also unmounting /dev/sdb1 before installing syslinux, as mentioned in the given documentations. In the pasted syslinux.cfg content--- I have also tried using only one DEFAULT directive. No success. syslinux boots

To the Syslinux mailing list administrator(s): There seem to be some issue when searching the Syslinux mailing list archives. To replicate (example): 1_ Open a Google web search page 2_ Search for "site:http://www.syslinux.org/archives/" 3_ Click "Search tools" 4_ Limit the search to "Past month". Result: no match! This has been happening for about 10 months or

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