> On Thu, 4 Dec 2014, Ady wrote: > > > Perhaps there should be a new MENU-type directive, so to force the > > screen to text mode (as opposed to leaving it in graphics mode for as > > long as it can be)? Perhaps this could also be useful when exiting a > > vesamenu to Syslinux CLI? > > Yes, please. To make this dependent *only* on the configuration of > the menu entry started is, IMHO, the only way to go. >If you want a per-label behavior, you could try adding a new menu entry: LABEL change2menu COM32 menu.c32 And replace your 'UI vesamenu.c32' with 'DEFAULT vesamenu.c32' (instead of your prior 'DEFAULT lunatics', and the LABEL lunatics should be placed as the first menu entry in your configuration file). With these changes, your default behavior is vesamenu, with the option to reload the same menu but using menu.c32. It is possible that these changes would allow you to launch the kernel as you wanted, without waiting for further developments. Regards, Ady.
On Thu, Dec 4, 2014 at 8:45 AM, Ady <ady-sf at hotmail.com> wrote:> >> On Thu, 4 Dec 2014, Ady wrote: >> >> > Perhaps there should be a new MENU-type directive, so to force the >> > screen to text mode (as opposed to leaving it in graphics mode for as >> > long as it can be)? Perhaps this could also be useful when exiting a >> > vesamenu to Syslinux CLI? >> >> Yes, please. To make this dependent *only* on the configuration of >> the menu entry started is, IMHO, the only way to go. >> > > If you want a per-label behavior, you could try adding a new menu > entry:Ady has an excellent point. Try the following instead: LABEL test MENU LABEL test COM32 pxechn.c32 APPEND pxebsd.0 Additionally, I'd suggest using the type-specific KERNEL-like directives (LINUX, COM32, PXE, etc) instead of the "guess and pray" directive KERNEL. -- -Gene
> > > On Thu, 4 Dec 2014, Ady wrote: > > > > > Perhaps there should be a new MENU-type directive, so to force the > > > screen to text mode (as opposed to leaving it in graphics mode for as > > > long as it can be)? Perhaps this could also be useful when exiting a > > > vesamenu to Syslinux CLI? > > > > Yes, please. To make this dependent *only* on the configuration of > > the menu entry started is, IMHO, the only way to go. > > > > If you want a per-label behavior, you could try adding a new menu > entry: > > LABEL change2menu > COM32 menu.c32 > > And replace your 'UI vesamenu.c32' with 'DEFAULT vesamenu.c32' (instead > of your prior 'DEFAULT lunatics', and the LABEL lunatics should be > placed as the first menu entry in your configuration file). > > With these changes, your default behavior is vesamenu, with the option > to reload the same menu but using menu.c32. > > It is possible that these changes would allow you to launch the kernel > as you wanted, without waiting for further developments. > > Regards, > Ady. > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >I'd like to clarify that my prior suggestion will still not give you a per-label behavior; it just lets you choose a simple menu system without the background graphics mode. It allows you to boot normally from vesamenu, and only use the normal menu when/if really desired. For a real per-label behavior, you can add new entries in your main configuration file: LABEL config1 CONFIG cfg1.cfg and then in the new cfg1.cfg file: PROMPT 0 DEFAULT mylabel LABEL mylabel KERNEL mykernel APPEND myoptions The result is that from your (vesa)menu you are going to the new cfg1.cfg, which is not using any menu but only a one-and-only entry. This entry is launched immediately and automatically from CLI. If launching the kernel from CLI (instead of doing it from vesamenu.c32) shows you the result you want, then this is a valid workaround IMHO. As Gene mentioned, instead of the KERNEL directive you could use something else. Regards, Ady.
On Thu, 4 Dec 2014, Gene Cumm wrote:> Ady has an excellent point. Try the following instead: > > LABEL test > MENU LABEL test > COM32 pxechn.c32 > APPEND pxebsd.0Thanks, that works! How do I use that in the generic case? The ?pxebsd.0? file can be called as? ? PXE loader ? COMBOOT (16-bit) ? DOS .COM ? Multiboot (although it switches back to 16-bit mode immediately) ? from its own bootsector, if installed on disc (blocklist) Normally I?d chain into it as COMBOOT, but that no longer works (this used to work for both ISOLINUX and PXELINUX, and the other two, although I rarely tested them). Now I?ve got a working method for PXELINUX, but that leaves the others still? Thanks, //mirabilos -- tarent solutions GmbH Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/ Tel: +49 228 54881-393 ? Fax: +49 228 54881-235 HRB 5168 (AG Bonn) ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg