Bugzilla – Bug 1166242
New error messages after installing Kernel:stable
Last modified: 2021-06-03 12:35:05 UTC
Created attachment 832414 [details]
I installed Kernel:stable as advised in bug#https://bugzilla.suse.com/show_bug.cgi?id=1165790
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
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.
What about the "MOK management" dialog?
After today's kernel update it appeared again.
You can ignore it as long as the kernel boots up :)
It's more about the secure boot.
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?
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.
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.
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 :-/
> 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?
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.
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?
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.