Freeze at GRUB boot menu with Secure boot enabled (and constant reboot with BIOS Clear TPM enabled)

English Install/Boot/Login
1

The behavour noted in this post is an an old Toshiba Satellite Z930 Ultrabook (SSD hard drive with EFI BIOS). Previous it was successfully running openSUSE LEAP-42.2 and later LEAP-42.3 with BIOS settings SECURE boot Enabled, and with BIOS setting “Clear TPM” enabled. I previous blogged on the old LEAP-42.2 successful install here but I did not bother blogging about the successful LEAP 42.3 install.

Today I successfully installed LEAP-15.0 but had to disable Secure Boot to get this Ultrabook to both successfully install (else it would freeze at Grub) and also disable Secure boot subsequently (after openSUSE updates) to get it to reboot past Grub (else it would freeze at Grub). Further, I had to disable BIOS “Clear TPM” to get the PC to boot to BIOS after applying the latest openSUSE updates (a massive download).

Currently PC boots fine with Secure boot disabled and “Clear TPM” disabled, but given PC booted fine with Leap-42.2 and 42.3 with those both enabled, this new behaviour puzzles me. Any insights here?

DETAILS (only for curious)

With old openSUSE-42.3 in place, rebooted to the 64-bit USB/DVD on a USB stick. The USB boot would freeze at the Grub boot menu for installing openSUSE. I tried multiple USB ports and behaviour was identical. I went into Toshiba BIOS and disabled secure boot. Clear TPM was left at ‘enabled’.

I rebooted PC, and USB grub menu came up, not frozen, and I successfully installed openSUSE-LEAP-15.0. For this LEAP-15.0 install it was a fresh install with a replacement of / and I kept my old /home partition. I conducted a reboot to confirm all was ok, which it was. I then installed the massive ( > 2 GB) updates (which is quick as I have a fast internet connection).

I then (after the openSUSE updates with the latest stock kernel) rebooted the PC, and it constantly rebooted, BEFORE reaching the grub menu. This is the screen:
http://thumbs2.imagebam.com/31/61/95/557b8f1091264414.jpg](http://www.imagebam.com/image/557b8f1091264414)

If one presses a key, everything is frozen with no response. If one lets it time out (5-seconds) it reboots, … one has same screen, and another 5-second reboot … again to same screen, a 5-second timeout, and another reboot. After 5 reboots I pressed F2 into BIOS, and Enabled secure boot. That made no difference, … constant reboots prior to Grub menu. So I went into BIOS again, and this time disabled both Secure Boot and disabled “Clear TPM”. PC booted fine to openSUSE LEAP-15.0.

I then rebooted, enabled Secure boot, and left “Clear TPM” disabled. PC froze at GRUB menu. This was my last test.

I switched OFF ultrabook PC, switched back on to BIOS, disabled secure boot (and left “Clear TPM” disabled), and Ultrabook boots normally. This is BIOS appearance here:http://thumbs2.imagebam.com/02/cd/7f/ae87421091264424.jpg](http://www.imagebam.com/image/ae87421091264424)

I am now going to proceed and install my nominal apps, and configure the PC how I like, but this difference between LEAP-15.0 and earlier LEAP versions is puzzling to me.

2

What exactly this means? You cannot navigate menu? You can navigate menu for some time and then no more so cannot select boot entry? You can navigate menu, can select boot entry and then get no further feedback when selected entry starts boot?

3

If you still have them available, I suggest you try using the “grub.efi” and “shim.efi” from your 42.3 system. That may fix the system – at least until a grub2 update or shim update breaks it again.

In any case, you should probably report a bug on this.

NOTE: The “shim.efi” and “grub.efi” are probably gone from your EFI partition, overwritten by the Leap 15.0 install. However, if you still have a 42.3 system available, then you can actually find those two files in “/usr/lib64/efi”. And they will be there even for a system using MBR booting.

4

The behaviour was the grub menu would appear. The count down would remain stuck (ie not see the second count down) and keyboard pressing had no effect. So no navigation. Just a freeze. Power off was only action here for the laptop. This was fully reproduceable. When restarting (from OFF) I couple press F2 and go to BIOS menu.

5

Good idea.

Unfortunately - I did not think of that for this Ultrabook. I don’t have the files.

However I have another EFI system (a desktop) in which I wish to install LEAP-15.0 (which is running 42.3) and I’ll prepare better this next time (keeping those files), albeit I doubt I’ll see this on different hardware.

6

As a test you could try deleting (renaming) grub.cfg on USB medium. This will result in GRUB2 text mode command line. Does it work?

Also it is not clear - do you still boot in EFI mode after disabling Secure Boot?

7

You can copy those files over. They are not specific to your system. Every 42.3 user (on x86-64 hardware) gets the same “grub.efi” and “shim.efi”. Some of the other files vary from system to system, but not those two.

8

Ok, then that’s a good test … maybe tomorrow.

I’ll prepare a Live boot USB first, just in case I end up not being able to boot at all with the 42.3 files.

9

Maybe tomorrow I can give that a try.

Yes its still EFI mode to the best of my understanding of what I observe.

10

I had for me, what was an interesting ‘development’ on this openSUSE LEAP-15.0 boot.

nrickert and arvidjaar, before I attempted your tests (which involved ‘temporary’ changing some boot files), I thought it important to better characterise this Toshiba Ultrabooks unexpected boot behaviour (with Secure boot not working, and “Clear TPM owner” enabled causing an infinite reboot (after 5-second count down) before grub loading).

TPM behaviour change

So I tried various reboots with different BIOS settings for ‘Secure Boot’ and ‘Clear TPM owner’ using the LEAP-15.0 KDE live USB, and also using a Knoppix Live USB (as I wanted a separate distro to compare against).

Toward the end of these tests, while in the ‘infinite re-boot’ test with ‘Secure boot’ disabled, and 'Clear TPM owner" enabled , the 5-second count down before a reboot was within a fraction of a second of ending with the reboot starting. On this occasion I pressed the F2 key a bit prematurely (as I wanted to go to BIOS). Relevant may be that during a normal boot in this Toshiba, prior to grub loading, pressing F2 on this Ultrabook takes one to BIOS setting control. As you can see in the image above (in an earlier post), in the blue screen “Boot option restoration” screen, where it says “Press any key to stop system reset”, pressing any key (where previous I tried over a dozen keys) did not stop the reboot. I had assumed “Press any key” means ‘any key’. But in over dozen key presses (none of which stopped the system reset), I never tried the F2 key.

However this time, I pressed F2, and I obtained this screen :
http://thumbs2.imagebam.com/8b/f6/33/b1f01c1091976084.jpg](http://www.imagebam.com/image/b1f01c1091976084)

Its can’t been seen on my image, but at the top it instead says “Boot option restored” , and it has a menu selection in a box (which can be seen).

I pressed “continue boot” and to my surprise and interest it booted to LEAP-15.0 KDE desktop with ‘Clear TPM owner’ enabled. I rebooted the PC,and again I had the blue “Boot option restoration” screen. However this time during the 5-second count down before I reboot, I pressed F2, and again I obtained the blue “Boot option restored” screen. This time I pressed “Always continue boot” and the Ultrabook booted to LEAP-15.0. I tried a reboot, and again it booted properly to LEAP-15.0.

So that ‘TPM’ constant/infinite reboot issue, which was introduced when I updated openSUSE-LEAP-15.0 from a basic install to the latest stock RPMs, is no longer a problem (ie solved).

My suspicion is this could be Toshiba Ultrabook hardware specific, in how it relates to the openSUSE-LEAP-15.0 update. Given this blue screen and menu occurs before Grub loads, I think it a Toshiba Ultrabook issue, and Toshiba coders should have had the menu say ‘press F2’ instead of ‘press any key’.

As to why that TPM issue with a ‘Blue screen’ introduced only AFTER the first reboot AFTER the openSUSE LEAP-15.0 update, is not known to me.

The secure boot problem still exists, and I think that issue is more associated with your suggestions.

Live USB boot behaviour

I rebooted the Ultrabook a number of times with the KDE live USB (LEAP-15.0) and with a Knoppix Live USB(KNOPPIX_V8.2-2018-05-10-EN).

  • With both ‘Clear TPM owner’ enabled and Secure Boot enabled, the Ultra book display freezes with GRUB. No screen presses work. Countdown does not count down. The Knoppix liveCD also does not boot. wrt the Knoppix, no Grub menu appears - rather PC just freezes with a big Toshiba font on the screen.
  • With ‘Clear TPM owner’ enabled and Secure Boot disabled, the Toshiba boots to the LEAP-15.0 KDE live USB. The same is true wrt the Knoppix liveCD as it boots properly to the Knoppix GNU/Linux live USB with Secure Boot disabled.

Honestly, I am speculating this could be something Toshiba specific, with boot information in its EEPROM (?) affected by the openSUSE LEAP-15.0 install.

I’ll proceed later today with the tests nrickert and arvidjaar recommended.

11

I copied the two noted files from my desktop core i7 (running openSUSE-LEAP-42.3) to my Toshiba Ultrabook running openSUSE LEAP-15.0 (to the /boot/grub/EFI/opensuse directory) replacing the LEAP-15.0 files (which I first backed up in a separate directory).

I still get the same freeze with ‘Secure Boot’ enabled. It looks like this (below). http://thumbs2.imagebam.com/58/80/96/fa872f1092106754.jpg](ImageBam)

Note pressing any key does not affect the freeze. Further the ‘8S’ countdown does not countdown like it should. So this is more than just a keyboard freeze / failure to recognize.

I have a question here (as my knowledge in this aspect of openSUSE is weak). In /boot/efi/EFI/opensuse are the files “grub.efi” and “shim.efi”. There is also the file “grubx64.efi” (which you did not mention to copy). Should all 3 have been copied over?

12

No, just the two that I mentioned.

There are two ways of using grub2-efi:

First way: this is much like MBR booting. The file “grubx64.efi” is used, and has been compiled specifically for your system. It knows where to find “/boot/grub2/x86_64-efi” and it uses that to boot the system. There is no secure-boot support.

Second way: this is used with secure-boot. It starts with “shim.efi” which is signed by Microsoft to pass the secure-boot tests. It includes a certificate to verify signatures by openSUSE. It then loads “grub.efi”. As I understand it, “grub.efi” is pretty much the full grub2-efi, so it does not need to actually use “/boot/grub2/x86_64-efi”. Here “grub.efi” is signed (by openSUSE), while the modules in " /boot/grub2/x86_64-efi" are not signed. This method also requires “/boot/efi//EFI/opensuse/grub.cfg” which is a small text file that points to the “grub.cfg” in “/boot/grub2”.

When you installed, the default is secure-boot. That sets it up for the second way of booting, even if you disable secure-boot. The effect of disabling secure-boot is to skip the signature verification.

If you were to use Yast bootloader, and uncheck the box for secure-boot support, it should then switch to the first way of booting.

I expect arvidjaar will correct anything that I got wrong there. He’s the real expert on this.

In any case, I agree with you that what you are seeing appears to be specific to Toshiba firmware.

13

A question on this … I note grub.cfg is located in both

  • /boot/efi/EFI/opensuse
  • /boot/efi/EFI/boot

Which one should be removed in the USB medium for this test? Both ?

I am also assuming you refer to the LEAP-15.0 installation media and not the KDE live USB?

My knowledge in this area is pretty weak. Nominally this has just worked for me in the past, and I’ve been a bit lazy in researching it (until now).
.

14

I assume that he meant the one in “/EFI/BOOT” on the install or live USB. That path would be relative to the EFI partition on that USB device.

I am also assuming you refer to the LEAP-15.0 installation media and not the KDE live USB?

It should not matter for this test. Both start out the same way, and your system freeze, if it occurs, is before there are any important differences.

15

Ok, so I removed the /boot/efi/EFI/boot/grub.cfg from the LEAP-15.0 installation USB, and booted to the USB in SECURE BOOT = enabled. The text mode GRUB v.2.0.2 comes up with the GRUB prompt, but pressing any key on the keyboard has no effect. It appears that text mode is frozen, or the keyboard not recognized. Given the previous experience that the 8-second count down (in GRUB GUI mode) would not count down with ‘Secure boot’ enabled, I suspect Grub v.2.0.2 is frozen with Secure boot enabled.

As a sanity check, with the /boot/efi/EFI/boot/grub.cfg file removed, I went to the BIOS, disabled “Secure boot” and the Ultra booted to the text mode Grub, and this time I could enter text characters in the Grub prompt.
.

16

That certainly warrants bug report, especially if Leap 42 worked as far as I understand.