1

I had the problem of GRUB_TIMEOUT="1" having no effect. Just like in these questions 1 2 3. Setting GRUB_RECORDFAIL_TIMEOUT="1" accomplished what I needed. A related article. But I am not certain if this is the (GRUB-designer-)intended solution to my problem. Should I instead be fixing whatever is causing the recordfail to trigger in the first place?

How do I figure out what is causing recordfail to be triggered?

Observations/attempts:

  • I tried running both grub-editenv create and sudo grub-editenv - unset recordfail. Followed by sudo update-grub. No visible results.

  • In the file /etc/grub.d/00_header in the function make_timeout() there are the following lines:

if [ "\${recordfail}" = 1 ] ; then
  set timeout=${GRUB_RECORDFAIL_TIMEOUT:-30}
if [ "$recordfail_broken" = 1 ]; then
  cat << EOF
if [ \$grub_platform = efi ]; then
  set timeout=${GRUB_RECORDFAIL_TIMEOUT:-30}
  if [ x\$feature_timeout_style = xy ] ; then
    set timeout_style=menu
  fi
fi
EOF
fi

(I don't understand the syntax in the second excerpt and why there is an if-clause inside an if-clause.)

I changed the timeout in the second excerpt from 30 to 50 and, after sudo update-grub and a restart, observed that the GRUB timeout at boot was indeed 50 seconds.

  • I also verified that in the grub console at boot echo $grub_platform yields efi.

Extra info:

Current /etc/default/grub (the colors at the end don't work):

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT="0"
#GRUB_TIMEOUT_STYLE="hidden"
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR="`lsb_release -i -s 2> /dev/null || echo Debian`"
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/mapper/ubuntu--vg-swap_1 sysrq_always_enabled=1"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL="console"

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE="640x480"

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID="true"

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

#GRUB_HIDDEN_TIMEOUT="2"
GRUB_DISABLE_OS_PROBER="true"
GRUB_RECORDFAIL_TIMEOUT="1"

export GRUB_COLOR_NORMAL="green/black"
export GRUB_COLOR_HIGHLIGHT="light-green/black"

I think my system uses UEFI (laptop from 2017 maybe), but I'm planning to switch my boot to legacy (BIOS?) mode soonish (due to a kernel parameter needed for an SSD to boot).

I'm using LVM, but not encryption. /boot is on ext4 under LVM.

Kubuntu 18.04

  • 1
    What is the file system on your /boot? Are you using LVM or encryption? – Pilot6 Dec 27 '19 at 11:14
  • Once I noticed that plugged-in jack of headphone hanged the grub. – kenn Dec 27 '19 at 11:23
  • This is by design. – Pilot6 Dec 27 '19 at 11:27
  • 1
    You got it exactly. I argued that I can alway get into grub menu, but the maintainers left it this way, but added the RECORDFAIL option for brave people.)) In case you really can't get into grub, which is unlikely, you can always boot from a LiveUSB and revert the setting back. – Pilot6 Dec 27 '19 at 11:54
  • 1
    If a boot fails, grub can't record it to LVM. So there is a possibility that you are unable to get to grub menu to boot in safe mode or another kernel. That's the main reason. – Pilot6 Dec 27 '19 at 11:56

Browse other questions tagged or ask your own question.