7

on my UEFI booting computer I installed an fresh Ubuntu 18.04.1 LTS using LVM partition scheme some months ago.

$ lsblk -f
NAME                          FSTYPE      LABEL        UUID                                   MOUNTPOINT
sda                                                                                           
├─sda1                        vfat                     79DE-0D6B                              /boot/efi
└─sda2                        LVM2_member              ZBlrfj-ZwAJ-2T3b-gUHr-eKVw-nhIi-9bQQTs 
  ├─ubuntu--vg-root   ext4                     e85edc94-cc00-42c5-8994-cbb835e8e315   /
  └─ubuntu--vg-swap_1 swap                     e699c892-4046-4d0b-957a-f936cc4c9973   [SWAP]

The first months every boot went as expected, what means the GRUB boot menu was only shown, if the system was not shut down correctly. So the well known recordfail feature seemed to work fine.

But then, some weeks ago, after an system upgrade to Ubuntu 18.04.2 LTS, the GRUB boot menu started to reveal itself at every boot, with a timeout of 30 seconds. Of course, in the long run this is annoying :-(

After inspecting the grub configuration file /boot/grub/grub.cfg I found out, that the recordfail feature was declared as broken regarding the usage of LVM?! The recordfail feature was disabled and therfore, GRUB keeps showing the boot menu at every boot.

  set recordfail=1
  # GRUB lacks write support for lvm, so recordfail support is disabled.

The source for this permanent disabled recordfail feature I found then in the further GRUB configration generating script /etc/grub.d/00_header in the check_writable() function.

    abstractions="$(grub-probe --target=abstraction "${grubdir}")"
    for abstraction in $abstractions; do
      case "$abstraction" in
        diskfilter | lvm)
          cat <<EOF
  # GRUB lacks write support for $abstraction, so recordfail support is disabled.
EOF
          return 1
          ;;
      esac
    done

As you can read, the author declared the two modules diskfilter and lvm to brake the recordfail feature, thus resulting in the annoying 30 seconds timeout at every boot.

So far this is the status quo and all things seem to work as expected... But, why did the recordfail feature work well in the first place? Is there a unresolved bug, which is the cause for disabling it? Am I the only person on earth running this constelation of bootloader and partition scheme? I'm looking forward, that some one can solve this mystery.

Thanks in advance

/EDIT I don't want to just get rid of the annoying GRUB boot menu timeout. Instead, I want to understand where the underlaying problem, for this behavior, is.

mrkskwsnck
  • 173
  • 2
  • 5
  • Welcome to AskUbuntu! Can you check to see of there is a recordfail marked in your grubenv? `grub-editenv - list` - please note the spaces on both sides of "-" are intentional. – Charles Green Feb 24 '19 at 21:35
  • @CharlesGreen Your command results in an empty output. This is a good sign, ain't it? – mrkskwsnck Feb 24 '19 at 21:40
  • It was worth a shot! Are you resuming from hibernate when this happens? I really have very little knowledge on the subject... – Charles Green Feb 24 '19 at 21:42
  • If you've had a failed boot (I have) there will be a line saying "recordfail=1", and apparently, this causes grub2 in Ubuntu to always use the recordfail timeout... [https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away](https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away) – Charles Green Feb 24 '19 at 21:45
  • I'm not using hibernation at all. Just restart or shutdown, respectively. Thanks anyway. – mrkskwsnck Feb 24 '19 at 21:45
  • The top answer in the question I sent describes using a grub variable to set the timeout back to x seconds - this does work for me, although it is an *undocumented grub function* – Charles Green Feb 24 '19 at 21:46
  • 3
    Possible duplicate of [Cannot get grub menu to timeout (or go away)](https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away) – Charles Green Feb 24 '19 at 21:47

2 Answers2

4

I just noticed this issue, too. It appears to be related to this change from January 9

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1800722

It looks like a bug has been submitted to fix the issue caused by the original bug fix

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1815002

Andrew Lowther
  • 5,811
  • 1
  • 15
  • 23
  • 2
    In addition to @andrew-lowther's provided bug reports I also found the following one: [Latest update causes 30 sec. menu delay timeout](https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1814403) – For me it describes this issue the best, so far. // In Short: GRUB simply cannot write to its files residing on the boot partition inside a LVM partition scheme. – mrkskwsnck Nov 16 '19 at 08:44
0

Workaround is to alter /boot/grub/grub.cfg manually and replace timeout=30 with timeout=2 (2 means 2 seconds here)

sudo sed -i.bak -- 's/set timeout=30/set timeout=2/g' /boot/grub/grub.cfg && diff /boot/grub/grub.cfg.bak '/boot/grub/grub.cfg'

It Creates backup file at /boot/grub/grub.cfg.bak. It must be done every time after update-grub, kernel update, etc.

Vouskopes
  • 1
  • 1