====== Sitemap ====== This is a sitemap over all available pages ordered by [[doku>namespaces|namespaces]].
Page Actions
Wiki Actions
User Actions
====== Differences ====== This shows you the differences between two versions of the page.
|
guides:pxe [2010/04/19 16:14] fishy Added some meat to the "getting fancy" section. |
guides:pxe [2010/04/19 17:39] (current) fishy Meat for the Nested Menus |
||
|---|---|---|---|
| Line 211: | Line 211: | ||
| <code> | <code> | ||
| # /var/lib/tftpboot/menus/common.cfg | # /var/lib/tftpboot/menus/common.cfg | ||
| - | DEFAULT vesamenu.c32 | ||
| MENU BACKGROUND menus/background.png | MENU BACKGROUND menus/background.png | ||
| ALLOWOPTIONS 1 | ALLOWOPTIONS 1 | ||
| Line 231: | Line 230: | ||
| Line for line description | Line for line description | ||
| - | * Load the vesamenu.c32 comboot module | ||
| * Set the background image (path relative to tftp root) | * Set the background image (path relative to tftp root) | ||
| * ALLOWOPTIONS 1 | * ALLOWOPTIONS 1 | ||
| Line 252: | Line 250: | ||
| ==== Nested menus ==== | ==== Nested menus ==== | ||
| + | |||
| + | So, we have our common configuration and COM32 modules ready. Let us modify pxelinux.cfg/default completely, and let it become our main menu. There are quite a few ways to build a complex menu system with syslinux. One approach is to use "MENU TITLE" to create submenus directly in the global configuration. This has the advantage that any LABEL of the menu and submenus can be typed directly on a prompt to boot. But, in my opinion, it also makes the menu vulnerable to errors in INCLUDE'd parts of the config. Another option is to chain-load the menus. This is related, but not as good, as the third option: loading each sub-menu as a COM32 module, with a separate complete config file for each sub-menu. | ||
| + | |||
| + | This is a reliable approach, and a flexible one when debugging. Every time you select a sub-menu, or to return to the main menu, the entire config is re-read and applied. So, you can test changes to the menu by navigating back and forth in it. This naturally implies that the vesamenu.c32 and sub-menu config files will | ||
| + | need to be transferred over TFTP every time you change menus, but in regard of the flexibility it gives for changing the menu on-the-fly is in my eyes a big plus, and the final selling point for me is the fact that a borken sub-config will not break my entire setup. | ||
| + | |||
| + | The initial main menu configuration looks like this: | ||
| <code> | <code> | ||
| # /var/lib/tftpboot/pxelinux.cfg/default | # /var/lib/tftpboot/pxelinux.cfg/default | ||
| + | DEFAULT vesamenu.c32 | ||
| MENU INCLUDE menus/common.cfg | MENU INCLUDE menus/common.cfg | ||
| MENU TITLE PXE Boot menu 0.1 | MENU TITLE PXE Boot menu 0.1 | ||
| Line 263: | Line 269: | ||
| Debian installers and live-boot options. | Debian installers and live-boot options. | ||
| ENDTEXT | ENDTEXT | ||
| - | KERNEL vesamenu.c32 | + | COM32 vesamenu.c32 |
| APPEND menus/debian.cfg | APPEND menus/debian.cfg | ||
| Line 280: | Line 286: | ||
| TIMEOUT 300 | TIMEOUT 300 | ||
| </code> | </code> | ||
| + | |||
| + | I choose to use the COM32 loader-keyword, opposed to KERNEL. Using KERNEL will normally auto-detect what type of image/boot-program it is trying to load by looking at the file suffix or magic number, it just feels more correct | ||
| + | to say COM32 when I know that is what I am going to load. | ||
| + | |||
| + | Note that the pxelinux.cfg/default is the only configuration file in my setup that has the line "DEFAULT vesamenu.c32" included. This is because for all the sub-menus, the module is already loaded by being the actual image "booted". | ||
| + | |||
| + | In all the sub-menus, I include a "Return to Main Menu" option on the top, to loads the default config and thus the main menu. | ||
| <code> | <code> | ||
| # /var/lib/tftpboot/menus/debian.cfg | # /var/lib/tftpboot/menus/debian.cfg | ||
| MENU INCLUDE menus/common.cfg | MENU INCLUDE menus/common.cfg | ||
| - | MENU TITLE Debian | + | MENU TITLE Debian Installers |
| LABEL mainmenu | LABEL mainmenu | ||
| - | MENU LABEL ^0 Return to Main Menu | + | MENU LABEL ^R Return to Main Menu |
| - | KERNEL vesamenu.c32 | + | COM32 vesamenu.c32 |
| - | APPEND graphics.conf ~ | + | APPEND ~ |
| + | |||
| + | MENU SEPARATOR | ||
| LABEL lenny_i386_install | LABEL lenny_i386_install | ||
| Line 296: | Line 311: | ||
| APPEND vga=normal initrd=debian/lenny/i386/initrd.gz -- | APPEND vga=normal initrd=debian/lenny/i386/initrd.gz -- | ||
| - | TIMEOUT 0 | + | TIMEOUT 900 |
| </code> | </code> | ||
| + | |||
| + | In the menus I am extensively using hotkeys. Hotkeys are identified my a caret (^) directly infront of the | ||
| + | character used as the hot-key. Hotkeys should be in the A-Z,0-9 range, to make sure that you are independent | ||
| + | of misc keyboard layouts. Hotkeys can also (naturally) only be assigned once in a single menu. If you asssign the same hotkey to multiple options, they will display as hot-keys, but none of them will be selected by pressing the key. | ||
| + | |||
| + | Seeing how I load the menus using the COM32 keyword with an APPEND line, you should be able to notice that there is really no limit on how deep you can nest your menus, and that it is fully possible to use the same menu as a "sub" in multiple places. | ||
| + | |||