Grub header lsefi not working causing delayed grub menu

[mr_raider]

Here is my layout:

[#]

sudo parted /dev/nvme0n1
GNU Parted 3.2
Using /dev/nvme0n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: WDC WDS512G1X0C-00ENX0 (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 525MB 524MB fat32 EFI System Partition boot, esp
2 525MB 18.2GB 17.7GB linux-swap(v1)
3 18.2GB 470GB 452GB btrfs
[/#]

Here is /etc/default/grub

[#]

$ cat /etc/default/grub
# 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=3
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
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,0xe fefefef"

# 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_RECORDFAIL_TIMEOUT=7

[/#]

I should be getting a 3 second timeout, but I'm getting a a 7 second timeout.

I don't seem to have the "lsefi"

line either in grub.cfg or 00_header

[Snowhog]

Here is my layout:

[#]

sudo parted /dev/nvme0n1
GNU Parted 3.2
Using /dev/nvme0n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: WDC WDS512G1X0C-00ENX0 (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 525MB 524MB fat32 EFI System Partition boot, esp
2 525MB 18.2GB 17.7GB linux-swap(v1)
3 18.2GB 470GB 452GB btrfs
[/#]

Here is /etc/default/grub

[#]

$ cat /etc/default/grub
# 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=3
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
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,0xe fefefef"

# 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_RECORDFAIL_TIMEOUT=7

[/#]

I should be getting a 3 second timeout, but I'm getting a a 7 second timeout.

I don't seem to have the "lsefi"

line either in grub.cfg or 00_header

The seven seconds would seem to be coming from the GRUB_RECORDFAIL_TIMEOUT=7

From the Grub2 - Community Help Wiki:

Last Boot Failed or Boot into Recovery Mode

If the last boot failed or after a boot into Recovery Mode the menu will be displayed until the user makes a selection.
To change this behaviour, edit /etc/default/grub and add the variable GRUB_RECORDFAIL_TIMEOUT. Set the value similar to setting for GRUB_TIMEOUT.

• [*=left]For -1, there will be no countdown and thus the menu will display.
  [*=left]For 0, menu will not display even for a failed startup.
  [*=left]For >=1, menu will display for the specified number of seconds.

Run update-grub after the change have been made.
In some cases trick with GRUB_RECORDFAIL_TIMEOUT doesn't work. In such a case edit /etc/grub.d/00_header and change value of timeoutin line 236 (this line is in the make_timeout() function)

set timeout=-1to the the value as described above.
Run update-grub after the change have been made. Special thanks to McCunha on Ubuntu Forums for the above tip.
The above change, however, still causes GRUB2 to boot into text graphics mode. Thus, an additional change is required. Edit /etc/grub.d/10_linux and change line 188 to

set linux_gfx_mode=keep

Once again, run update-grub after the change has been made.

[mr_raider]

The seven seconds would seem to be coming from the GRUB_RECORDFAIL_TIMEOUT=7

I know. I put in that line to cut the boot down from 30. Note that the GRUB_TIMEOUT is being ignored.

[Snowhog]

Did you then follow:

In some cases trick with GRUB_RECORDFAIL_TIMEOUT doesn't work. In such a case edit /etc/grub.d/00_header and change value of timeout in line 236 (this line is in the make_timeout() function)

set timeout=-1 to the the value as described above.

[oshunluvr]

what's the output of;

cat /boot/grub/grubenv

[mr_raider]

[FONT=monospace]$ cat /boot/grub/grubenv
# GRUB Environment Block
##########################################################################################################################################
##########################################################################################################################################
##########################################################################################################################################
##########################################################################################################################################
##########################################################################################################################################
##########################################################################################################################################
##########################################################################################################################################
#################################
[/FONT]

[mr_raider]

I've been reading this:

https://bugs.launchpad.net/ubuntu/+s...2/+bug/1814403

I think this is intentional:

It is expected behavior that, after this SRU, some systems which are configured in such a way that /boot/grub is not writable by grub will take longer to boot. This is a boot speed regression, but it is not a functional regression; no systems should be failing to boot as a result of this change.
The change is deliberate and necessary because without it, it is impossible on a UEFI system to reliably access the boot menu. That means that if you ever had a kernel that fails to boot, you will be stuck with a non-bootable system and be unable to recover it from the grub menu (by booting the previous, working kernel).
So I believe this bug is 'wontfix'.

Changed in grub2 (Ubuntu):
status:	Confirmed → Won't Fix

Also,
> using EFI+btrfs boot volume. No LVM used, just GPT on NVMe.
Yes, this change was introduced to address the problem as seen on LVM-backed /boot/grub, but that is certainly not the only configuration for which GRUB has read support but lacks write support. The fix is generic to all such filesystems that are read-only in GRUB, and that is by design.

[oshunluvr]

Yeah, sounds like it. Annoying none the less.

[jlittle]

Firstly, if you're using btrfs, the generated grub.cfg says:

# GRUB lacks write support for btrfs, so recordfail support is disabled.

So the contents of the grubenv block are irrelevant. It looks to me that the recent change is to simulate the recordfail mechanism always failing.

Secondly, it is not necessary to use the generated grub.cfg. IMO it's simpler to use a minimal, hand coded, grub.cfg. The grub doc encourages this. In the long run, IMO it saves time and effort, partly because an update won't come along screw up the boot.

[mr_raider]

Yeah, sounds like it. Annoying none the less.

GRUB documentation should be updated to state that the timeout value no longer has any meaning.

Exactly why does grub need to write the boot partition?

[oshunluvr]

Exactly why does grub need to write the boot partition?

Not sure what exactly you're asking here, but AFAIK it doesn't during boot. It obviously does when you run update-grub.

As far as recordfail and btrfs, at least part of the issue there is the way the file system is managed and grub. A damaged btrfs subvolume would result in not being able to boot because grub couldn't read it's files, but wouldn't mean the file system is necessarily damaged. And the reverse could be also true. A damaged superblock wouldn't mean the data is compromised. BTRFS makes the whole recordfail process irrelevant.

Jlittle; I think we've discussed this before, but I run a quasi-manual grub system. I have GRUB installed to a stand-alone BTRFS subvolume that uses a custom boot menu. It allows me to pick from one of a list of whatever I have installed at the time. However, each installation (also in BTRFS subvolumes) maintain their own grub configs. This was how I discovered the above issue in the first place. MY grub booted fine but KDEneon's grub had the 30 second delay.