[syslinux] Fallback to second menu entry, ONERROR looping forever

[Gene Cumm]

On Sun, Sep 24, 2017 at 4:44 PM, Kristian Klausen via Syslinux
<syslinux at zytor.com> wrote:
> Hello
>
> I want to fallback to a second boot entry, if the kernel is missing for
> the first entry.
>
> So I through I could use ONERROR, but syslinux just continue to try
> starting the first entry.
>
> Am I doing something wrong? or can't this be done with syslinux?

I snipped the config to later.

> - Kristian Klausen

What version of Syslinux from what build/source is being used?


On Wed, Sep 27, 2017 at 12:43 AM, TorgeirW via Syslinux
<syslinux at zytor.com> wrote:
> Hi!
>
> I think thats the whole point with ONERROR.
> We use it in PXELINUX with a reload label.
>
> So we can reload pxelinux (ONERROR) if someone types something wrong “intall» instead of «install».
>
> —
> Torgeir

It is the point of ONERROR however, the menu might be adding to confusion.

I personally try to use uppercase on the directives as it makes
knowing what is or is not directives a little easier.

Let's look at the emailed config:

> default menu.c32

This should be:

DEFAULT grub
UI menu.c32

Though to see what's wrong, I'd suggest commenting out the "UI" line.

> prompt 0

For diagnostics, let's use "PROMPT 1".

> MENU HIDDEN
> MENU AUTOBOOT
> TIMEOUT 2

For testing, I'd suggest increasing TIMEOUT to a human value of say
600 (60 seconds) or set to 0 (around 13 years).

> ONERROR live-generic
>
> label grub
>      menu label ^Grub
>      menu default
>      linux /boot/grub/lnxboot.img
>      initrd /boot/grub/core.img
>
> label live-generic
>      menu label ^Live (generic)
>      linux /live/vmlinuz
>      initrd /live/initrd.img
>      append boot=live quiet splash nonetworking

Your LABELs are clean names and non-ambiguous in the first character.
You've used MENU LABEL for human descriptions with special characters
like spaces and parentheses.  With the change to DEFAULT, there's
almost no need for MENU DEFAULT though it shouldn't be hurting
anything.

I seem to recall something about error-like conditions not triggering
a proper error state and using ONERROR but at least these changes
should show more of what's going on underneath.

-- 
-Gene