zypper dup refers to BIOS

Using Tumbleweed version 20200122 with KDE, booting in EFI mode. After latest update the boot stops right at the beginning with a blue BIOS screen with the following options:

  • Continue to boot
  • Enrol MOK (what ist the meaning of the acronym MOK?)
  • Enrol key from disk
  • Enrol hash from disk

I selected the first option continue to boot. It booted alright and everything works but with the next boot the boot process stops again at the same blue screen. To boot normally what do I need to select?
Any help is appreciated. Cheers

Hi
That’s an update for the signing key, select “Enrol MOK” (Machine Owner Key) and enter the root user password, the signing key will be added to the database.

Thank you, malcolmlewis for your quick reply. But in a case like that how should a normal user know what to do. My first inclination was to select ‘Enrol key from disk’.

Hi
I think if you selected that, it would ask to browse for the file, I think your would back out of this option, but skipping and asking would be the best option. At the next kernel update AFAIK it will ask again :wink: I do note there have been a few Forum posts about enrolling the MoK…

That is a good question. And I’m not sure that there’s a good answer.

The first time that I saw this (maybe 2 years ago or so), I went with “continue to boot”. And that worked, but I got the same prompt the next time. I eventually worked out that I needed to enroll the key (probably due to discussions like this one).

If you use “continue to boot”, the worst that could happen is that boot would fail due to secure-boot checks. And you would then probably know to disable secure-boot so that you could boot.

I guess things could be setup so that you are notified about this when installing a kernel. But most people would not notice the message, because there is too much output from “zypper dup”.

This is not for BIOS, but for secure boot. You are not suppose to go there for Kernel 5.4. This is a bug of 20200121 snapshot. It was fixed on Dec.18th, but it seems to be a no end buggy loop.

You also have the option to wait for the delay and do nothing which is the procedure for a normal user. This is equivalent to continue boot. Selecting continue boot was OK here 2 days ago.

Now that it did not work and this is an additional bug, you must select enroll MoK.

To enroll MoK, the question to answer is yes. If not working and chances are high that it won’t, disable secure boot. Next time, if you see the option delete MOK, choose it.

Did not boot in MoK at all up to 20200121 snapshot:

Additional rpm output: 
SKIP: /etc/uefi/certs/188EA6FA.crt.delete is not in MokList 
5.5-rc-2-3
rc-4
SKIP: /etc/uefi/certs/1AA60533.crt is already enrolled 
5.5-rc5
Additional rpm output:
SKIP: /etc/uefi/certs/188EA6FA.crt.delete is not in MokList

file:///etc/uefi/certs/1AA60533.crt
file:///etc/uefi/certs/4659838C.crt
Checking for file conflicts:
( 1/43) Removing kernel-default-5.4.7-1.1.x86_64 
Additional rpm output:
SKIP: /etc/uefi/certs/F1C08E27.crt.delete is not in MokList
5.4.10
SKIP: /etc/uefi/certs/1AA60533.crt is already enrolled

20200118 Fresh install

5.5-rc7
Checking for file conflicts: 
( 1/43) Removing kernel-default-5.4.10-1.1.x86_64 
Additional rpm output:
SKIP: /etc/uefi/certs/F1C08E27.crt.delete is not in MokList

Fresh install 20200116-20200121: The bug is back.

Hi
Your not running a standard Tumbleweed install if you have the **5.5-rc7 **kernel, what your seeing is normal as that kernel is not signed. Current Tumbleweed (20200123) and 5.4.13-1-default

Our machine booted in MoK from Kernel 5.4.10 to 5.4.12 after running zypper dup and this is a bug (20200121). If continue boot doesn’t work, it is a second bug.

And, because there is nothing to enroll (same Kernel) there will be a third bug.

OP will see you must load the Kernel first and the Kernel will be unusable. Before Dec.18th, mainline Kernel would boot in MoK, it is not the case anymore.

Here, the bug is in stock Kernel since 20200121.

Hi
Not here on multiple tumbleweed machines with secure boot enabled, likely something introduced with the mainline kernel perhaps or your nvram/bios database if funky.

Good to know!

All we can say is that we clear all secure boot keys in the BIOS and set it back to standard mode before a fresh install. We do several clean install in a month.

Secure Boot remains a challenge here in TW. We adapt ourself and we force them to be better, not booting in MoK is already a great accomplishment.