Sometimes a BIOS update (UEFI, nowadays, but you get the idea) might cause strange power and/or boot issues with specific motherboards. While fixing a “freebie system” recently, we saw a UEFI that was struggling with “staying off”. There seems to be some issue either with the USB port or the keyboard, or something else. The behavior was occurring on cold boots and Shutdown Commands were rebooting the system, instead of turning it off, NO MATTER WHAT. Since this was a system that was intended to be “Always On”, such as XCP-ng / XenServer, we used this “workaround solution”:
~~]# cat /boot/efi/EFI/xenserver/grub.cfg
serial --unit=0 --speed=115200
terminal_input serial console
terminal_output serial console
set default=0
# the default for timeout_style is = menu
set timeout_style=countdown
if [ "${recordfail}" = 1 ]; then
unset recordfail
fi
set timeout=5
#######################################################
# CHANGES:
## (default) timeout_style=countdown ; timeout boots 1st option but "hides" the menu UNLESS keyboard press gets Shift, F4 or Esc keypress
## (added as wa) 'if recordfail then unset recordfail' ; forces timeout even after failed boot
#########################################################
menuentry 'XCP-ng' {
# ... rest of config...
The magic is in this conditional here: if [ "${recordfail}" = 1 ]; then
unset recordfail
fi
Apparently, if grub detects something went “wonky” either at last shutdown or during boot, the grub timer that usually “auto-selects” the “first menu option” will “go away” and leave you worse off than just a “wonky reboot or shutdown” by forever-waiting for you to hit the “Enter” key on a headless system. It may be an issue with USB initialization for the keyboard, and issue with the USB port or the keyboard sending some unknown key always on first boot, sometimes on reboot, result in “waiting for someone to hit Enter” on a remote host machine. Not awesome. Here’s a solution.
Good luck!