"error: Unknown TPM error." after upgrading to grub 2.04

I have the same issue after upgrading to Kubuntu 19.10. I worked around it by disabling secure boot.

For me, the "Secure boot" option was disabled - however I did not find a separate TPM option and Windows (installed on a separate partition) claimed TPM is a active.

Status changed to 'Confirmed' because the bug affects multiple users.

I got the exact same error after upgrading from Ubuntu 19.04 to Ubuntu 19.10 on my HP EliteBook 820 G4. Disabling TPM in UEFI "solved" it for me. Seems to be a bug in grub2 package version 2.04 in Ubuntu 19.10. Seems they added UEFI TPM 1.2/2.0 support to grub2 version 2.04 in July 2019, but it obviously does not work for us.....

https://www.phoronix.com/scan.php?page=news_item&px=GRUB-2.04-Released

How do you disable TPM in UEFI ? I've got ASUS laptop and don't see any option with "TPM" in BIOS. Secure Boot is off.

I went to "TPM Embedded Security", set option "embedded security device availability" to "Hidden", and deactivated option "embedded security device state" as you can see in following video, which is only valid for certain HP laptops:

https://www.youtube.com/watch?v=gSooNBJ6QjQ

However, this will probably not help you, as the layout and menus on your ASUS laptop will be totally different.

I got the same error after upgrading from Ubuntu 19.04 to Ubuntu 19.10 on my Asus M32CD4-K desktop computer. Disabling TPM or Secure boot fixes the problem.

I have followed this troubleshooting procedure:

1) Booted to Windows 10 to install newest tpm firmware for my HP EliteBook 820 G4
 laptop using HP TPM Configuration Utility.
2) Booted to Ubuntu 19.10 (kernel 5.3.0-18-generic) with Secureboot enabled and TPM disabled
3) Purged and uninstalled all grub* packages (Yes, I know, pretty dangerous :-)
4) Only reinstalled following grub packages

~>apt list --installed|grep grub

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

grub-common/eoan,now 2.04-1ubuntu12 amd64 [installed,automatic]
grub-customizer/eoan,now 5.1.0-1 amd64 [installed]
grub-efi-amd64-bin/eoan,now 2.04-1ubuntu12 amd64 [installed,automatic]
grub-efi-amd64-signed/eoan,now 1.128+2.04-1ubuntu12 amd64 [installed]
grub-gfxpayload-lists/eoan,now 0.7 amd64 [installed,automatic]
grub-pc-bin/eoan,now 2.04-1ubuntu12 amd64 [installed,automatic]
grub-pc/eoan,now 2.04-1ubuntu12 amd64 [installed,automatic]
grub2-common/eoan,now 2.04-1ubuntu12 amd64 [installed]
grub2-splashimages/eoan,eoan,now 1.0.1+nmu1 all [installed]
grub2-themes-ubuntu-mate/eoan,eoan,now 0.3.7 all [installed]
grub2-themes-ubuntustudio/eoan,eoan,now 0.2 all [installed]
grub2/eoan,now 2.04-1ubuntu12 amd64 [installed]

5) Ran sudo update-grub2
6) Updated Ubuntu kernel to signed kernel version 5.3.0-19-generic

7) In UEFI, disabled SecureBoot and enabled TPM 2.0.

8) Successfully rebooted into Ubuntu 19.10 with TPM 2.0 enabled and SecureBoot disabled

~>dmesg | grep -i tpm
[ 0.000000] efi: ACPI=0xd9ffe000 ACPI 2.0=0xd9ffe014 TPMFinalLog=0xd9f76000 SMBIOS=0xd9765000 SMBIOS 3.0=0xd9763000 MEMATTR=0xd5f3c018 ESRT=0xd9766b18
[ 0.016058] ACPI: SSDT 0x00000000D9FEC000 0003B3 (v02 HPQOEM Tpm2Tabl 00001000 INTL 20160422)
[ 0.016061] ACPI: TPM2 0x00000000D9FEB000 000034 (v03 HPQOEM EDK2 00000002 01000013)
[ 4.129890] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 16)
~> uname -a
HP-EliteBook-820-G4 5.3.0-19-generic #20-Ubuntu SMP Fri Oct 18 09:04:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ ls -la /lib/modules/`uname -r`/kernel/drivers/char/tpm
total 172
drwxr-xr-x 3 root root 4096 Okt 22 10:58 .
drwxr-xr-x 9 root root 4096 Okt 22 10:58 ..
drwxr-xr-x 2 root root 4096 Okt 22 10:58 st33zp24
-rw-r--r-- 1 root root 11737 Okt 18 10:17 tpm_atmel.ko
-rw-r--r-- 1 root root 11697 Okt 18 10:17 tpm_i2c_atmel.ko
-rw-r--r-- 1 root root 16473 Okt 18 10:17 tpm_i2c_infineon.ko
-rw-r--r-- 1 root root 22721 Okt 18 10:17 tpm_i2c_nuvoton.ko
-rw-r--r-- 1 root root 22177 Okt 18 10:17 tpm_infineon.ko
-rw-r--r-- 1 root root 17017 Okt 18 10:17 tpm_nsc.ko
-rw-r--r-- 1 root root 11617 Okt 18 10:17 tpm_tis_spi.ko
-rw-r--r-- 1 root root 17361 Okt 18 10:17 tpm_vtpm_proxy.ko
-rw-r--r-- 1 root root 14585 Okt 18 10:17 xen-tpmfront.ko
$ ps -aux|grep tpm_dev
root 140 0.0 0.0 0 0 ? I< 12:52 0:00 [tpm_dev_wq]
$ ls -lart /sys/class/tpm/tpm0/
total 0
drwxr-xr-x 2 root root 0 Okt 22 13:22 ppi
drwxr-xr-x 2 root root 0 Okt 22 13:22 power
lrwxrwxrwx 1 root root 0 Okt 22 13:22 device -> ../../../MSFT0101:00
-r--r--r-- 1 root root 4096 Okt 22 13:22 dev
-rw-r--r-- 1 root root 4096 Okt 22 2019 uevent
lrwxrwxrwx 1 root root ...

I also blah, blah, blah, upgraded Kubuntu to 19.10 and updated to 5.3.0-19-generic.

System:
    ASUS GL553VE Laptop
    GPT Disk with EFI partition
    No TPM module installed that I can determine

BIOS:
    Latest == 308
    No TPM settings
    Turned off Secure Boot and CSM

GRUB Boot Error:
    error: Unknown TPM error. (multiple)
    error: you need to load the kernel first

FIX:
    Boot a broken system:
        'c' to command line
        grub> rmmod tpm
        'esc'
        Select any boot option to boot normally

    Fix GRUB once booted:
        sudo grub-install --no-uefi-secure-boot /dev/sd<your disk letter>
        reboot

I'm documenting my experience in the following details so that maybe somebody can figure it out and finally fix the effing thing.

Apparently, I had an older kernel {from 19.04?) that would boot even though I had a later kernel installed. I didn't notice the grub failures as I had:
  GRUB_TIMEOUT_STYLE=hidden
  GRUB_TIMEOUT=0
and the system was apparently failing. When I changed:
  #GRUB_TIMEOUT_STYLE=hidden
  GRUB_TIMEOUT=10
I thought I was borked! I rebooted and left it while I did some research. It apparently had time to fall back to the earlier working kernel which surprised me. In the attempt to clean the system, I did a "sudo apt autoremove" which really did bork my system as the fallback kernel was now gone.

I looked all over the intertubes and found little help--even this post, I fiddled with turning on and off the BIOS Fast Boot, CSM, and Secure Boot to no effect.

I guessed on trying to remove the tpm module during the grub boot as above. The grub documentation is VERY POOR at describing how specific modules get loaded. The tpm.mod file has no "insmod" command anywhere on the system. However, the /boot/grub/x86_64-efi/ directory has a moddep.lst file that shows the dependencies between modules and files: tpm <- verifiers <- normal <- many others. Automagically, tpm.mod gets loaded. I suppose I could have set a "rmmod tpm.mod" in a /etc/default/grub.d/40-custom.cfg file, but that didn't seem really elegant.

So, grub is apparently detecting and demanding Secure Boot even though it's off and the installed vmlinuz and initrd files can't get validated. I don't know why the earlier kernel didn't fail. I tried a manual boot with:
  grub> ls
    to get the disks
  grub> set root=(hd0,1)
  grub> linux /boot/vmlinuz-5.3.0-19-generic root=/dev/sda1
    Failed with the "error: Unknown TPM error."
  grub> initrd /boot/initrd.img-5.3.0-19-generic
    Failed with the "error: you need to load the kernel first"
    Of course!!! because "linux" failed to set linux
  grub> boot
    FAIL!
Then, I did:
  grub> rmmod tpm
    Complains with the "error: Unknown TPM error."
    But works because a repeat doesn't produce the error message
  Repeat "linux"
    No error
  Repeat "initrd"
    No error
  grub> boot
    SUCCESS!

Then, I eventually worked my way around to the "grub-install" man pages and saw the "--no-uefi-secure-boot" and "--uefi-secure-boot" switches. What if...YUP! Turning off UEFI Secure Boot for the grub install did it. Why the hell can't grub get it right from the BIOS settings? Why is tp...

Same here with Asus UX390.

On a 19.04 system, I don't see the /boot/grub/x86_64-efi/tmp.mod file--so added during the upgrade.

Speculation:
--------------------
So, the problem might be related to signed versus unsigned kernels. The earlier kernel was probably signed. The new kernels from the upgrade are probably not signed. Can't test right now, but will follow up with another laptop. I will upgrade to 19.10 in the same way.

Using command:
  dpkg --list | grep linux-image
to list kernels lists past kernels not currently installed. Example on a 19.04 system:
...
rc linux-image-5.0.0-20-generic 5.0.0-20.21 amd64 Signed kernel image generic
ic linux-image-5.0.0-21-generic 5.0.0-21.22 amd64 Signed kernel image generic
ii linux-image-5.0.0-31-generic 5.0.0-31.33 amd64 Signed kernel image generic
ii linux-image-5.0.0-32-generic 5.0.0-32.34 amd64 Signed kernel image generic
ii linux-image-generic 5.0.0.32.33 amd64 Generic Linux kernel image

I only have the -31- and -32- kernels installed as is seen in the /boot/ dir:

-rw------- 1 root root 8785656 Sep 30 13:38 vmlinuz-5.0.0-31-generic
-rw------- 1 root root 8785656 Sep 30 22:58 vmlinuz-5.0.0-32-generic

See possibly related Bug #1788727:
  https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1848892

My affected system is an ASUS Zenbook UX305FA with Secure Boot turned off. Thanks for all the hints, especially comment #10. My workaround was easy:
1. In grub menu, choose an entry and edit it (key press: e).
2. Add rmmod tpm in a line before the first insmod.
3. Boot with the modified entry (key press: F10).
4. The system might ask for a confirmation, but then it boots into 19.10.

Thanks you for the workaroune. If works for an Asus UX303!
Curiously, once restarted, no confirmation was required and no problem for further boots.

Good evening
I've got the same problem. My system is an desktop Asus 2O7HSV6 with Secure boot "on"...I'm not able to turn it "off"
No hints works till now:(((
I can't find TPM in BIOS
Any idea?
Many thks in advance

Hello,

Same problem. ASUS X556U
Comment #13 helped me to boot

Same problem with Asus UX3410U. I
TPM in BIOS was/is disabled.
I followed the instructions from #13 and I´m able to start Ubuntu. However, after the confirmation.
#15 - did you scroll down in the "Security" option of BIOS?

Asus UX330 here.
After upgrade to 19.10 failed because of mysql-core update error, I also had the TPM error even though I disabled secure boot in the BIOS.
Comment #13 fixed for me, thank you ! Do you know if there's a way to make it permanent in a boot option ?
Not sure if a more permanent fix should be implemented in GRUB or Ubuntu..

To make it permanent, see #10.

Specifically:

sudo grub-install --no-uefi-secure-boot /dev/sd<your disk letter>

The recipes of messages no x and y worked well for me. PC ASUS VIVO PC K31CD

The recipes of messages no 13 and 20 worked well for me. PC ASUS VIVO PC K31CD

I've already submitted a possible fix upstream for this issue (well, at least something that will stop this breaking, and give us more information to debug and fix it more permanently):

https://lists.gnu.org/archive/html/grub-devel/2019-10/msg00103.html

There isn't concensus there just yet, but I will prepare the SRU for this today, and I think this is a good candidate for releasing quicker than the usual 7 day waiting period in the -proposed repository.

This means I'll still need help from people to give us debug information once the patched version of GRUB is available so we can better understand what was going wrong exactly.

In the meantime, the best solution is to:

- Get to the GRUB menu
- Highlight the boot entry you wanted to run and hit E (for edit)
- At the top of the entry, add "rmmod tpm"
- Hit Ctrl-X or F10 to run the edited entry.

Removed block-proposed tag after doing one last smoketest to make sure grub was booting fine.

This bug was fixed in the package grub2 - 2.04-1ubuntu13

---------------
grub2 (2.04-1ubuntu13) focal; urgency=medium

  * debian/patches/ubuntu-tpm-unknown-error-non-fatal.patch: treat "unknown"
    TPM errors as non-fatal, but still write up the details as debug messages
    so we can further track what happens with the systems throwing those up.
    (LP: #1848892)
  * debian/patches/ubuntu-linuxefi.patch: Drop extra check for Secure Boot
    status in linuxefi_secure_validate(); it's unnecessary and blocking boot
    in chainload (like chainloading Windows) when SB is disabled.
    (LP: #1845289)

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 31 Oct 2019 17:58:47 -0400

Also reported for ubuntu 19.10 with kernel 5.3.7

I could see no logs upon boot, only a purple screen that appeared to hang forever. Disabling TPM in BIOS had no effect on the issue, as tpm is a kernel module it is automatically loaded upon boot.

The trick is to enter the grub 2.04 console by pressing c, and then entering

`rmmod tpm` feel free to run it again to make sure the module has been removed. That should do it

Then boot in with ctrl+x or F10

This is just a workaround and not a permanent fix, the entire community expects this bug to be fixed ASAP as there is not solution for it besides removing the module manually on each boot, or recompilling your kernel with the removed module. None of which is a long-term solution

I hope this helps somebody

Hello Stefan, or anyone else affected,

Accepted grub2 into eoan-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.04-1ubuntu12.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-eoan to verification-done-eoan. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-eoan. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Stefan, or anyone else affected,

Accepted grub2-signed into eoan-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2-signed/1.128.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-eoan to verification-done-eoan. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-eoan. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Adam,

I had also the boot issue on a Dell Optiplex 5050 even with TPM disabled.

After booting into 5.0.0-32 generic and upgrading grub2 to "2.04-1ubuntu12.1" I am still stuck while booting (and the color background of grub menu has switched to black).

lsb_release -rd
Description: Ubuntu 19.10
Release: 19.10

grub-efi:
  Installed: (none)
  Candidate: 2.04-1ubuntu12
  Version table:
     2.04-1ubuntu12.1 400
        400 http://be.archive.ubuntu.com/ubuntu eoan-proposed/main amd64 Packages
     2.04-1ubuntu12 500
        500 http://be.archive.ubuntu.com/ubuntu eoan/main amd64 Packages

sudo update-grub2
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.3.0-19-generic
Found initrd image: /boot/initrd.img-5.3.0-19-generic
Found linux image: /boot/vmlinuz-5.0.0-32-generic
Found initrd image: /boot/initrd.img-5.0.0-32-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
Found Windows 10 on /dev/sda1

@Adam Conrad (adconrad) : thanks for the updated packages. Seems to be solved now on my laptop. My laptop can now successfully enable TPM and Secure boot at the same time during boot

HP-EliteBook-820-G4 ~> dmesg|egrep 'ecure|tpm|TPM'
[ 0.000000] efi: ACPI=0xd9ffe000 ACPI 2.0=0xd9ffe014 TPMFinalLog=0xd9f76000 SMBIOS=0xd9765000 SMBIOS 3.0=0xd9763000 MEMATTR=0xd63c0018 ESRT=0xd9766b18 TPMEventLog=0xc50a8018
[ 0.000000] secureboot: Secure boot enabled
[ 0.000000] Kernel is locked down from EFI secure boot; see man kernel_lockdown.7
[ 0.016255] ACPI: TPM2 0x00000000D9FEB000 000034 (v03 HPQOEM EDK2 00000002 01000013)
[ 4.068308] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 16)
[ 4.158924] integrity: Loaded X.509 cert 'Hewlett-Packard Company: HP UEFI Secure Boot 2013 DB key:<restricted>

HP-EliteBook-820-G4:~$ apt-cache policy grub2-common grub2
grub2-common:
  Installed: 2.04-1ubuntu12.1
  Candidate: 2.04-1ubuntu12.1
  Version table:
 *** 2.04-1ubuntu12.1 100
        100 /var/lib/dpkg/status
     2.04-1ubuntu12 500
        500 http://de.archive.ubuntu.com/ubuntu eoan/main amd64 Packages
grub2:
  Installed: 2.04-1ubuntu12.1
  Candidate: 2.04-1ubuntu12.1
  Version table:
 *** 2.04-1ubuntu12.1 100
        100 /var/lib/dpkg/status
     2.04-1ubuntu12 500
        500 http://de.archive.ubuntu.com/ubuntu eoan/universe amd64 Packages

$ uname -a
HP-EliteBook-820-G4 5.3.0-21-generic #22-Ubuntu SMP Tue Oct 29 22:55:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Thanks to @Adam Conrad (adconrad) for the updated packages in eoan-proposed :
My laptop can now successfully boot with Secure boot enabled.

$ uname -a
Linux urbah-15 5.3.0-21-generic #22-Ubuntu SMP Tue Oct 29 22:55:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

$ dmesg | grep -i -e secure -e tpm
[ 0.000000] efi: TPMFinalLog=0x7ccdc000 ACPI 2.0=0x7c4c3000 ACPI=0x7c4c3000 SMBIOS=0x7d2f0000 SMBIOS 3.0=0x7d2ef000 MPS=0xfca00 ESRT=0x7a59d3d8
[ 0.000000] secureboot: Secure boot could not be determined (mode 0)
[ 0.010088] ACPI: TPM2 0x000000007C4F95A0 000034 (v03 Tpm2Tabl 00000001 AMI 00000000)
[ 0.622872] tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x200] vs fed40080 f80
[ 0.622877] tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x200] vs fed40080 f80

$ apt-cache policy grub2-common grub-efi-amd64-signed
grub2-common:
  Installed: 2.04-1ubuntu12.1
  Candidate: 2.04-1ubuntu12.1
  Version table:
 *** 2.04-1ubuntu12.1 500
        500 http://fr.archive.ubuntu.com/ubuntu eoan-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     2.04-1ubuntu12 500
        500 http://fr.archive.ubuntu.com/ubuntu eoan/main amd64 Packages
grub-efi-amd64-signed:
  Installed: 1.128.1+2.04-1ubuntu12.1
  Candidate: 1.128.1+2.04-1ubuntu12.1
  Version table:
 *** 1.128.1+2.04-1ubuntu12.1 500
        500 http://fr.archive.ubuntu.com/ubuntu eoan-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     1.128+2.04-1ubuntu12 500
        500 http://fr.archive.ubuntu.com/ubuntu eoan/main amd64 Packages

@Adam Conrad (adconrad) : Thanks for this updated package on proposal.
No more problems to boot with this package on my laptop : ASUS GL553VE

$ uname -a
Linux ub-eric 5.3.0-19-generic #20-Ubuntu SMP Fri Oct 18 09:04:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

$ dmesg | grep -i -e secure -e tpm
[ 0.000000] efi: TPMFinalLog=0x7aefb000 ACPI 2.0=0x7aa93000 ACPI=0x7aa93000 SMBIOS=0x7b2ec000 SMBIOS 3.0=0x7b2eb000 ESRT=0x789cd518
[ 0.000000] secureboot: Secure boot could not be determined (mode 0)
[ 0.014858] ACPI: TPM2 0x000000007AACDBC0 000034 (v03 Tpm2Tabl 00000001 AMI 00000000)
[ 0.765919] tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x200] vs fed40080 f80
[ 0.765937] tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer. [mem 0xfed40000-0xfed4087f flags 0x200] vs fed40080 f80

$ apt-cache policy grub2-common grub-efi-amd64-signed
grub2-common:
  Installé : 2.04-1ubuntu12.1
  Candidat : 2.04-1ubuntu12.1
 Table de version :
 *** 2.04-1ubuntu12.1 500
        500 http://fr.archive.ubuntu.com/ubuntu eoan-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     2.04-1ubuntu12 500
        500 http://fr.archive.ubuntu.com/ubuntu eoan/main amd64 Packages
grub-efi-amd64-signed:
  Installé : 1.128.1+2.04-1ubuntu12.1
  Candidat : 1.128.1+2.04-1ubuntu12.1
 Table de version :
 *** 1.128.1+2.04-1ubuntu12.1 500
        500 http://fr.archive.ubuntu.com/ubuntu eoan-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     1.128+2.04-1ubuntu12 500
        500 http://fr.archive.ubuntu.com/ubuntu eoan/main amd64 Packages

This bug was fixed in the package grub2 - 2.04-1ubuntu12.1

---------------
grub2 (2.04-1ubuntu12.1) eoan; urgency=medium

  * debian/patches/ubuntu-tpm-unknown-error-non-fatal.patch: treat "unknown"
    TPM errors as non-fatal, but still write up the details as debug messages
    so we can further track what happens with the systems throwing those up.
    (LP: #1848892)
  * debian/patches/ubuntu-linuxefi.patch: Drop extra check for Secure Boot
    status in linuxefi_secure_validate(); it's unnecessary and blocking boot
    in chainload (like chainloading Windows) when SB is disabled.
    (LP: #1845289)

 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 01 Nov 2019 15:16:43 -0400

The verification of the Stable Release Update for grub2 has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Thank you for comment #13, it solved my problem.