Bug 1173682 - Changes needed in Release Notes about unsigned kernel modules and Secureboot Mode on Leap 15.2
Changes needed in Release Notes about unsigned kernel modules and Secureboot ...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Release Notes
Leap 15.2
x86-64 Other
: P5 - None : Major (vote)
: ---
Assigned To: Stefan Knorr
Lubos Kocman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-07-03 12:08 UTC by Matthias Bach
Modified: 2020-08-13 07:13 UTC (History)
13 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
martin.wilck: needinfo? (opensuse)


Attachments
Patch proposal for release notes (2.48 KB, patch)
2020-07-23 10:05 UTC, Stefan Dirsch
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Bach 2020-07-03 12:08:02 UTC
After upgrading openSUSE on my secure-boot enabled system from 15.1 to 15.2 I can no longer load the NVIDIA kernel module. That is, `modprobe nvidia` returns an error:

modprobe: ERROR: could not insert 'nvidia': Operation not permitted

And this is also reflected in the kernel messages:

Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7

While, rereading the release notes after the fact, I assume this is expected as the kernel module is actually built in the post-install hook of the driver package, the release notes here are—even for the experience openSUSE user that I count myself as—misleading at best. While stating that drivers from vendor repositories won't work, the explicit linkage to the NVIDIA page in SDB, which makes no mention of potential secure-boot issues, makes it sound like one will be fine when following the official way. Especially if, after reading messages like [1], one assumes that SUSE is involved in the creation of these packages.

[1]: https://lists.opensuse.org/opensuse-factory/2017-08/msg00397.html
Comment 1 Ricardo Minnaard 2020-07-07 13:05:16 UTC
Having the same issue.

modprobe: ERROR: could not insert 'nvidia': Operation not permitted

This with the drivers from the NVidia repo as well as the ones from the download page on their site (if you even can get them installed).
Comment 2 Ricardo Minnaard 2020-07-08 12:30:07 UTC
Turning off secure boot and installing the NVidia drivers results in a non bootable system. Screen turns black right after GRUB and before asking for the disk encryption password. Only to get back in the system was by turning on secure boot so that the driver failed to load.
Comment 3 Matthias Bach 2020-07-08 16:04:07 UTC
OK. That is much worse than my issue. I could just disable secure boot on my system and the system now works fine. But this makes it even more necessary to properly point out this limitation.
Comment 4 Wolfgang Bauer 2020-07-08 16:48:08 UTC
FTR, this is the result of bug#1173158 .
Comment 5 Martin Wilck 2020-07-08 17:21:50 UTC
FTR, the release notes entry is here: 

https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.2/#sec.driver.sig

Turning on secure boot while allowing unsigned kernel modules to be loaded doesn't make much sense. I can see that his might be an issue on dual-boot systems where the other OS requires SB to be active.
Comment 6 Martin Wilck 2020-07-08 17:25:25 UTC
(In reply to Ricardo Minnaard from comment #2)
> Turning off secure boot and installing the NVidia drivers results in a non
> bootable system. Screen turns black right after GRUB and before asking for
> the disk encryption password.

This sounds like a different issue. Please remove "quite splash=silent" boot parameters and add "splash=verbose ignore_loglevel systemd.show_status=0". If you can, capture logs with a serial console.
Comment 7 Martin Wilck 2020-07-08 17:26:01 UTC
(In reply to Martin Wilck from comment #6)
> This sounds like a different issue. Please remove "quite splash=silent"

typo. remove "quiet splash=silent"
Comment 8 Wolfgang Bauer 2020-07-08 17:52:13 UTC
(In reply to Martin Wilck from comment #5)
> Turning on secure boot while allowing unsigned kernel modules to be loaded
> doesn't make much sense. I can see that his might be an issue on dual-boot
> systems where the other OS requires SB to be active.

It's obviously also an issue when upgrading openSUSE systems (with the nvidia driver installed) that did have secure boot enabled before and worked fine.

I suppose that's the reason for this bug report in the first place...
Comment 9 Martin Wilck 2020-07-08 18:47:10 UTC
Right. Perhaps we should warn users more prominently about this issue. But I don't think this should be a reason for Leap to stick with the the unsafe setup, which IIRC was rather an oversight in previous Leap versions.
Comment 10 Ricardo Minnaard 2020-07-08 18:50:58 UTC
Ok here's the info.

I did a fresh install, because the upgrade failed for the same reason and I just figured to try a clean install. The machine is an Alienware R4, 3 years old. I installed:

- x11-video-nvidiaG05
- nvidia-glG05
- nvidia-gfxG05-kmp-default
- nvidia-computeG05

OpenSUSE it's on its own SSD drive. Windows is on a separate drive and in the machines Boot menu I can select to boot from the windows drive.

The system suggests to install the G04 driver, but that is not correct for the GTX1080 AFAIK. Also, I tried the G04, same result. Which is weird I guess since it's the wrong driver to begin with.

I just disabled secure boot and edit the GRUB line: removing quiet splash=silent and adding splash=verbose ignore_loglevel systemd.show_status=0

Then I continued to boot. Exactly the same result, a black screen that never went away. I did see however a quick boot screen with all the messages. But just a fraction.

I made the journald permanent and here is the boot log:

https://pastebin.com/9RnWMc39



Just another question, do I understand right that secure boot will never work with NVidia drivers? Or at least, not the easy (automatically) way?
Comment 11 Wolfgang Bauer 2020-07-08 18:56:52 UTC
(In reply to Martin Wilck from comment #9)
> Right. Perhaps we should warn users more prominently about this issue. But I
> don't think this should be a reason for Leap to stick with the the unsafe
> setup, which IIRC was rather an oversight in previous Leap versions.

Breaking existing user's setups on Leap 15 is not nice either though.
Your decision, I suppose.

Please note that I'm just a messenger here, not affected.
Personally, I don't care.
Comment 12 Martin Wilck 2020-07-08 19:20:15 UTC
(In reply to Ricardo Minnaard from comment #10)

> https://pastebin.com/9RnWMc39

From the log, I'd hypothesize that the screen goes black *because the nvidia driver was loaded successfully* and started doing weird things with your graphics hardware. But I'm not a video driver expert.

Booting fails because the job for the crypt device times out, probably because you never had the chance to enter the pass phrase. 

Have you tried typing in the pass phrase blindly? Have you tried "plymouth.enable=0?"

> Just another question, do I understand right that secure boot will never
> work with NVidia drivers? Or at least, not the easy (automatically) way?

Unfortunately, the answer is "most probably yes". I believe that it would be possible to create proper KMP packages for NVidia drivers, which wouldn't suffer from the issue because such drivers can be signed. It would still be necessary to make the signing keys known to UEFI and/or the kernel, e.g. using mokutil. 

But there are a number of problems with this approach, discussed already in bug 1173158:

 - SUSE won't ship such packages, and they can't be built on openSUSE's OBS instance, for legal reasons. In theory something like pacman would be possible I guess. 
 - Setting up module signing in OBS is non-trivial AFAIK and requires a safe setup to keep the private keys secure.
 - It would be considerable effort to create these KMPs, and so far noone has volunteered to try. There is a non-zero probability that the concept won't work out in practice and that thus the effort would be mostly wasted.
Comment 13 Martin Wilck 2020-07-08 19:28:44 UTC
(In reply to Wolfgang Bauer from comment #11)

> Breaking existing user's setups on Leap 15 is not nice either though.
> Your decision, I suppose.

Come on. Nobody "decided" to break anyone's setup. There was even an emergency post to opensuse-factory (https://lists.opensuse.org/opensuse-factory/2020-06/msg00249.html), which got no replies. (OK, I know - I also don't read through the last 3 weeks of the factory ML before running "zypper dup". But what else would you expect?).

I am personally sorry for everyone who's affected. I hate regressions caused by careless developers just like everybody else. But if it's about "security vs. convenience", openSUSE has a record for rather choosing security, and that's a good thing IMHO.

Note that if we're talking about "closing the leap gap", not enabling this would be a major pain point, as SLE has always enabled it.
Comment 14 Wolfgang Bauer 2020-07-08 19:31:51 UTC
(In reply to Martin Wilck from comment #12)
>  - SUSE won't ship such packages, and they can't be built on openSUSE's OBS
> instance, for legal reasons. In theory something like pacman would be
> possible I guess. 
Sorry to step in again, but if it would be possible in Packman e.g., why shouldn't that be possible in the existing NVidia repo too?
Comment 15 Matthias Bach 2020-07-08 19:33:42 UTC
(In reply to Martin Wilck from comment #9)
> Right. Perhaps we should warn users more prominently about this issue. But I
> don't think this should be a reason for Leap to stick with the the unsafe
> setup, which IIRC was rather an oversight in previous Leap versions.

This is exactly what my intention was when opening this bug.

Counting myself as an experienced user rather knowledgeable in hardware and security I am fully aware of the reasons why this makes sense, and why the current implementation of the NVIDIA driver package won't work. Yet, despite all this the comment in the release nodes mislead me to think it would be fine as long as I follow the treated path. Otherwise I'd probably have stuck out with 15.1 a little longer and not upgraded with some more time on my hands. And with machine learning tools being a highlight of 15.2 I suspect that a lot of of less-hardware-savvy folks might be taking a new look at openSUSE and find a nasty surprise realising that they won't easily get GPU acceleration for their libraries without flicking a BIOS switch first. Would probably be better to tell them upfront at least.

That said. Of course finding a way to provide a properly signed NVIDIA driver would be the perfect solution. But until then we should at least make it clear that on a secure-boot system the proprietary driver won't work without manual intervention, even when following the best practice guidelines in the wiki.
Comment 16 Wolfgang Bauer 2020-07-08 19:38:21 UTC
(In reply to Martin Wilck from comment #13)
> (In reply to Wolfgang Bauer from comment #11)
> 
> > Breaking existing user's setups on Leap 15 is not nice either though.
> > Your decision, I suppose.
> 
> Come on. Nobody "decided" to break anyone's setup. There was even an
> emergency post to opensuse-factory
> (https://lists.opensuse.org/opensuse-factory/2020-06/msg00249.html), which
> got no replies. (OK, I know - I also don't read through the last 3 weeks of
> the factory ML before running "zypper dup". But what else would you expect?).
> 
> I am personally sorry for everyone who's affected. I hate regressions caused
> by careless developers just like everybody else. But if it's about "security
> vs. convenience", openSUSE has a record for rather choosing security, and
> that's a good thing IMHO.
> 
> Note that if we're talking about "closing the leap gap", not enabling this
> would be a major pain point, as SLE has always enabled it.

Well, breaking user systems like this is not what I do understand about "closing the leap gap", sorry.

Anyway, I do feel sorry if I offended you with my comment.
That was not my intent.
I was just trying to point out what leaded to this problem here

But I don't have any means to "fix" this problem in any way.

And btw, I didn't reply to this mailing list post you listed, because it doesn't affect me as I wrote.
Comment 17 Matthias Bach 2020-07-08 19:40:05 UTC
(In reply to Ricardo Minnaard from comment #10)
> The system suggests to install the G04 driver, but that is not correct for
> the GTX1080 AFAIK. Also, I tried the G04, same result. Which is weird I
> guess since it's the wrong driver to begin with.

Just FYI, this issue has been noted when tackling #1173733 and should be solved with the next package version.
Comment 18 Ricardo Minnaard 2020-07-08 19:48:26 UTC
How do the AMD drives solve this? Or do they have the same issue?
I’ve been in Suse since Novell bought it, so I’ll be fine. But I’m noticing a Linux growth around me. As me, more people are switching to Linux. People are playing A+ games now on Linux. See YouTube, it’s flooding with gaming on Linux vids.

Not being able to run these drives is a disaster IMO. It sets Linux back several years. Yet I do understand the security trait off. I’m no developer, so I’m not going to lay down some hard critics.

And if I was able to be part of the solution I’d try. My understanding is too little. If it was up to me, I’d show a pop-up window or a big splash screen in the GUI informing a user the steps to take to get around this. A text somewhere in some release notes isn’t enough. But that is my personal opinion. Ubuntu has or had this wizard for proprietary drivers. Something like that to explain a user why it doesn’t work with secure boot.
Comment 19 Martin Wilck 2020-07-08 19:49:16 UTC
(In reply to Wolfgang Bauer from comment #14)
> Sorry to step in again, but if it would be possible in Packman e.g., why
> shouldn't that be possible in the existing NVidia repo too?

I can't answer that, because I have zero knowledge about how that repo is maintained.

In the past I worked for a company that shipped (other) proprietary drivers in KMP format, properly signed with the company's own key. So I guess if NVidia was willing to do this and spend the necessary effort, they could. NVidia would be powerful enough to even push their key to the major vendors' BIOS. 

Let's get this straight:

 - After years of fighting and hassle, NVidia still ships the proprieary driver and AFAIK has no intention to cease doing that.
 - SB is becoming more and more ubiquitous, and SB + unsigned modules is a general problem, not only on openSUSE but on every Linux distro.
 - SUSE and the openSUSE community have done a great deal of work to make packaging and installing the drivers hassle-free for users. That's work that NVidia should have done but chose rather not to.
 - Now with secure boot and CONFIG_MODULE_SIG=y, the problem gets a new dimension that the community can't easily solve. It's a catch-22. 
 - Eventually it's NVidia's problem and only NVidia can solve it "for good", either by open-sourcing the driver or by packaging and shipping properly signed driver modules.

> Well, breaking user systems like this is not what I do understand about "closing the leap gap", sorry.

Again, "breaking systems" is not the intention. The intention is to minimize differences, and that includes of course important basic kernel security settings like that. By doing this, we bring Leap to a similar security level as SLE.
Comment 20 Ricardo Minnaard 2020-07-08 19:50:13 UTC
(In reply to Martin Wilck from comment #12)
> (In reply to Ricardo Minnaard from comment #10)
> 
> > https://pastebin.com/9RnWMc39
> 
> From the log, I'd hypothesize that the screen goes black *because the nvidia
> driver was loaded successfully* and started doing weird things with your
> graphics hardware. But I'm not a video driver expert.
> 
> Booting fails because the job for the crypt device times out, probably
> because you never had the chance to enter the pass phrase. 
> 
> Have you tried typing in the pass phrase blindly? Have you tried
> "plymouth.enable=0?"
> 

I will try this first thing tomorrow.
Comment 21 Wolfgang Bauer 2020-07-08 19:52:13 UTC
(In reply to Wolfgang Bauer from comment #11)
> (In reply to Martin Wilck from comment #9)
> > Right. Perhaps we should warn users more prominently about this issue. But I
> > don't think this should be a reason for Leap to stick with the the unsafe
> > setup, which IIRC was rather an oversight in previous Leap versions.
> 
> Breaking existing user's setups on Leap 15 is not nice either though.
> Your decision, I suppose.

And maybe I should clarify it a bit:
I wanted to say it's your decision what to do about it, or whether it's worth to change it.

And with "you/your", I do mean SUSE, whoever is responsible for this.
Comment 22 Ricardo Minnaard 2020-07-08 19:54:59 UTC
Ok in the end NVidia needs to solve this. And since all distros will eventually have this issue they need to make a choice. Drop Linux support or make a change?
Comment 23 Wolfgang Bauer 2020-07-08 19:56:50 UTC
(In reply to Martin Wilck from comment #19)
> (In reply to Wolfgang Bauer from comment #14)
> > Sorry to step in again, but if it would be possible in Packman e.g., why
> > shouldn't that be possible in the existing NVidia repo too?
> 
> I can't answer that, because I have zero knowledge about how that repo is
> maintained.
Why do you even ask?

It's maintained by Stefan Dirsch AFAIK.
In OBS:
https://build.opensuse.org/project/show/X11:Drivers:Video

You should know that, no?
Comment 24 Martin Wilck 2020-07-08 20:02:54 UTC
(In reply to Ricardo Minnaard from comment #18)
> How do the AMD drives solve this? Or do they have the same issue?

Every proprietary driver has the issue. It can be solved, but the solutions differ between distros. Shipping binary drivers for all Linux distros is a huge task, even for a big company (at my former employer we shipped only drivers for SLE and RHEL, and that was already a lot of work). 

 > Not being able to run these drives is a disaster IMO. It sets Linux back
> several years. Yet I do understand the security trait off. I’m no developer,
> so I’m not going to lay down some hard critics.

I totally agree. The workaround is "disable secure boot". IIUC comment 17, the other issue you had should be fixed soon, too.

> If it was up to me, I’d show a pop-up window or a big splash
> screen in the GUI informing a user the steps to take to get around this. A
> text somewhere in some release notes isn’t enough.

I agree. What we could have done out-of-the-box would be to display an "EULA" at package installation time. ("EULA"s are not only for legal issues, they've been used for technical warnings quite a few times). Unfortunately nobody thought about that, and when we did it was too late. Apparently Nvidia+SB users didn't take part in the beta testing. The only thing we could have done at the time the issue came up was revert the change.

AFAIK Ubuntu "solves" this problem by not enabling module signing. It's a trade-off between security and convenience, and SUSE and Ubuntu have different positions in that area. 

I believe we should take a look at NVidia drivers for Fedora. Fedora has enabled module signing long ago.
Comment 25 Wolfgang Bauer 2020-07-08 20:11:57 UTC
(In reply to Martin Wilck from comment #19)
> Let's get this straight:
> 
>  - After years of fighting and hassle, NVidia still ships the proprieary
> driver and AFAIK has no intention to cease doing that.
>  - SB is becoming more and more ubiquitous, and SB + unsigned modules is a
> general problem, not only on openSUSE but on every Linux distro.
>  - SUSE and the openSUSE community have done a great deal of work to make
> packaging and installing the drivers hassle-free for users. That's work that
> NVidia should have done but chose rather not to.
>  - Now with secure boot and CONFIG_MODULE_SIG=y, the problem gets a new
> dimension that the community can't easily solve. It's a catch-22. 
>  - Eventually it's NVidia's problem and only NVidia can solve it "for good",
> either by open-sourcing the driver or by packaging and shipping properly
> signed driver modules.

Yes.

And while I do fully agree with this, there's still the problem that some openSUSE Leap 15 users (that upgrade from 15.1 to 15.2) are suddenly left with an unbootable system.

I would think that this should be worth a reconsideration.

Anyway, as I wrote, it's not *my* problem.
Comment 26 Martin Wilck 2020-07-08 20:17:53 UTC
(In reply to Wolfgang Bauer from comment #23)
> (In reply to Martin Wilck from comment #19)
> > I can't answer that, because I have zero knowledge about how that repo is
> > maintained.
> Why do you even ask?

I didn't ask. But indeed I thought you were referring to something else than Stefan's repo. I apologize, I don't have NVidia hardware and thus no experience in this area.

> It's maintained by Stefan Dirsch AFAIK.
> You should know that, no?

I'm aware of Stefan's repo. But that doesn't mean that I know how the packages are structured and built. I believe you read bug 1173158. Then you are probably aware that a solution will hardly be created in that repo, for legal reasons alone. To build the packages on the end user's system is key for the design, but
it doesn't go well with module signing. At best, you'd have to tell users how to set up their own key, load it into the BIOS, and provide and unlock the secret key every time the modules are rebuilt.

(In reply to Wolfgang Bauer from comment #25)
> I would think that this should be worth a reconsideration.

Adding Lubos. I believe it's too late to change this now, and I don't think I have to re-state that I'm against it. But of course we should discuss it.
Comment 27 Matthias Bach 2020-07-08 20:32:13 UTC
(In reply to Martin Wilck from comment #26)
> To build the packages on the end user's system is key
> for the design, but
> it doesn't go well with module signing. At best, you'd have to tell users
> how to set up their own key, load it into the BIOS, and provide and unlock
> the secret key every time the modules are rebuilt.

That's an interesting approach. The only idea I came up with so far would be to create rely on a reproducible build and ship only the signature of the module in the package (which would only match a correctly build package and require updating the package with every kernel update then). But that is probably highly unrealistic given how tricky and hard reproducible builds still are nowadays.
Comment 28 Wolfgang Bauer 2020-07-08 20:33:36 UTC
(In reply to Martin Wilck from comment #26)
> I believe you read bug 1173158.
I did, and you were involved there too, and suddenly commented here.
So I took it up here..

Again, sorry if there was some miscommunication because of this.

Maybe I should have commented more in the other bug report...

But I do hope that everybody involved there reads the discussion here, that's why I mentioned it.
Comment 29 Ricardo Minnaard 2020-07-09 06:47:53 UTC
With all the options I needed to add to the GRUB line and plymouth.enable=0 the screen still goes black. Blindly typing the encryption password doesn’t seem to work.

Still no go for me.
Comment 30 Ricardo Minnaard 2020-07-09 06:49:32 UTC
Oh after a while I do get a blinking cursor and I can switch to tty1 to get a login prompt.
Comment 31 Ricardo Minnaard 2020-07-09 06:52:17 UTC
Oh and the NVidia driver is somewhat working because all my monitors are now on and with the Nouveau driver the monitors go on when the GUI is loaded. The NVidia driver also enables the monitors when you don’t have a GUI.

Just seems that Wayland isn’t loading now.
Comment 32 Ricardo Minnaard 2020-07-09 07:14:56 UTC
Turning off Wayland still results in a black screen instead of the password encryption input screen. Typing it blindly works and it starts good old Xorg.

So not showing the encryption thing is still an issue. Wayland is an issue I guess.

And with what I have read in this post, I think the Linux community killed the Linux Desktop themselves now. I mean, yeah security. That argument is solid, but I will not be installing 15.2 anywhere. I have migrated loads of people to Suse the last 15 years. Even retired people that got sick of the windows crap. But these choices made will now kill all the effort the Linux community made the last 2 years in acceptance of the Linux Desktop and gaming. And gaming may sound silly, but that is THE way to get people to your platform.

I hope the bugs that I have encountered here will be resolved of course. And the key problem, unless NVidia wakes up, this is over. Makes me sad.

This is the first time I am not happy and excited with a new Suse release :(
Comment 33 Martin Wilck 2020-07-09 09:03:36 UTC
(In reply to Ricardo Minnaard from comment #32)
> Turning off Wayland still results in a black screen instead of the password
> encryption input screen. Typing it blindly works and it starts good old Xorg.

Even with "plymouth.enable=0"? Again, this is likely a different issue and should be discussed elsewhere (bug 1173733 ?). Possibly related to graphics mode during boot. You could try to set GRUB_TERMINAL=console and/or GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub (re-run grub2-mkconfig after that).

> So not showing the encryption thing is still an issue. Wayland is an issue I
> guess.

I thought that the NVidia driver doesn't work well with Wayland in general, for reasons related to the architecture of the graphics stack. I haven't followed the development closely, is it solved?

> I hope the bugs that I have encountered here will be resolved of course. And
> the key problem, unless NVidia wakes up, this is over. Makes me sad.

I said that only NVidia can solve this "for good". That doesn't mean there will be no solution. To the contrary, I'm quite positive that we'll find a solution.

> This is the first time I am not happy and excited with a new Suse release :(

I can understand your frustration. Rest assured that something will be done about it. There is no simple solution which is "right" for everyone, unfortunately.
Comment 34 Ricardo Minnaard 2020-07-09 09:29:51 UTC
Ok so your message gives me hope. I am no developer, but if I can help in any way, please let me know.

I’ll try the Plymouth option with the driver installed and Wayland turned off.
Comment 35 Ricardo Minnaard 2020-07-09 10:06:12 UTC
Ok this is what I did:

Booting with only Plymouth.enable=0 results in a black screen instead of the encryption password.

Booting with removing quiet splash=silent AND adding splash=verbose ignore_loglevel systemd.show_status=0 plymouth.enable=0 also results in a black screen instead of the encryption password.
Comment 36 Valur Olafsson 2020-07-09 12:54:43 UTC
(In reply to Ricardo Minnaard from comment #35)
> Ok this is what I did:
> 
> Booting with only Plymouth.enable=0 results in a black screen instead of the
> encryption password.
> 
> Booting with removing quiet splash=silent AND adding splash=verbose
> ignore_loglevel systemd.show_status=0 plymouth.enable=0 also results in a
> black screen instead of the encryption password.

You could try to boot with nvidia-drm.modeset=1. I'm not sure if this will do much but I know that in order to run kwin on Wayland one of their main kwin developers, David Edmunds, wrote on his blog about needing to include this kernel parameter [1]. I see that they've also written about this on their KDE Community Wiki [2].

[1] http://blog.davidedmundson.co.uk/blog/running-kwin-wayland-on-nvidia/
[2] https://community.kde.org/Plasma/Wayland/Nvidia
Comment 37 Ricardo Minnaard 2020-07-10 07:05:04 UTC
When Wayland turned off:

I entered nvidia-drm.modeset=1 and booted. I got stuck at a black screen with ony:

Sd 4:0:0:0: [sdc] No Caching mode page found
Sd 4:0:0:0: [sdc] Assuming drive cache: write through

But when I touched a random key I got the encryption password screen, entered it and Xorg booted.

When Wayland turned on:

I entered nvidia-drm.modeset=1 and booted. I got stuck at a black screen with ony:

Sd 4:0:0:0: [sdc] No Caching mode page found
Sd 4:0:0:0: [sdc] Assuming drive cache: write through

But when I touched a random key I got the encryption password screen, entered it and I got back at:

Sd 4:0:0:0: [sdc] No Caching mode page found
Sd 4:0:0:0: [sdc] Assuming drive cache: write through

and the machine froze. Even ctrl + alt + del didn’t’ work.
Comment 38 Martin Wilck 2020-07-13 16:19:00 UTC
(In reply to Ricardo Minnaard from comment #37)

> and the machine froze. Even ctrl + alt + del didn’t’ work.

This sounds as if the driver freezes your graphics hardware. Probably more an issue for NVidia to solve than for us. Are you using the same driver version that you used with Leap 15.1?

Would you be able to capture a serial console log?
Comment 40 Ricardo Minnaard 2020-07-16 07:06:48 UTC
So here is the boot log from where Wayland is turned on WITH the latest NVidia drivers. The screen goes black, but typing in the disk encryption password several times blindly did help. The system booted to a console, not Wayland.

The version of these drivers is the same as the latest that I had on 15.1. I just didn't use Wayland on 15.1.

However, this boot log shows some interesting NVidia stuff. I hope this helps you guys in any way.

https://pastebin.com/FHrm8TmK
Comment 41 Martin Wilck 2020-07-16 08:55:23 UTC
The nvidia driver is loaded immediately before the cryptsetup. So like I said before, the Nvidia driver is doing something weird, causing the screen to go dark. The Nvidia and/or graphics driver experts should have a look. I see no error messages from the nvidia driver, debug levels need to be incraesed.

Wrt wayland not starting, it's most probably a different issue.

I see this:

> Jul 16 08:48:31 echelon gnome-shell[2538]: Failed to open gpu '/dev/dri/card1': Failed to activate universal planes: Operation not permitted
> Jul 16 08:48:31 echelon gnome-shell[2538]: Failed to create backend: No GPUs with outputs found
> Jul 16 08:48:31 echelon systemd[2262]: Failed to start GNOME Shell on Wayland.

The first line is probably the error that's causing the issue. gnome-shell, running as the gdm user, can't access the graphcis device (/dev/dri/card1)

I can see two possible reasons for the wayland issue:

 * permissions for /dev/dri/card$X are managed by systemd-logind, adding ACLs for the user that currently owns the console. (https://dvdhrm.wordpress.com/2013/08/25/sane-session-switching/). Maybe we have a race here, related to the use of the nvidia driver, that cause the permissions not to be set correctly, or too late, or some nvidia user space component is trying to access the device before the ACLs have been set.
  
 * or it's lockdown-related. I don't know what "failed to activate universal planes" means, and if extra permissions are needed for that. Maybe nvidia's user space code attempts to so something that lockdown forbids, like accessing device  memory directly. However, I reckon this was reported against a system with secure boot switched off; it's rather unlikely that lockdown is the issue in that case.
Comment 42 Stefan Dirsch 2020-07-16 10:43:58 UTC
I believe the discussion about Wayland with nvidia proprietary driver is unrelated here. Unfortunately Leap/TW doesn't support Wayland running NVIDIA's proprietary driver yet, at least not out-of-the-box. If you're deeply interested into this topic just a few
references for reading:

GNOME:
  * https://wiki.gnome.org/Initiatives/Wayland/NVIDIA 
  * https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/ 
   
Plasma
  * http://blog.davidedmundson.co.uk/blog/running-kwin-wayland-on-nvidia/
  * https://community.kde.org/Plasma/Wayland/Nvidia
Comment 43 Ricardo Minnaard 2020-07-16 11:02:29 UTC
Nah I don't care about Wayland yet. I see the improvements over Xorg, but I also see limitations in the current build of Wayland. I am back to Xorg now. The only problem that remains is that I don't see the disk encryption screen, but just typing the password works.

I hope the secureboot with NVidia issue will get resolved.
Comment 44 Martin Wilck 2020-07-16 11:34:48 UTC
(In reply to Stefan Dirsch from comment #42)

> https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-
> 31/ 

The link was broken for me, I retrieved the text via google translate, here is the relevant part:

Finally there is the NVidia binary driver support question. So you can run a native Wayland session on top of the binary driver and you had that ability for a very long time. Unfortunately there has been no support for the binary driver in XWayland and thus and X applications (which there are a lot of) would not be getting any HW accelerated 3D graphics support. Adam Jackson has worked on letting XWaylands load the binary NVidia x.org driver and we are now waiting on NVidia to review that work and hopefully be able to update their driver to support it.
Comment 45 Martin Wilck 2020-07-16 11:42:24 UTC
Ricardo, please try this:

> https://forums.developer.nvidia.com/t/black-screen-after-install-of-nvidia-driver-ubuntu/109312/2

Don't let yourself confuse by the ubuntu-specific parts of the procedure.

Note also the mention of the nvidia-bug-report.sh script there, it might be useful.

Are you sure you installed the right NVidia package for your hardware?
Comment 46 Stefan Dirsch 2020-07-16 22:34:44 UTC
(In reply to Martin Wilck from comment #5)
> FTR, the release notes entry is here: 
> 
> https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.2/#sec.driver.

This needs adjustments in Release notes with unsigned modules no longer being loadable with Leap 15.2 kernel. The following may
help for writing. Feel free to refer to it.

https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot
Comment 47 Ricardo Minnaard 2020-07-17 07:02:01 UTC
Hi Stefan,

I just installed the new driver with SecureBoot on. I got the enroll key menu and this worked flawlessly. With secure boot I did got to see the Encryption Disk password (with secure boot off still not btw) and Xorg loaded without any issues.

I think this solution is the best outcome in this situation. This is something I can explain to people that are on OpenSuse due to my advise and enthousiasme for Suse.

If I can help with testing on my hardware for feature releases then gladly.
Comment 48 Ricardo Minnaard 2020-07-17 07:02:21 UTC
Hi Stefan,

I just installed the new driver with SecureBoot on. I got the enroll key menu and this worked flawlessly. With secure boot I did got to see the Encryption Disk password (with secure boot off still not btw) and Xorg loaded without any issues.

I think this solution is the best outcome in this situation. This is something I can explain to people that are on OpenSuse due to my advise and enthousiasme for Suse.

If I can help with testing on my hardware for feature releases then gladly.
Comment 49 Ricardo Minnaard 2020-07-17 07:03:39 UTC
@Martin

The solution from the url you gave would be for the black password screen with secure boot off I think?
Comment 50 Stefan Dirsch 2020-07-17 07:41:20 UTC
@Ricardo Black screen for encryption password sounds more like nouveau driver to me. But this is weird since once one installs the nvidia driver packages nouveau gets blacklisted - even already in initrd.
Comment 51 Matthias Bach 2020-07-17 07:42:22 UTC
Thanks for providing such a great solution for this! Switched my system back to secure boot, enrolled the key when the prompt came up, got a working NVIDIA driver. :)
Comment 52 Stefan Dirsch 2020-07-17 11:52:44 UTC
@marix@marix.org Thanks for positive feedback! I'm glad it works for you. :-)
Comment 53 Ricardo Minnaard 2020-07-17 13:07:44 UTC
Thanks for all the help everyone!

And thanks Stefan (and your team if there is one) for this great solution.

Have a nice weekend all.
Comment 54 Stefan Dirsch 2020-07-17 14:23:45 UTC
@opensuse@x-labs.nl Thanks for positive feedback! Credits also go to Takashi, Ludwig, Martin W. for proposals, suggestions, feedback and testing.
Also to NVIIDA. This time it took them just a few hours to update the repositories!
Comment 55 Zaborski 2020-07-22 20:37:49 UTC
Hello all. Just would like to say, enrolling key has not solved for me the problem with NVIDIA driver. It still doesn't work after enrolling. 
The problem modprobe: ERROR: could not insert 'nvidia': Operation not permitted still exist on my machine.
Comment 56 Zaborski 2020-07-22 21:11:01 UTC
CORRECTED
Sorry I gave wrong information. After enrolling key modprobe output changed from 
modprobe: ERROR: could not insert 'nvidia': Operation not permitted
to
modprobe: ERROR: could not insert 'nvidia': No such device
That is for G05 driver
Comment 57 Stefan Dirsch 2020-07-23 09:16:58 UTC
@Zaborski Well, this could be a complete different issue. Wrong driver e.g. what does "hwinfo --gfxcard" say? And  "dmesg | grep nvidia"?
Comment 58 Zaborski 2020-07-23 09:23:54 UTC
I apologize
Finlay, Enrolling key solved my problem.
Now, driver works
Comment 59 Stefan Dirsch 2020-07-23 09:36:33 UTC
Ok. I meanwhile added also screenshots to the secureboot section ...

https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot

Hopefully this helps ...
Comment 60 Stefan Dirsch 2020-07-23 10:05:42 UTC
Created attachment 839950 [details]
Patch proposal for release notes
Comment 61 Stefan Dirsch 2020-07-23 12:15:19 UTC
I also opened a pull request. Not sure what else I can do ...

https://github.com/openSUSE/release-notes-openSUSE/pull/101
Comment 62 Stefan Dirsch 2020-07-23 12:43:57 UTC
Pull request has been accepted. :-)

https://github.com/openSUSE/release-notes-openSUSE/pull/101#issuecomment-662982353
Comment 63 Stefan Dirsch 2020-07-24 02:58:19 UTC
Release Notes have already been updated.

https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot

So let's close this one as fixed.
Comment 64 Stefan Dirsch 2020-07-24 03:38:32 UTC
That's the correct address:

https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.2/#sec.driver
Comment 65 Tripple Moon 2020-08-13 07:11:31 UTC
Please take not that on my system i do NOT get the MokManager screen after reboot, so this system is *not* working flawlessly...
For details see: https://bugzilla.opensuse.org/show_bug.cgi?id=1175210