Grub header lsefi not working causing delayed grub menu

[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.

[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?

[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.

[oshunluvr]

Yeah, sounds like it. Annoying none the less.

[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.

[mr_raider]

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

[oshunluvr]

what's the output of;

cat /boot/grub/grubenv

[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.

[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]

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]

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

[oshunluvr]

Yes I'm using EFI. The bug appears on EFI too.

At this point, I don't necessarily agree - at least not with what info you've provided. While what you're seeing on the screen in front of you appears the same, that does not necessarily mean the cause is the same. The bug I reported and was addressed was specific to a non-EFI, GPT, non-LVM, environment. It may have also been related to BTRFS. Reading the bug report and all the comments should reveal this.

The appearance of the 30 second boot menu was due to a function called 'lsefi' that is missing from non-EFI installations of grub, but was referenced by a section in the 00_header file, which has now been fixed - it no longer appears in my grub.cfg.

It's possible you're encountering a different cause or even that the fix produced the problem. I suggest you go through the steps to validate what you're seeing, then log into the bug report and comment. Maybe it will get addressed immediately.

If I were you, I'd first verify that your grubenv is correct and reboot. Then edit grub.cfg and change the 30 seconds in the section I addressed to some other number and reboot. If the timer changes, that proves it's that section causing the problem, then go and report your findings. If not, the issue lies elsewhere.

Also, you can edit 00_header and change the 30 seconds in line 387 to something more to your liking. Then at least you don't have to look at it until another update to 00_header is released.

[mr_raider]

Yes I'm using EFI. The bug appears on EFI too.

Sent from my ONEPLUS A6003 using Tapatalk

[oshunluvr]

Yes.

No go.

Are you using EFI boot? This bug was specific to non-EFI environment.

[mr_raider]

Did you run sudo update-grub after updating the package?

Yes.

No go.