Bug 1166242

Summary: New error messages after installing Kernel:stable
Product: [openSUSE] openSUSE Distribution Reporter: Suse User <suseino>
Component: KernelAssignee: Jiri Srain <jsrain>
Status: REOPENED --- QA Contact: Jiri Srain <jsrain>
Severity: Major    
Priority: P5 - None CC: suseino, tiwai
Version: Leap 15.1   
Target Milestone: ---   
Hardware: x86-64   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: journal excerpt

Description Suse User 2020-03-10 13:10:04 UTC
Created attachment 832414 [details]
journal excerpt

I installed Kernel:stable as advised in bug#https://bugzilla.suse.com/show_bug.cgi?id=1165790

What happened:

1. After reboot a new blue dialog appeared telling me something about "MOK" (no idea what this means). There was some other text too but I didn't have enough time to read it because the countdown timer was only 5 seconds. I think it had something to do with UEFI. This happened only one time. On next reboots it doesn't appear any more.

2. On *EACH* boot now I notice a few new initial messages:

[    1.382523] Couldn't get size: 0x800000000000000e
[    1.382558] MODSIGN: Couldn't get UEFI db list
[    1.382763] Couldn't get size: 0x800000000000000e
[    1.382975] Couldn't get size: 0x800000000000000e

I don't find these in journal though.

3. In journal I see a new "failed" message with a "BIOS bug" notice in journal (see attached journal excerpt).


Everything seems to work as expected so far but I thought I should report this as it might be an actual bug.


# uname -rvpi
5.5.8-1.gfb4c60d-default #1 SMP Fri Mar 6 07:52:20 UTC 2020 (fb4c60d) x86_64 x86_64
Comment 1 Takashi Iwai 2020-03-10 13:15:01 UTC
It's a know harmless message you can forget for now.

The upstream already worked on it, hopefully gets fixed in 5.6 kernel, but might be in 5.7 kernel.
Comment 2 Suse User 2020-03-12 11:07:29 UTC
What about the "MOK management" dialog?
After today's kernel update it appeared again.
Comment 3 Takashi Iwai 2020-03-12 11:09:52 UTC
You can ignore it as long as the kernel boots up :)
It's more about the secure boot.
Comment 4 Suse User 2020-03-13 11:00:22 UTC
Well, I do ignore it because I have no other choice.

However this doesn't seem normal. I have updated the kernel many many times for years but there has never been a case when after an update this Shim UEFI MOK management shows up. Now it has been just a few days and only 3 updates and after each one it shows up.

Why is that?
Comment 5 Suse User 2020-03-16 09:36:40 UTC
I am sorry but this is definitely causing trouble although I simply ignore the messages as per your advice.

Today something weird happend which has never happend before on this machine:

Background: yesterday evening I shut the machine down as usual. In the morning I power it on and:

On booting the machine 3 consequent beeps were heard, the monitor didn't power on. I pressed Reset on the box, the monitor powered on this time but there was no bootloader at all. The computer simply displayed the standard message which shows up when there is no OS or bootable media (as if it is brand new).

I entered the UEFI/BIOS setup and noticed that the boot entry for openSUSE was completely missing. Fortunately there is another one for an older installation of Windows 7 on this machine, so I could boot Windows and look for hardware failures - nothing. Everything works fine, all HDD smart statutuses are OK.

After rebooting the machine from Windows - strangely the entry for openSUSE reappeared in UEFI/BIOS setup and GRUB shows up now. However this definitely doesn't look normal and as I said - this has never happened before, on any version of kernel.
Comment 6 Takashi Iwai 2020-03-16 10:10:33 UTC
It happened in BIOS, far before booting up the kernel, so it's rather a BIOS problem.  Or at most an issue of GRUB or its installation.
Comment 7 Jiri Srain 2020-03-16 10:16:20 UTC
Is there anything suspicious you did with your computer before previous boot?

Really, beeps instead of starting the display is a firmware issue - not much we could do with :-/
Comment 8 Suse User 2020-03-16 13:03:53 UTC
> It happened in BIOS

The issue here (as commented earlier) is that the kernel update seems to be messing up with the UEFI. So it may have "happened in BIOS" but it did not happen by itself. As I explained - for so many years of using this same hardware with openSUSE it has never happened.

> Is there anything suspicious you did with your computer before previous boot?

I was expecting that question but the answer is really - no. In the evening I simply shutdown the machine and power it on in the morning. No updates were run before the shutdown or anything else that changes the OS. Just regular user work with documents.

> Really, beeps instead of starting the display is a firmware issue - not much we could do with :-/

Well, kernel-firmware got updated too since I switchted to Kernel:stable repo. If it has damaged anything - this makes the issue even bigger.

Also for some reason this 3-beep-no-power-on-monitor happened only once. I really don't know why. In any case the hardware itself is OK as I explained.

BTW (in the context of GRUB) after the issue I switched back to 4.12.14-lp151.28.40-default and I could see in boot that vmlinuz -> vmlinuz-4.12.14-lp151.28.40-default but for some reason by default GRUB keeps booting the 5.5.9 kernel. I had to go to GRUB configuration in Yast and manually tell it to boot 4.12.14 by default. Why is that?
Comment 9 Jiri Srain 2020-03-16 13:17:57 UTC
The probelm I see that without you finding the critical operation, which happened after the last successful boot before the problem, we have no way to find out what caused the problem.

If it was any related to previous kernel update, it would happen right after the kernel update was done (the next reboot), not some reboots later.

Because of this, I don't see much chance to find the cause of your problem from current information.
Comment 10 Suse User 2020-03-16 18:19:58 UTC
I understand the logic you follow however there is one irrevocable fact which stands out: no other kernel update in the past has caused a dialog related to UEFI key management. Ever. So regardless of the correctness of the logic you explain, the two things are obviously related. How exactly - I don't know.

What about my last question in the previous reply?
Comment 11 Suse User 2020-03-16 21:46:07 UTC
BTW... something that may be important.

Note the time of the file:

2020-03-14 11:53:41 vmlinuz-5.5.9-3.ge9e359d-default

On 14.March I did 'zypper up' and rebooted - no issues with 5.5.9 (except the UEFI key management dialog which I ignored as usual). That evening I did not shut down the machine. There were reboots during that day and the next one but no shutdown with power off. So I continued to work on 15.March too and shut down the system on 16.Mar (about 00:01). So this was the first time the machine was powered off after installing 5.5.9-3.ge9e359d. Then on the next morning the big problem appeared: 3 beeps etc.

I am mentiong this because there is a difference between reboot and power off and the kernel firmware may do different things.