[Solved] Grub2 Timeout 30 seconds after today's update

[LanceM]

I now have a 30 sec timeout delay in booting after installing the new Grub2 and Grub-signed updates today. I checked ect/default/grub and default and timeout are still set at =0 . Any fix for this?

[gm10]

Any fix for this?

In a terminal window run:

Code: Select all

sudo sed -i "/recordfail_broken=/{s/1/0/}" /etc/grub.d/00_header

followed by

Code: Select all

sudo update-grub

The reason for the change is that the maintainer at Ubuntu doesn't know when to press Shift during boot and only know to bring up the menu via Ctrl+Alt+Del, which won't work with GRUB installed to an LVM partition, so they thought they'd just force 30 seconds of menu on everyone using EFI + LVM. Genius...!

[LanceM]

What exactly is "sudo sed -i "/recordfail_broken=/{s/1/0/}" /etc/grub.d/00_header"?
I tried it, but no change happened.

[hkindle]

Same problem.
Fix above did not work for me either.

Code: Select all

sudo -s update-grub

After the fix worked for me.

[gm10]

Thanks hkindle, sorry for failing to mention that. Added to my post above.

[LanceM]

Thanks Wondering if they issue an update, will it conflict with this CMD fix?

[gm10]

At worst an update overwrites it and you can apply my patch again.

[LanceM]

Thanks!

[JeremyB]

If this is happening on LVM, see https://bugs.launchpad.net/ubuntu/+sour ... omments/45

[gm10]

If this is happening on LVM, see https://bugs.launchpad.net/ubuntu/+sour ... omments/45

This is about LVM, but that bug is unrelated, the thread here isn't about a bug but this very intentional change:

Code: Select all

grub2 (2.02-2ubuntu8.10) bionic; urgency=medium
[...]
  [ Steve Langasek ]
  * debian/patches/quick-boot-lvm.patch: If we don't have writable
    grubenv and we're on EFI, always show the menu.  Closes LP: #1800722.

 -- Mathieu Trudel-Lapierre <cyphermox@ubuntu.com>  Wed, 09 Jan 2019 14:04:09 -0500

[mint-maniac]

I noticed this and tracked it also down to the same update change causing grub to always pop up. The change in grub refers to having an unsigned kernel.
I noticed that when I run dpkg -l linux and look for images, I'm seeing an unsigned kernel package (supposedly not installed) and a signed one installed.
This is after I uninstalled 4.15.0-44.47 (after upgrading to 4.15.0-45.57) and then reinstalling and rolling back to it (I did that after thinking the kernel update caused the issue rather than the grub update). It's possible that the churning created these two entries but after uninstalling 4.15.0-45.47, I'm not seeing remnants of it in dpkg (nor for any other kernel that I have uninstalled in the past) so I'm doubting that this kernel uninstall left something.

Anyway, are we supposed to see both a signed and unsigned package like this???

ii linux-image-4.15.0-44-generic 4.15.0-44.47 amd64 Signed kernel image generic
un linux-image-unsigned-4.15.0-44-generic <none> <none> (no description available)

[gm10]

Anyway, are we supposed to see both a signed and unsigned package like this???

Yes.

Also that's completely unrelated to this thread and the change in GRUB discussed here has nothing to do with unsigned kernels, either. For the solution to thread's issue, see my first reply to the thread. If you have a different issue, please make that a different thread.

Thanks!

This is what happens when you don't mark a solved thread as SOLVED (hint).

[Pjotr]

Sideline (as long as it isn't marked as solved):

Everybody who has checked the LVM box (in Ubiquity) during installation of Mint: are you sure that you had a good reason for doing that? If not, you shouldn't have checked that box at all.

In most cases, LVM is just an unnecessary complication with no advantages at all, which can cause serious trouble.

[mint-maniac]

The change log for the grub change is here:

https://launchpad.net/ubuntu/+source/gr ... ubuntu8.10

and specifically mentions checks for signed/unsigned kernels.

[LanceM]

Another related mystery. Doing a clean install of Mint 19.1 Cinnamon in UEFI mode using Ext4 for / resulted in no 30 boot delay. After completely updating the system, still no boot delay. Then cleaning the same SSD and doing the same install but using Btrfs as / resulted in the 30 second boot delay. Updating the system made no difference. How is this possible?

[oz42]

I have installed 19.1 twice on the same machine on btrfs. First time in BIOS mode, no problem. Second time in UEFI mode: grub2 delay is fixed at 30 seconds.

[Pjotr]

Why the (still rather experimental) BTRFS instead of the good old tried-and-tested EXT4?

[oz42]

Why not? THe machine (Notebook) has no important data. Good for a btrfs test.

[Pjotr]

Why not?

Well, maybe because you can experience some unexpected bugs and hitches from time to time. Like (possibly) an inexplicable increase in the Grub timeout.

[karlchen]

I have installed 19.1 [...] Second time in UEFI mode: grub2 delay is fixed at 30 seconds.

gm10 had explained why the 30 seconds occur and how to solve the issue a lot of posts above already: workaround/solution