On reboot grub does not show delay countdown and does not start

Site Feedback
1

Version: 2026-03 stream
Hardware: Qotom Q750G5 1U Celeron J4125
BIOS set for automatic power on after power outage

As described in the title, on reboot and annoyingly, when recovering from a power outage Vyos gets stuck at the Grub menu. No seconds countdown and no automatic boot. On the other hand I do have another machine that has no issue restarting.

Searching the forums has not come up with anything similar and that is also true on a wider search. So I doubt that is some bug. At the very least it would have come up in testing upgrade I would think. So I’d be very grateful if someone would kindly point to an explanation/solution.

Thanks in advance
Regards
Philippe

2

Is this the first and only install or did you update VyOS from a previous version?

When Im looking in my fresh stream 2026.03 install (as in no previous installs or updates) I can see the following:

/boot/grub/grub.cfg.d/vyos-versions/2026.03.cfg

menuentry "2026.03" --id uuid5-68dfdd09-f0c4-5c2d-aae2-c44d85f6f013 {

/boot/grub/grub.cfg.d/20-vyos-defaults-autoload.cfg

set default="uuid5-68dfdd09-f0c4-5c2d-aae2-c44d85f6f013"
export default

Which gives that the selected default matches the id being used for the menuentry “2026.03”.

Which as I interpret this should force the default item that is 2026.03 to be booted no matter of previous selections.

So verify how that looks for the one that doesnt cooperate with you?

Otherwise when it comes to grub this seems to be the standard way to store which should be the next boot item:

GRUB_SAVEDEFAULT=true
GRUB_DEFAULT=saved

which VyOS currently doesnt seem to be using.

When comparing with lets say Proxmox they use a different approach:

/boot/grub/grub.cfg

if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi
  
export menuentry_id_option
  
if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}
3

Thanks for the reply.

For this particular router (R1):

  • this is a fresh install. Not an upgrade.
  • /boot/grub/grub.cfg.d/vyos-versions/2026.03.cfg is the only file in the directory.
  • /boot/grub/grub.cfg.d/20-vyos-defaults-autoload.cfg is identical to yours

On my regular router (R0), which has seen a fair number of upgrades, /boot/grub/grub.cfg.d/vyos-versions/ contains 8 *.cfg file, including 2026.03.cfg, which is also identical to that in R1 above.

uname -a has the same output on both routers, so same kernel, 6.6.128-vyos, 16-Mar-2026.

The files on R0 are mostly dated 26-Nov-2023 except for 20-vyos-defaults-autoload.cfg which is dated 09-Jul-2026 as expected. It appears that some of those files do not get overwritten on upgrade.

Only two of those files are different from the same on the more recent R1:

  • 25-vyos-common-autoload.cfg to set up a serial console.
  • 50-vyos-options.cfg where the older file has an extra menuentry for ttyUSB console.

Neither of those strike me as a potential issue with my problem. In fact, nowhere in these files did I see any reference to any delay before boot. Just to make sure, I rebooted R0 a couple of times, and I did not even have time to see the BIOS logo.

Best regards.

4

Which of R0 and R1 is it that gets stuck as you described in your initial post?

/boot/grub.cfg.d/20-vyos-defaults-autoload.cfg is the one that defines timeout to 5 seconds by default.

5

That would be R1.

And setting the timeout to 0 allows the system to boot, which solves the problem and leaves the question: why does the timeout not work?

Many thanks!
:smiley: