[kernel-bugs] [Bug 1175626] Recent update run on August 21, 2020 kills bootloader
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1175626
https://bugzilla.suse.com/show_bug.cgi?id=1175626#c68
Gary Ching-Pang Lin
(In reply to John Shaw from comment #66)
The current certificate is MOK-nvidia-gfxG05-450.66-default.der, which is the same version as the driver. Presumably the actual keys would be different from install to install
yes.
At the time MokManager is running, the EFI environment of your BIOS is responsible to display the screen. It could be that this fails. MokManager uses EFI calls to switch the console to *from graphics to text mode*, actually; perhaps your EFI BIOS has an issue with text mode? It wouldn't be the first BIOS that fails at simple text mode. Whatever goes wrong here, I don't see how it could be related to the fact that you installed the Linux nvidia drivers and enrolled a certificate for them.
If its the underlying EFI BIOS that buggy, there is nothing to be done. I have the latest BIOS for my MB, but it was issued about 2 years ago. Its unlikely ASUS will issue any more updates for it, but I will keep watch for one. People running Windows have to occasionally start in safe mode, or bring up the ntldr boot menu for whatever reason. That would seem to be a screen in simple text mode, and by this point many many people would have reported if it did not work with this MB (ASUS z170A).
Is it possible that there is some simple bug in console.c that could account for this? (eg, a timing issue?) Just a thought.
Possible? Certainly. Likely? I doubt it, but I have to say my knowledge about these APIs is close to 0. It's also possible that MokManager dies and leaves the screen in an unhealthy condition (like old DOS games did when they crashed).
Gary?
The simple text protocol seems working well when SB is disabled. It's strange that MokManager couldn't draw the screen correctly when SB is enabled. I'll check the change in console.c between the old and new shim.
Both cards using the same driver?
yes, nVidia used to have separate drivers for consumer and pro products, but now there is just a single unified driver. 450.66 is the current long-lived stable one. Its officially supports both cards, so there is nothing funny here.
Well it COULD be that changing the graphics mode might confuse the BIOS somehow if there are multiple graphics cards. Just a wild guess, and I wouldn't know what to do about it.
If it's no big hassle for you, you might try if the problem goes away if you remove or disable the GV100 card.
Let me think about it (ie, its a hassle;). I don't really believe this has anything to do with anything, but I thought I would mention it. The theory about a bug in the BIOS being able to switch to text only mode makes the most sense to me.
Just strange that that happens only with SB on. In non-SB mode, MokManager seems to start just fine.
There seems to be no way to show a "simple" bios in text-only mode anymore. In the past, I have been able to run memtest86, which looks like it to has a text interface. I can try to boot that and make sure it still works.
I don't think the standard version works with UEFI. You need to get a special version of it.
Out of curiosity, why does MokManager come up if SB is disabled? Presumably there is nothing meaningful for it to do.
Excellent question. I guess it *can* enroll certificates in this mode (after all, MokList is just a regular boot-service UEFI variable). They just won't be used. From a paranoid point of view, I guess the MOK variables would need to be reset and everything re-enrolled after switching SB off and on. After all, with SB off, any untrusted EFI program could change the list at will.
For users who disable SB, this is just a confusing screen page. I would suggest that MokManager kick out immediately and pass control to grub if it determines SB is is not in effect. I can confirm the Linux believes SB is disabled when I disable it.
No dispute over the lousy and confusing UI.
Gary, please comment.
Well, it actually can be a workaround: disable SB and invoke MokManager to enroll the key and then enable SB. I believe the black screen is caused by MokManager due to the residual MOK variables, e.g. MokAuth. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com