Answer 1 to delete lock and proceed to install. Lock will not be deleted, but merely ignored for the current operation, because wildcard locks do not get deleted except expressly in same manner as created.
That's a good hint too! I didn't know about that trick with wildcard locks. Thanks On Wed, 8 Apr 2020 at 02:40, Raphael Lydia Bertoche <bertocheraphael@gmail.com> wrote:
I do think nvidia package should hardcode the max minor kernel version it works with instead
I agree, in theory. Problem is, we do not control nvidia packages... It must be another package, probably one manually installed by proprietary nvidia users.
nVidia package builds KMP on the fly, on end user system. From there it is not different to DKMS. And it includes triggers that should rebuild driver when new kernel is installed. If this does not work, it is a bug that should be reported and investigated.
Hardcoding exact kernel version means driver must be rebuilt and published with every kernel update. I do not see this happening any time soon.
It's not a bug if it doesn't succeed after a minor update because of changes in kernel headers. Exact kernel version is not necessary. Patch version changes should be and usually are harmless.
+1. I fully support your proposal. For now I use a customized zypper script to check if the nvidia driver matches the kernel version and only upgrade if it matches.
Could you share that with us? It seems by far the most efficient and automatic solution on a single machine.
always keep at least one and preferably two previous kernels so you do not loose your "desktop" (video driver).
That's good advice, I'm happy it's still the default for suse. But why not have a solution that works even for people that have no idea there was a kernel update?
I disagree vehemently. I maintain VirtualBox for openSUSE, thus I have to modify some out-of-kernel modules to match changing kernel APIs. From the time that a new API is stabilized, the developer has roughly 8 weeks to modify the code to handle these changes. It rarely takes me more that one day!
If a single volunteer like me can keep up with such changes, then a large corporation should have those fixes on ALL its Linux drivers available by the time a new kernel version is released.
They should indeed! The point is, will they, ever? If not, then I think we should make it work better somehow. If only we and the rest of linux communities could find a way to pressure them to release their source code with some blobs in it... I for one would switch for nouveau anytime, once it did most of what nvidia does. I like the whistles and bells. I hope it catches up to them soon enough, then they will be forced to open it. But keep in mind this proposal is for a reliable solution to users of their drivers, not to release them from their responsibility with their costumers.
and still no packages/patches for legacy drivers, particularly 390.132 This is really sad, I have some machines locked on old kernel to this day because of that.
I think Xu Zhao wrote a good synthesis of I mean't:
3. However, I do hope to somehow delay my kernel update until the Nvidia driver catches up to make sure my desktop doesn't fail.
I think there are many ways to do 3. One solution is completely local, just as described by Felix, but it would be largely manual. The package maintainer can help automate this by defining an > allowed range of kernel versions when the Nvidia is installed (for example, with the "Conflicts" keyword in the spec).
But since the package maintainer is nvidia - correct me if I'm wrong - then we'd have to create a package for that ourselves. Unless nvidia would accept to include it to their srpm.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org