* Chuck Davis [04-07-20 13:12]:

I would certainly appreciate something being done to prevent having my desktop obliterated thru an update. Fortunately, I was able to find a way around this one but the last one was terrible.

On Tue, Apr 7, 2020 at 6:32 AM Stasiek Michalski wrote:

...

On Tue, Apr 7, 2020 at 09:05, Raphael Lydia Bertoche wrote:

...

What do you think?

I do think nvidia package should hardcode the max minor kernel version it works with instead, so the error message when trying to update is very clear on what's wrong. And that's double as useful considering the package's use of kmp instead of dkms.

always keep at least one and preferably two previous kernels so you do not loose your "desktop" (video driver). -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 Tue, 7 Apr 2020 at 16:16, Felix Miata wrote:

Chuck Davis composed on 2020-04-07 10:10 (UTC-0700):

...

I would certainly appreciate something being done to prevent having my desktop obliterated thru an update. You can do "something" yourself quite simply:

zypper addlock kernel-def* # addlock = al

If and when you know it's an appropriate time to upgrade to current kernel:

zypper install kernel-default # install = in

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. -- Evolution as taught in public schools is religion, not science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Dienstag, 7. April 2020, 19:22:02 CEST schrieb Andrei Borzenkov:

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.

Well this time the first kernel-5.6 for tumbleweed was released on Sat Apr 4, the updated nvidia-gfxG05-kmp-default-440.82 , which has the fixes to build on kernel-5.6 was released on Tue Apr 7 . So three days without functional nvidia driver for the tumbleweed kernel this time. However the problem that the older nvidia-440.64 doesn't build on kernel-5.6 without patches was known weeks before. And patches for 440.64 were available. So it would have been possible to provide a patched 440.64 on Apr.4 . But probably NVIDIA doesn't want to distribute a package with inofficial patches. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

From what I know, the Nvidia repository at http://download.nvidia.com/opensuse/tumbleweed/x86_64/ (which is the one I am using) is built from the nvidia-gfxGXX packages on OBS (e.g., https://build.opensuse.org/package/show/X11:Drivers:Video/nvidia-gfxG05). So I think the nvidia package on TW is under openSUSE's control. (Correct me if I am wrong.) If not, we can fork this package and maintain a community version of nvidia package, if Packman or other community OBS is willing to accept it.

The problem is that we need to maintain a compatibility matrix for nvidia and the latest kernel. I know there is a blog (http://rglinuxtech.com/?p=2724) constantly testing the compatibility, but it will be great if someone knows better source of information. Best, xz -- Xu Zhao i@xuzhao.net On Wed, 8 Apr 2020, at 1:40 AM, Raphael Lydia Bertoche 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

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Apr 08, 2020 at 03:34:33PM +0200, Axel Braun wrote:

Am Mittwoch, 8. April 2020, 14:56:26 CEST schrieb Xu Zhao:

...

From what I know, the Nvidia repository at http://download.nvidia.com/opensuse/tumbleweed/x86_64/ (which is the one I am using) is built from the nvidia-gfxGXX packages on OBS (e.g., https://build.opensuse.org/package/show/X11:Drivers:Video/nvidia-gfxG05). So I think the nvidia package on TW is under openSUSE's control. (Correct me if I am wrong.) If not, we can fork this package and maintain a community version of nvidia package, if Packman or other community OBS is willing to accept it.

There will probably always a delay between release of a kernel and the fix for nividia. One way to work around this is a test in openQA. Not sure what the policy is for proprietary drivers.

There are two class of failures of nVidia driver 1) it does not build 2) it builds but crashes You should be able to detect (1) with a kernel post-install hook and warn the user at the end of zypper run or even automatically modify the grub menu to not include broken kernel as the default. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Apr 7, 2020 at 9:32 AM Stasiek Michalski wrote:

On Tue, Apr 7, 2020 at 09:05, Raphael Lydia Bertoche wrote:

...

What do you think?

I do think nvidia package should hardcode the max minor kernel version

That won't work .. kernel_version != kernel_abi !! it is the latter you are concerned with. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hans-Peter:

1) a small group, that cares about NVidia

I understand that delaying kernel releases for everyone is not an option! But until Michal pointed out it hadn't occurred to me that a local system scope solution in a script run during installation could fix it for all nvidia users. Still, would a kernel version dependecy in some nvidia package delay kernel update those that don't use nvidia? I wouldn't propose that if I thought it would... Markus:

So include a conflict with kernel-5.7 into the current nvidia driver.

Isn't Michal's idea a better one? It would require no human work upon kernel update. I think this is a major difference. And It would give neither false positives nor false negatives for patch updates that break or minor updates that don't. Though it is more complex, since something would have to be hooked on next boot to detect that nvidia failed to be loaded. I think it's not that hard and is worth it. Thanks for everyone's replies -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I still prefer limiting the kernel version of Nvidia driver users because: - The driver may build and load but fail to work correctly, and - If the number of kernels is limited on user's machine, multiple incompatible (new) kernels may be installed, which might eventually remove the usable (old) kernel, and there will be no usable kernel at all. Therefore, I suggest we simply limit the kernel version in the Nvidia package to conflict with incompatible kernels. It is the easiest and simplest way to get things done, before we come up with a better solution. A few questions: - Is the nvidia packager on TW willing to cooperate? - Will it be helpful if we maintain a "Nvidia-kernel support matrix" on openSUSE wiki or somewhere else? I will be happy to maintain such a page, if it is helpful for the packager. Yours, xz -- Xu Zhao i@xuzhao.net On Mon, 13 Apr 2020, at 2:39 PM, Raphael Lydia Bertoche wrote:

Hans-Peter:

...

1) a small group, that cares about NVidia

I understand that delaying kernel releases for everyone is not an option!

But until Michal pointed out it hadn't occurred to me that a local system scope solution in a script run during installation could fix it for all nvidia users.

Still, would a kernel version dependecy in some nvidia package delay kernel update those that don't use nvidia? I wouldn't propose that if I thought it would...

Markus:

...

So include a conflict with kernel-5.7 into the current nvidia driver.

Isn't Michal's idea a better one? It would require no human work upon kernel update. I think this is a major difference.

And It would give neither false positives nor false negatives for patch updates that break or minor updates that don't.

Though it is more complex, since something would have to be hooked on next boot to detect that nvidia failed to be loaded. I think it's not that hard and is worth it.

Thanks for everyone's replies -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Sorry maybe I was not clear before. After some thoughts, here is my current position: 1. It is a fact that Nvidia driver updates slower than the kernel API changes. It is not something that can be fixed in any short term. 2. As a TW+nvidia user, I do NOT expect openSUSE package maintainers to delay the kernel release or keep patching the Nvidia driver to match the TW kernel changes. 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). - xz -- Xu Zhao i@xuzhao.net On Tue, 7 Apr 2020, at 3:17 PM, Larry Finger wrote:

On 4/7/20 1:40 PM, Xu Zhao wrote:

...

+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. Although recent Nvidia driver has improved its compatibility with the latest kernel, I still prefer that TW can put in some efforts to make the nvidia driver and kernel version consistent. Specifying the max/min kernel version in the nvidia package seems to be a good start.

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.

Even better, they should follow Intel and open up their source. If the nVidia driver were polished and submitted to the kernel, then the driver would always be available.

I used to have to keep up with the kernel changes for an nVidia driver, but I changed my graphics card to one that works with nouveau. It does not have the latest bells and whistles, but it is good enough for me.

Larry

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 8 Apr 2020, Andrei Borzenkov wrote:

07.04.2020 22:28, Xu Zhao пишет:

...

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).

Do you have actionable proposal how package maintainer can predict which kernel version will break compilation of nVidia module in the future?

The next? Unless somebody gives green light it does not (I guess somehow auto building the driver against KOTD isn't easily/legally possible in OBS). Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2020-04-08 at 16:21 +0200, Marius Kittler wrote: ...

Judging by the repository URL it looks like the NVIDIA driver is provided by NVIDIA itself and not openSUSE.

Read the readme file found in that server, you will then see this is not exactly the case. More or less, the situation is: The current package is generated at the OBS, but published by Nvidia, for legal reasons. Some manual procedure copies the package there and then it is published. This is not fast. For legal reasons, the package compiles on each person machine the actual kernel modules used, not on the OBS. This is done at install time, and at every kernel update. Unfortunately, with some kernel changes some little thing changes, there is a failure and the driver stops working or building locally, and a mannual modification has to be done somewhere in the package (kernel modules perhaps?), and then the package has to be published to make things work again. Maybe someone could publish a file with the list of current kernel versions known to work with what driver versions, and a script would lock the kernel till the file publishes the go ahead. You people would have to run that script before attempting the upgrades. (for me the problem is gone: I switched to AMD/ATI graphics) - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXo39wBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVL14An3ebGoemhEAKiD9DHMMJ BAGK2eByAJ9ph5OBaKO9/KZqYRz4unGzepsOYg== =VYxd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org