Leap 15.0/15.1 using UEFI Boot with Secure Boot - Booting freeze when GRUB2 is displayed

Hi,

I have a Toshiba laptop R930-17M with BIOS version 6.80.

In BIOS setup I have the options UEFI or CSM. When I select UEFI then there is another option activated which is Secure Boot.

I have installed Leap 15.0 (and after update it to Leap 15.1) with CSM boot mode in BIOS setup. Now I’m trying to activate both options UEFI and Secure Boot in BIOS setup I’m not able to boot from GRUB2 onwards (Laptop starts until it shows GRUB2 then freezes). If I enable only UEFI and disable Secure Boot then I’m able to boot sucessfully. If I activate Secure Boot then Laptop starts until it shows GRUB2 and then freezes. From my reading here https://en.opensuse.org/openSUSE:UEFI there should be something wrong with shim.efi but I don’t know what.

My BootOrder is as below:

linux:/home/mkk # efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0005,0000,0001,0004,0002
Boot0000* HDD/SSD PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,0,0)
Boot0001* ODD PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,1,0)
Boot0002* LAN2 PciRoot(0x0)/Pci(0x19,0x0)/MAC(b86b231e1018,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0004* LAN1 PciRoot(0x0)/Pci(0x19,0x0)/MAC(b86b231e1018,0)/IPv6(::]:<->::]:,0,0)
Boot0005* opensuse-secureboot HD(1,GPT,ad47db69-da10-4774-b33b-2f3603b62780,0x800,0x200000)/File(\EFI\opensuse\shim.efi)
linux:/home/mkk #

When I active the Secure Boot in BIOS setup, and the system boots after it boots and before arrives to GRUB2 stage it shows a message saying: “System BootOrder not found". Initializing defaults.”. If I remove all the entries in the BootOrder and leave only the Boot0005* opensuse-secureboot then next time I reboot the BIOS adds again the Boot0000, Boot0001, Boot0002 and Boot0004 entries to the BootOrder.

I have only 1 MOK enrolled key which is Opensuse Key:

linux:/home/mkk # mokutil --list-enrolled
[key 1]
SHA1 Fingerprint: 46:59:83:8c:82:03:fe:15:52:ad:19:e1:86:09:db:21:7e:3a:d2:4f
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
Validity
Not Before: Aug 26 16:12:07 2013 GMT
Not After : Jul 22 16:12:07 2035 GMT
Subject: CN=openSUSE Secure Boot CA, C=DE, L=Nuremberg, O=openSUSE Project/emailAddress=build@opensuse.org
Subject Public Key Info:


My disk structure above (removed Windows 7) and converted to a GPT disk:

linux:/home/mkk # fdisk -l /dev/sda
Disk /dev/sda: 465,8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: HGST HTS725050A7
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: D38B1133-308E-4855-AA76-067B8FEA7196

Device Start End Sectors Size Type
/dev/sda1 2048 2099199 2097152 1G EFI System
/dev/sda2 83892224 871915519 788023296 375,8G Linux filesystem
/dev/sda3 2099200 83892223 81793024 39G Linux filesystem
/dev/sda4 871915520 976773134 104857615 50G Linux filesystem

Partition table entries are not in disk order.
linux:/home/mkk # gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.

linux:/home/mkk # ls -la /boot/efi/EFI/opensuse/
total 3504
drwxr-xr-x 2 root root 4096 jun 6 22:31 .
drwxr-xr-x 5 root root 4096 jun 18 22:30 …
-rwxr-xr-x 1 root root 58 jun 6 00:05 boot.csv
-rwxr-xr-x 1 root root 155 jun 6 00:05 grub.cfg
-rwxr-xr-x 1 root root 1144 jun 6 21:51 grub.der
-rwxr-xr-x 1 root root 1062752 jun 6 00:05 grub.efi
-rwxr-xr-x 1 root root 124416 jun 6 00:06 grubx64.efi
-rwxr-xr-x 1 root root 1158688 jun 6 00:05 MokManager.efi
-rwxr-xr-x 1 root root 1144 jun 6 22:30 shim.der
-rwxr-xr-x 1 root root 1208968 jun 26 13:31 shim.efi
linux-lkt3:/home/owner # ls -la /boot/efi/EFI/boot/
total 1544
drwxr-xr-x 2 root root 4096 mai 29 19:20 .
drwxr-xr-x 5 root root 4096 jun 18 22:30 …
-rwxr-xr-x 1 root root 1208968 jun 6 22:40 bootx64.efi
-rwxr-xr-x 1 root root 358768 jun 6 00:05 fallback.efi
linux:/home/mkk #

I have tried from the OpenSUSE UEFI guide https://en.opensuse.org/openSUSE:UEFI the options of “Booting the Machine without vendor provided Keys” and also “Booting the Machine that supports only one signature with vendor provided Keys” but without sucess so far. I have also re-created the /boot/efi/EFI folder with the Microsoft/Boot folder (which was erased when I installed Opensuse Leap 15.0) and copied /boot/efi/EFI/opensuse/* into /boot/efi/EFI/Microsoft/Boot but without sucess.

My Yast Boot Loader shows:

  • Boot Loader:
    GRUB2 for EFI - **Enable Secure Boot Support: **
    Activated - Enable Trusted Boot Support:
    Activated

I’m trying to have a boot sequence with UEFI and Secure Boot activated in Opensuse but without luck so far (will keep only UEFI active for now).

I don’t know if the fact of having erased completly the disk (including the Windows EFI partition) when installed Opensuse Leap 15.0 had any impact on the Boot sequence issues appearing now or if this is a BIOS setup problem only resolved with a BIOS update.

Any sugestions are welcome.

Thanks,
MKK

Just for the sake of it: UEFI / Secure boot do not make your linux install safer. Whenever possible I try to avoid using it, but on laptops it’s impossible most of the times, due to BIOS/UEFI implementations by the manufacturors. In your case I’d stick to CSM.

The may I suggest that you just disable secure-boot and enjoy life.

From my reading here openSUSE:UEFI - openSUSE Wiki there should be something wrong with shim.efi but I don’t know what.

For your information, the “shim.efi” used with Leap 15.1 is identical to the “shim.efi” used with Leap 15.0. So if this worked with Leap 15.0, then your problem is not with “shim.efi”.

In practice, “shim.efi” calls “grub.efi”. And “grub.efi” has changed for Leap 15.1.

If you can get hold of the “grub.efi” from Leap 15.0, you might try that. And if it works with the “grub.efi” from Leap 15.0, but not with the “grub.efi” from Leap 15.1, then this is worth a bug report.

Note that I just checked. The “grub.efi” used by 15.0 is different from the “grub.efi” on the install media for 15.0, so there was probably an update at some time. But maybe testing with either of those would be interesting.

My BootOrder is as below:

linux:/home/mkk # efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0005,0000,0001,0004,0002
Boot0000* HDD/SSD PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,0,0)
Boot0001* ODD PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,1,0)
Boot0002* LAN2 PciRoot(0x0)/Pci(0x19,0x0)/MAC(b86b231e1018,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0004* LAN1 PciRoot(0x0)/Pci(0x19,0x0)/MAC(b86b231e1018,0)/IPv6(::]:<->::]:,0,0)
Boot0005* opensuse-secureboot HD(1,GPT,ad47db69-da10-4774-b33b-2f3603b62780,0x800,0x200000)/File(\EFI\opensuse\shim.efi)
linux:/home/mkk #

Boot0000 through Boot0004 are being generated internally by your UEFI firmware (or BIOS).

When I active the Secure Boot in BIOS setup, and the system boots after it boots and before arrives to GRUB2 stage it shows a message saying: “System BootOrder not found". Initializing defaults.”.

That suggests a firmware (BIOS) bug.

My suspicion is that your problems are all due to UEFI firmware bugs.

I don’t know if the fact of having erased completly the disk (including the Windows EFI partition) when installed Opensuse Leap 15.0 had any impact on the Boot sequence issues appearing now …

Unlikely.

However, earlier threads do suggest that there are problems with the Toshiba implementation of UEFI.

Hi,

Thanks a lot for your feedback.

It seems there is a recent version of BIOS available:

|
|

  • 29/08/2018

|BIOS Update|Toshiba|OS independent|7.00-WIN|World Wide|

I will try to perform the BIOS update and confirm if it addresses these issues.

Thanks,
MKK

Without Secure Boot: LUKS can be hacked by a modifying initrd and sending master key to a hacker’s server during standard user login to his/her system.

Some info about securing: Enhancing Secure Boot Chain on Fedora 29

I’m not sure what “Secure Boot” has to do with that. “Secure Boot” does not check the integrity of “initrd”.