VyOS 1.2-rolling and booting without GRUB interaction

Good. That was too easy to think of it!

Additional data points:

I have the identical issue with a Qotom bare metal install. (UEFI is 2019, so relatively recent)
It would potentially seem to be a “buggy UEFI implementation” (as described in the debian uefi wiki)
Question would there need to be a feature request to allow options to modify this upon Install image?
or a documentation update?
Note this is tried with 1.2 (built via docker) & 1.3 rolling release.
also with both installed.

Reason I believe it to be a buggy UEFI implementation is that I remove the SSD and put in another system, it boots up fine with proper countdown & no prompt.
or the VYOS installer doesn’t recognize the UEFI properly ?

Other test:
Install debian 8 UEFI only (CSM disabled) boots no problem. (get the color grub boot screen)
if I try and configure as CSM only, legacy only, also works.

Question:
Does the “install image” modify nvram
Seems like the AMI boot screen takes longer since installing vyos…

If I can provide any logs to help find the root cause, please let me know.

Thanks.

I’ve just run into this, too, on Qotom bare metal.

I notice this difference between a fresh install of 1.3-rolling:

set default=1
set timeout=5
serial --unit=0 --speed=115200
terminal_output --append serial
terminal_input console serial

And a working install on a Netgate box that started out life as 1.1.7:

set default=1
set timeout=5
serial --unit=1 --speed=115200
terminal_output --append serial
echo -n Press ESC to enter the Grub menu...
if sleep --verbose --interruptible 5 ; then
        terminal_input console serial
fi

It seems like there may be something interfering with Grub’s sense of input when using serial input via EUFI. If I disable the serial console entirely, then it boots up. And if I add the sleep before enabling terminal_input, then it also boots properly after two 5 second waits. But as shipped, it seems like Grub thinks you’ve pressed something, so it stops booting and waits for input.

I guess that sleep was in the old install to work around some troubles like this, and it’s since been dropped. But I guess it still needed in some situations. I’ve dropped the first sleep down to 1 second, and it works just fine (booting after 6 seconds of waiting).