[Bug 1814403] Re: Latest update causes 30 sec. menu delay timeout

[oshunluvr]

Not using EFI here at all; BTRFS+GPT but no EFI. IMO forcing reference
to EFI when it doesn't exist is poor programming for a universal tool
like a boot manager. EFI should be included but gracefully enough not to
cause problems. If the strong recommendation is to not set
GRUB_RECORDFAIL_TIMEOUT to zero, why is it acceptable to delay boot for
functionality that doesn't exist?

Seems at a minimum the 00_header should be re-written to bypass the
"lsefi" stanza if EFI is not in use.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1814403

Title:
  Latest update causes 30 sec. menu delay timeout

Status in grub2 package in Ubuntu:
  Won't Fix

Bug description:
  KDEneon LTS user edition 5.12, Release 18.04

  grub-common 2.02-2ubuntu8.10 from Ubuntu updates

  Since latest update near the end of Jan. 2019 (29th?), grub menu has
  30 second delay every reboot as though recordfail is set. It did not
  do this before the update.

  After messing with grubenv and recordfails settings, I found this
  paragraph in 00_header in 18.04 that is not in 16.04:

  if lsefi; then
    set timeout=30 
    if [ x$feature_timeout_style = xy ] ; then
      set timeout_style=menu
    fi
  fi

  Note "timeout=30" which is the same as the recordfail timeout. As a
  test, I edited /boot/grub/grub.cfg and changed the 30 to 17 and sure
  enough, that's the source of the timeout.

  Here's the paragraph from 00_header:

  if lsefi; then  set timeout=${GRUB_RECORDFAIL_TIMEOUT:-30}
    if [ x\$feature_timeout_style = xy ] ; then
      set timeout_style=menu
    fi
  fi

  One odd thing is the 00_header file is from Jan 9th but this bug has
  just appeared so it must be related to grub-common not the the header
  file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1814403/+subscriptions