I have this problem too like andrew700. I am on Ubuntu 20.04.
exec "apt show grub2-signed" shows that "No packages found".
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1814403
Title:
Latest update
I am experiencing this problem but am new to ubuntu and linux.
As above 'This bug was fixed in the package grub2-signed - 1.110.2',
please could someone provide some basing instructions for downloading
and updating grub2?
Many thanks
--
You received this bug notification because you are a
I just encountered the issue that the parameter GRUB_TIMEOUT in
/etc/default/grub does not reduce the timeout for uefi boot anymore. I
was able to pinpoint the issue in the grub config to line 98 [1]. From
your issue here I understand that this is the way it is supposed to
work.
This should be
This bug was fixed in the package grub2-signed - 1.110.2
---
grub2-signed (1.110.2) cosmic; urgency=medium
* Rebuild against grub2 2.02+dfsg1-5ubuntu8.2. (LP: #1814403) (LP:
#1814575)
-- Mathieu Trudel-Lapierre Tue, 05 Feb 2019
11:19:47 -0500
--
You received this bug
This bug was fixed in the package grub2 - 2.02+dfsg1-5ubuntu8.2
---
grub2 (2.02+dfsg1-5ubuntu8.2) cosmic; urgency=medium
[ Mathieu Trudel-Lapierre ]
* debian/grub-check-signatures: properly account for DB showing as empty on
some broken firmwares: Guard against mokutil
> If you still feel your system is showing the menu and timeout at every
boot unnecessarily, or if you feel the default timeout is too long,
please file a separate bug with the information specific to your system
and particular case so we can look into it
In this case please look into
You absolutely can change /etc/grub.d/00_header to change or remove the
code. The problem is; I don't think there is a way around us providing a
way to reach the menu for the those setups where "recordfail", the
feature that lets the boot menu start on failure, doesn't work, while
also making it
Two immediately above comments reference EFI boot. This bug report and
fix were regarding an original bug that appeared in non-EFI boot
environment.
It's possible your encountering a different bug or have an unclean EFI
--
You received this bug notification because you are a member of Ubuntu
I installed 2.02+dfsg1-5ubuntu8.2 on fresh 18.10 and I still have 30
seconds counter.
SSD layout is GPT with small esp partition, btrfs partition for @, and
swap.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I have an 18.04.2 desktop installation running grub2 2.02-2ubuntu8.12,
which is still pausing for 30 seconds at the grub menu on every boot.
The system is UEFI and running secure boot, with nVidia binary drivers
if that matters? The disk is an NVMe drive with two partitions. The
first is
Thanks for the quick fix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1814403
Title:
Latest update causes 30 sec. menu delay timeout
To manage notifications about this bug go to:
Verification-done on cosmic with grub2/2.02+dfsg1-5ubuntu8.2,
grub2-signed/1.110.2:
As expected, LVM in UEFI leads to a GRUB menu at boot, since it would
otherwise not be available. For LVMs on legacy BIOS, this does not
happen. I find this SRU is working correctly.
** Tags removed:
This bug was fixed in the package grub2-signed - 1.93.13
---
grub2-signed (1.93.13) bionic; urgency=medium
* Rebuild against grub2 2.02-2ubuntu8.12.
grub2-signed (1.93.12) bionic; urgency=medium
* Rebuild against grub2 2.02-2ubuntu8.11.
(LP: #1401532) (LP: #1814403) (LP:
This bug was fixed in the package grub2 - 2.02-2ubuntu8.12
---
grub2 (2.02-2ubuntu8.12) bionic; urgency=medium
* debian/grub-check-signatures: make sure grub-check-signatures conserves
its execute bit.
grub2 (2.02-2ubuntu8.11) bionic; urgency=medium
[ Mathieu
Verification-done for bionic using grub2/2.02-2ubuntu8.12 and
grub2-signed/1.93.13+2.02-2ubuntu8.12:
This fixes this issue for UEFI with /boot/grub on ZFS.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Dennis; when running the upgrade your GRUB_TIMEOUT may have been reset,
depending on what options you picked when prompted about the config
change.
Verification-done for bionic using grub2/2.02-2ubuntu8.12, grub2-signed/1.93.13:
I have run installs both with and without LVM on UEFI and on
Unwanted side effect: I have had my GRUB_TIMEOUT set to 300 so that grub
would wait for 5 minutes. Now that setting seems to have no effect. The
delay is now just 30 sec.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Fixed for me by the latest -proposed package. I'm running Bionic, non-
EFI, and was affected by the issue with the earlier package.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1814403
Title:
I just tested the packages in proposed for Ubuntu Bionic and I still see 30
seconds wait times after boot.
I have a particular configuration, which was done automatically by Ubuntu when
I freshly installed the system a while back.
I have an NVMe drive with two partitions, one is an LVM partition
Hello oshunluvr, or anyone else affected,
Accepted grub2-signed into bionic-proposed. The package will build now
and be available at
https://launchpad.net/ubuntu/+source/grub2-signed/1.93.12 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
Hello oshunluvr, or anyone else affected,
Accepted grub2 into bionic-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/grub2/2.02-2ubuntu8.11
in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: grub2-signed (Ubuntu Bionic)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1814403
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: grub2-signed (Ubuntu Cosmic)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1814403
** Also affects: grub2-signed (Ubuntu)
Importance: Undecided
Status: New
** Changed in: grub2-signed (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hello oshunluvr, or anyone else affected,
Accepted grub2 into cosmic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/grub2/2.02+dfsg1-5ubuntu8.2 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
** Also affects: grub2 (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: grub2 (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: grub2 (Ubuntu Bionic)
Status: New => Triaged
** Changed in: grub2 (Ubuntu Bionic)
Importance: Undecided
This bug was fixed in the package grub2 - 2.02+dfsg1-5ubuntu11
---
grub2 (2.02+dfsg1-5ubuntu11) disco; urgency=medium
[ Mathieu Trudel-Lapierre ]
* debian/grub-check-signatures: properly account for DB showing as empty on
some broken firmwares: Guard against mokutil --export
** Description changed:
+ [SRU Justification]
+ There is a behavior regression on non-EFI systems with the latest SRU of
grub2 which causes unnecessary boot delays.
+
+ [Test case]
+ 1. Install a system using BIOS mode with /boot on LVM.
+ 2. Reboot and verify that the boot menu is shown for 30
grub> if lsefi; then
> set foo=bar
> fi
error: can't find command `lsefi'.
grub> echo $foo
bar
Indeed, this is not working as expected. I'll work on finding another
option that lets us properly detect EFI at runtime.
** Changed in: grub2 (Ubuntu)
Status: Incomplete => Triaged
** Changed
On Mon, Feb 04, 2019 at 04:47:35PM -, oshunluvr wrote:
> Seems at a minimum the 00_header should be re-written to bypass the
> "lsefi" stanza if EFI is not in use.
The whole point of the 'lsefi' command is to check at runtime whether EFI is
in use. If you have not booted the EFI GRUB, the
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
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
As a user you do have the option of adjusting the timeout by setting
GRUB_RECORDFAIL_TIMEOUT to a different value in /etc/default/grub. I
strongly recommend that you not set it to 0.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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.
I believe it had to do with the patch debian/patches/quick-boot-
lvm.patch as described here:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1800722
Here's what I wrote in a comment (#12) there a couple days ago:
Seeing a regression here on 18.10/amd64 with 2.02+dfsg1-5ubuntu8.1 using
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: grub2 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1814403
Title:
** Tags added: regression-update
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1814403
Title:
Latest update causes 30 sec. menu delay timeout
To manage notifications about this bug go to:
37 matches
Mail list logo
