[opensuse-factory] Re: Updates on Tumbleweed with proprietary nvidia drivers installed could be more reliable I guess
I'd like to make a suggestion and ask you guys if you think it would work as I expect. There is an issue in openSUSE Tumbleweed that happens in my workplace frequently and often makes people complain about using TW, more than any other issue. That issue is a zypper dup without matching nvidia packages and kernel version. Before people suggesting me a switch to nouveau: I work with several mechanic and electric technicians who either want or must use Linux. They use nvidia because of issues with nouveau and huge framebuffers, either with two monitors or a large one, It's mostly used to a visual intensive data analysis or CAD work. This issue causes people to lose graphic interface every once in a while, since minor kernel updates have become rather frequent. Most of them don't know what to do next. If it's a laptop, it loses network, so even some not that savvy software devs are unable to get it back alive. Its a clear usability issue that I'd like to suggest a solution to. This solution wouldn't bother other users nor packagers because it would be a new package that required a certain kernel version. If this package was installed, the system wouldn't do a kernel update until it had an update. Then this package's maintainer - me I guess? - would limit nvidia's users kernel updates. Before release a check would have to be done and if nvidia matched current kernel version, then this package would get an update. It could be scripted somehow if it proves to work manually. I would do that way happier than doing several fixes that affects one single user and won't last long. What do you think? Best regards -- 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 09:05, Raphael Lydia Bertoche <bertocheraphael@gmail.com> 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. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 <hellcp@opensuse.org> wrote:
On Tue, Apr 7, 2020 at 09:05, Raphael Lydia Bertoche <bertocheraphael@gmail.com> 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.
LCP [Stasiek] https://lcp.world
-- 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
* Chuck Davis <cjgunzel@gmail.com> [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 <hellcp@opensuse.org> wrote:
On Tue, Apr 7, 2020 at 09:05, Raphael Lydia Bertoche <bertocheraphael@gmail.com> 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
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
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 <mrmazda@earthlink.net> 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
07.04.2020 16:31, Stasiek Michalski пишет:
On Tue, Apr 7, 2020 at 09:05, Raphael Lydia Bertoche <bertocheraphael@gmail.com> 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.
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. -- 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
* Markus Koßmann <mkossmann_ml1@gmx.de> [04-07-20 15:10]:
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.
and still no packages/patches for legacy drivers, particularly 390.132 -- (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
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
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
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
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. Best Axel -- 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
Am Mittwoch, 8. April 2020, 15:34:33 CEST schrieb Axel Braun:
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.
We have two kinds of openSUSE maintainers 1) a small group, that cares about NVidia 2) a large group, that don't want to be bothered with anything NVidia, and especially not delay a new kernel release because of 1). It has to be solved on local system scope, as Michal has pointed out. @Raphael: we control, what is published as NVidia drivers by Maintainer Stefan Dirsch. And Stefan is happy to cooperate. At least, that's my experience. Cheers, Pete -- 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 <hellcp@opensuse.org> wrote:
On Tue, Apr 7, 2020 at 09:05, Raphael Lydia Bertoche <bertocheraphael@gmail.com> 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
Am Montag, 13. April 2020, 15:32:10 CEST schrieb Cristian Rodríguez:
On Tue, Apr 7, 2020 at 9:32 AM Stasiek Michalski <hellcp@opensuse.org> wrote:
On Tue, Apr 7, 2020 at 09:05, Raphael Lydia Bertoche
<bertocheraphael@gmail.com> 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. Yes, but you can expect that there is no kernel abi change without kernel version change at least in minor version. So the idea could be: Now were are kernel-5.6, current nvidia driver is 440.80 So include a conflict with kernel-5.7 into the current nvidia driver. Once it's known that current nvidia driver has no problems with kernel-5.7 abi, update the nvidia driver to conflict with kernel-5.8. So silent updates to a kernel-abi, which breaks nvidia could be avoided, for non users of the nvidia driver there is no change
-- 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
Am Montag, 13. April 2020, 20:39:27 CEST schrieb Raphael Lydia Bertoche:
Hans-Peter:
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.
It's even more complex : the driver could compile and load but crash then. I doubt that you can detect such a case automatically. On the other hand we have only 4 kernel updates a year ( to< minor>.0 releases) where we have to expect such a problem. And only if there is no kernel abi change we have an additional update of nvidia just to update the conflict . With kernel abi change we have to update nvidia anyways. -- 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
On Mon, Apr 13, 2020 at 07:12:52PM +0200, Markus Koßmann wrote:
Am Montag, 13. April 2020, 15:32:10 CEST schrieb Cristian Rodríguez:
That won't work .. kernel_version != kernel_abi !! it is the latter you are concerned with.
Yes, but you can expect that there is no kernel abi change without kernel version change at least in minor version.
If you really expect that, you are in for an unpleasant surprise. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
+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. Best, - xz -- Xu Zhao i@xuzhao.net On Tue, 7 Apr 2020, at 8:05 AM, Raphael Lydia Bertoche wrote:
I'd like to make a suggestion and ask you guys if you think it would work as I expect.
There is an issue in openSUSE Tumbleweed that happens in my workplace frequently and often makes people complain about using TW, more than any other issue. That issue is a zypper dup without matching nvidia packages and kernel version.
Before people suggesting me a switch to nouveau: I work with several mechanic and electric technicians who either want or must use Linux. They use nvidia because of issues with nouveau and huge framebuffers, either with two monitors or a large one, It's mostly used to a visual intensive data analysis or CAD work.
This issue causes people to lose graphic interface every once in a while, since minor kernel updates have become rather frequent. Most of them don't know what to do next. If it's a laptop, it loses network, so even some not that savvy software devs are unable to get it back alive.
Its a clear usability issue that I'd like to suggest a solution to.
This solution wouldn't bother other users nor packagers because it would be a new package that required a certain kernel version. If this package was installed, the system wouldn't do a kernel update until it had an update.
Then this package's maintainer - me I guess? - would limit nvidia's users kernel updates. Before release a check would have to be done and if nvidia matched current kernel version, then this package would get an update.
It could be scripted somehow if it proves to work manually.
I would do that way happier than doing several fixes that affects one single user and won't last long.
What do you think?
Best regards -- 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 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
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
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? -- 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 <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
Hi, under Arch Linux it is generally possible to use the proprietary NVIDIA driver without disturbances. I've been doing this for years. They solved this problems in two different ways and it would be great if Tumbleweed would implement at least one of them. That's how they do it: 1. The updates of the `linux` package are synchronized with updates of the `nvidia` package. Even if there's no new version of NVIDIA they still rebuild the package against the new kernel, e.g. https://git.archlinux.org/svntogit/ packages.git/commit/trunk?h=packages/ nvidia&id=615899a8e8fc0d3c8809358c2f0ca64d5f899046. Only both packages are released from the staging repo at the same time. 2. Of course 1. does not work when one has a custom kernel installed. In this case the solution is to install the `nvidia-dkms` package. In this case the kernel module is built via DKMS which is invoked by hooks of the package manager on kernel updates. This requires installing kernel headers and takes some additional time when updating but it generally works quite well. Judging by the repository URL it looks like the NVIDIA driver is provided by NVIDIA itself and not openSUSE. That likely means the synchronization required for 1. is not achievable. But it still means that NVIDIA could implement 2. It is the most generic solution anyways. Best Regards Marius Am Dienstag, 7. April 2020, 14:05:12 CEST schrieb Raphael Lydia Bertoche:
I'd like to make a suggestion and ask you guys if you think it would work as I expect.
There is an issue in openSUSE Tumbleweed that happens in my workplace frequently and often makes people complain about using TW, more than any other issue. That issue is a zypper dup without matching nvidia packages and kernel version.
Before people suggesting me a switch to nouveau: I work with several mechanic and electric technicians who either want or must use Linux. They use nvidia because of issues with nouveau and huge framebuffers, either with two monitors or a large one, It's mostly used to a visual intensive data analysis or CAD work.
This issue causes people to lose graphic interface every once in a while, since minor kernel updates have become rather frequent. Most of them don't know what to do next. If it's a laptop, it loses network, so even some not that savvy software devs are unable to get it back alive.
Its a clear usability issue that I'd like to suggest a solution to.
This solution wouldn't bother other users nor packagers because it would be a new package that required a certain kernel version. If this package was installed, the system wouldn't do a kernel update until it had an update.
Then this package's maintainer - me I guess? - would limit nvidia's users kernel updates. Before release a check would have to be done and if nvidia matched current kernel version, then this package would get an update.
It could be scripted somehow if it proves to work manually.
I would do that way happier than doing several fixes that affects one single user and won't last long.
What do you think?
Best regards
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----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
Thanks Xu Zhao and Carlos E. R. for clarifying things.
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.
This script could be a hook inside a package, so that it would run automatically, can't it? According to Xu Zhao, it could even be bundled together in nvidia official repository, once they get it from OBS.
The problem is that we need to maintain a compatibility matrix for nvidia and the latest kernel.
Regardless of the source for that compatibility matrix, if this needs to be manual work done by a maintainer, I think it would still be better to most nvidia users to have a kernel update delayed for a week or two and in exchange be able to safely update without manually checking individual package versions. Since the kernel version is already appended to nvidia's version, shouldn't this be realiable enough? Once it had a current version, shouldn't it build safely? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (18)
-
Andrei Borzenkov
-
Axel Braun
-
Carlos E. R.
-
Chuck Davis
-
Cristian Rodríguez
-
Felix Miata
-
Hans-Peter Jansen
-
Larry Finger
-
Marius Kittler
-
Markus Koßmann
-
Michal Kubecek
-
Michal Suchánek
-
Patrick Shanahan
-
Raphael Lydia Bertoche
-
Raphael Lydia Bertoche
-
Richard Biener
-
Stasiek Michalski
-
Xu Zhao