[opensuse] Lastest Kernel update kernel-default-4.4.73-18.17.1.x86_64 causes crashes on shutdown
Before I write a bug report, I like to hear, if everyone else has problems with the latest openSUSE Leap 42.2 kernel update (kernel-default-4.4.73-18.17.1.x86_64)? If I try to shutdown or reboot the PC, the Kernel crashes at the end. As a work-around for the problem, that the PC is unresponsive after reboot action I set "kernel.panic = 20" in /etc/sysctl.d/reboot-after-kernel-panic.conf. This are the last messages. https://paste.opensuse.org/3930615 Some notes about the hardware: - main-board: Gigabyte H97-HD3 - CPU: Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz - RAM: 32 GB Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday 07 July 2017, Bjoern Voigt wrote:
Before I write a bug report, I like to hear, if everyone else has problems with the latest openSUSE Leap 42.2 kernel update (kernel-default-4.4.73-18.17.1.x86_64)?
If I try to shutdown or reboot the PC, the Kernel crashes at the end. As a work-around for the problem, that the PC is unresponsive after reboot action I set "kernel.panic = 20" in /etc/sysctl.d/reboot-after-kernel-panic.conf.
This are the last messages. https://paste.opensuse.org/3930615
Maybe this bug: https://bugzilla.suse.com/show_bug.cgi?id=1044294 For me it crashes when stopping Raid-1 devices. Do have also Raid-1 or another raid level? I have downgraded all my machines to kernel-default-4.4.62-18.6.1. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ruediger Meier wrote:
On Friday 07 July 2017, Bjoern Voigt wrote:
Before I write a bug report, I like to hear, if everyone else has problems with the latest openSUSE Leap 42.2 kernel update (kernel-default-4.4.73-18.17.1.x86_64)?
If I try to shutdown or reboot the PC, the Kernel crashes at the end. As a work-around for the problem, that the PC is unresponsive after reboot action I set "kernel.panic = 20" in /etc/sysctl.d/reboot-after-kernel-panic.conf. This are the last messages. https://paste.opensuse.org/3930615 Maybe this bug: https://bugzilla.suse.com/show_bug.cgi?id=1044294
For me it crashes when stopping Raid-1 devices. Do have also Raid-1 or another raid level?
I have downgraded all my machines to kernel-default-4.4.62-18.6.1. Thanks. I have RAID 5 on the affected server and subscribed the bug report now.
Kernel 4.4.72 had issues with my Java software (see https://bugzilla.suse.com/show_bug.cgi?id=1045340). I will probably stay at 4.4.73 or upgrade to a recent Kernel (like 4.12 or 4.11). Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, 7 July 2017 15:59:44 BST Bjoern Voigt wrote:
Before I write a bug report, I like to hear, if everyone else has problems with the latest openSUSE Leap 42.2 kernel update (kernel-default-4.4.73-18.17.1.x86_64)?
If I try to shutdown or reboot the PC, the Kernel crashes at the end. As a work-around for the problem, that the PC is unresponsive after reboot action I set "kernel.panic = 20" in /etc/sysctl.d/reboot-after-kernel-panic.conf.
This are the last messages. https://paste.opensuse.org/3930615
Some notes about the hardware: - main-board: Gigabyte H97-HD3 - CPU: Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz - RAM: 32 GB
Greetings, Björn
No issues reported here. Running on Toshiba Laptop which is about 6 years old. -- Sudhir Anand -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op vrijdag 7 juli 2017 15:59:44 CEST schreef Bjoern Voigt:
Before I write a bug report, I like to hear, if everyone else has problems with the latest openSUSE Leap 42.2 kernel update (kernel-default-4.4.73-18.17.1.x86_64)?
If I try to shutdown or reboot the PC, the Kernel crashes at the end. As a work-around for the problem, that the PC is unresponsive after reboot action I set "kernel.panic = 20" in /etc/sysctl.d/reboot-after-kernel-panic.conf.
This are the last messages. https://paste.opensuse.org/3930615
Some notes about the hardware: - main-board: Gigabyte H97-HD3 - CPU: Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz - RAM: 32 GB
Greetings, Björn
No issues either. Smooth reboot. Björn, after seeing the other posts, one would thiink it's indeed a RAID issue. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 7 Jul 2017 15:59:44 +0200 Bjoern Voigt wrote:
Before I write a bug report, I like to hear, if everyone else has problems with the latest openSUSE Leap 42.2 kernel update (kernel-default-4.4.73-18.17.1.x86_64)?
If I try to shutdown or reboot the PC, the Kernel crashes at the end. As a work-around for the problem, that the PC is unresponsive after reboot action I set "kernel.panic = 20" in /etc/sysctl.d/reboot-after-kernel-panic.conf.
This are the last messages. https://paste.opensuse.org/3930615
Some notes about the hardware: - main-board: Gigabyte H97-HD3 - CPU: Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz - RAM: 32 GB
Greetings, Björn
No problems here since installing the update on June 27th. This is on an eight year old dual core Asus laptop w/ 4 GB RAM and a two year old SSD. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/07/17 23:59, Bjoern Voigt wrote:
Before I write a bug report, I like to hear, if everyone else has problems with the latest openSUSE Leap 42.2 kernel update (kernel-default-4.4.73-18.17.1.x86_64)?
If I try to shutdown or reboot the PC, the Kernel crashes at the end. As a work-around for the problem, that the PC is unresponsive after reboot action I set "kernel.panic = 20" in /etc/sysctl.d/reboot-after-kernel-panic.conf.
This are the last messages. https://paste.opensuse.org/3930615
Some notes about the hardware: - main-board: Gigabyte H97-HD3 - CPU: Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz - RAM: 32 GB
Greetings, Björn
I have a copy of Leap 42.3 installed and kept up-to-date on almost a daily basis. This morning 42.3 received another update which also upgraded the kernel-default to 4.4.73 and now I am unable compile the nVidia driver (375.66) which I normally do after a kernel upgrade. When trying to compile the nVidia driver I get this the error msg: /quote Kernel module compilation complete. -> Unable to determine if Secure Boot is enabled: No such file or directory ERROR: Unable to load the kernel module 'nvidia-drm.ko'. This happens most frequently when this kernel module was built against the wrong or improperly configured kernel sources, with a version of gcc that differs from the one used to build the target kernel, or if a driver such as rivafb, nvidiafb, or nouveau is present and prevents the NVIDIA kernel module from obtaining ownership of the NVIDIA graphics device(s), or no NVIDIA GPU installed in this system is supported by this NVIDIA Linux graphics driver release. /unquote This is not the first time this has happened over the past weeks and some update to 42.3 days later often solves this problem. BC -- In a coffin there are no pockets. Russian proverb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Saturday, 8 July 2017 11:24:19 ACST Basil Chupin wrote:
[...] I have a copy of Leap 42.3 installed and kept up-to-date on almost a daily basis.
This morning 42.3 received another update which also upgraded the kernel-default to 4.4.73 and now I am unable compile the nVidia driver (375.66) which I normally do after a kernel upgrade.
When trying to compile the nVidia driver I get this the error msg:
/quote
Kernel module compilation complete. -> Unable to determine if Secure Boot is enabled: No such file or directory ERROR: Unable to load the kernel module 'nvidia-drm.ko'. This happens most frequently when this kernel module was built against the wrong or improperly configured kernel sources, with a version of gcc that differs from the one used to build the target kernel, or if a driver such as rivafb, nvidiafb, or nouveau is present and prevents the NVIDIA kernel module from obtaining ownership of the NVIDIA graphics device(s), or no NVIDIA GPU installed in this system is supported by this NVIDIA Linux graphics driver release.
/unquote
This is not the first time this has happened over the past weeks and some update to 42.3 days later often solves this problem.
BC
Suggest you update your nvidia driver to 381.22, or try the new beta 384.47 (or patch your 375.66 driver). Latest versions and patches can be found via the nvidia Linux forum - start here: https://devtalk.nvidia.com/default/topic/533434/linux/current-graphics-drive... BTW, it is also worth installing and setting up dkms - except when new kernel versions break the nvidia drivers, it makes kernel upgrades much easier by automatically building the nvidia modules for the new kernel (or, for an older kernel if you boot to one that has not had the driver module previously built). Regards, -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Rodney Baker wrote:
Suggest you update your nvidia driver to 381.22, or try the new beta 384.47 (or patch your 375.66 driver). Latest versions and patches can be found via the nvidia Linux forum - start here:
https://devtalk.nvidia.com/default/topic/533434/linux/current-graphics-drive...
BTW, it is also worth installing and setting up dkms - except when new kernel versions break the nvidia drivers, it makes kernel upgrades much easier by automatically building the nvidia modules for the new kernel (or, for an older kernel if you boot to one that has not had the driver module previously built). Why everyone is suggesting to use beta drivers from Nvidia?
I use the latest released driver 375.66. It needs a patch for Kernel 4.11 or 4.12: https://devtalk.nvidia.com/default/topic/1007266/patch-for-driver-375-39-wit... Regards, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday, 10 July 2017 17:27:00 ACST Bjoern Voigt wrote:
Rodney Baker wrote:
Suggest you update your nvidia driver to 381.22, or try the new beta 384.47 (or patch your 375.66 driver). Latest versions and patches can be found via the nvidia Linux forum - start here:
https://devtalk.nvidia.com/default/topic/533434/linux/current-graphics-dri ver-releases/
BTW, it is also worth installing and setting up dkms - except when new kernel versions break the nvidia drivers, it makes kernel upgrades much easier by automatically building the nvidia modules for the new kernel (or, for an older kernel if you boot to one that has not had the driver module previously built).
Why everyone is suggesting to use beta drivers from Nvidia?
I use the latest released driver 375.66. It needs a patch for Kernel 4.11 or 4.12: https://devtalk.nvidia.com/default/topic/1007266/patch-for-driver-375-39-wit h-stable-kernel-4-11/?offset=3
Regards, Björn
381.22 are not beta drivers - they are the latest official release version and are already patched for 4.11 and 4.12 kernels. Check out the support forums linked above. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Rodney Baker wrote:
381.22 are not beta drivers - they are the latest official release version and are already patched for 4.11 and 4.12 kernels. Check out the support forums linked above. The Nvidia driver search form http://www.nvidia.com/ says, that 375.66 is the latest released driver. But here http://www.nvidia.de/Download/Find.aspx?lang=en 381.22 is the latest driver. Nvidia should probably fix their nvidia.com pages. Thanks.
Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, 12 July 2017 7:38:32 ACST Bjoern Voigt wrote:
Rodney Baker wrote:
381.22 are not beta drivers - they are the latest official release version and are already patched for 4.11 and 4.12 kernels. Check out the support forums linked above.
The Nvidia driver search form http://www.nvidia.com/ says, that 375.66 is the latest released driver. But here http://www.nvidia.de/Download/Find.aspx?lang=en 381.22 is the latest driver. Nvidia should probably fix their nvidia.com pages. Thanks.
Greetings, Björn
That’s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :) -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/07/17 21:38, Rodney Baker wrote:
On Wednesday, 12 July 2017 7:38:32 ACST Bjoern Voigt wrote:
Rodney Baker wrote:
381.22 are not beta drivers - they are the latest official release version and are already patched for 4.11 and 4.12 kernels. Check out the support forums linked above. The Nvidia driver search form http://www.nvidia.com/ says, that 375.66 is the latest released driver. But here http://www.nvidia.de/Download/Find.aspx?lang=en 381.22 is the latest driver. Nvidia should probably fix their nvidia.com pages. Thanks.
Greetings, Björn That’s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :)
Ah, you seem to have answered my question I asked in another message. Does this really mean that a driver for a 64-bit Linux system will work on any nVidia GPU card installed on a 64-bit Linux-running computer? Only asking just to be sure :-). BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/07/17 12:25, Rodney Baker wrote:
[...] I have a copy of Leap 42.3 installed and kept up-to-date on almost a daily basis.
This morning 42.3 received another update which also upgraded the kernel-default to 4.4.73 and now I am unable compile the nVidia driver (375.66) which I normally do after a kernel upgrade.
When trying to compile the nVidia driver I get this the error msg:
/quote
Kernel module compilation complete. -> Unable to determine if Secure Boot is enabled: No such file or directory ERROR: Unable to load the kernel module 'nvidia-drm.ko'. This happens most frequently when this kernel module was built against the wrong or improperly configured kernel sources, with a version of gcc that differs from the one used to build the target kernel, or if a driver such as rivafb, nvidiafb, or nouveau is present and prevents the NVIDIA kernel module from obtaining ownership of the NVIDIA graphics device(s), or no NVIDIA GPU installed in this system is supported by this NVIDIA Linux graphics driver release.
/unquote
This is not the first time this has happened over the past weeks and some update to 42.3 days later often solves this problem.
BC Suggest you update your nvidia driver to 381.22, or try the new beta 384.47 (or patch your 375.66 driver). Latest versions and patches can be found via
On Saturday, 8 July 2017 11:24:19 ACST Basil Chupin wrote: the nvidia Linux forum - start here:
https://devtalk.nvidia.com/default/topic/533434/linux/current-graphics-drive...
BTW, it is also worth installing and setting up dkms - except when new kernel versions break the nvidia drivers, it makes kernel upgrades much easier by automatically building the nvidia modules for the new kernel (or, for an older kernel if you boot to one that has not had the driver module previously built).
Regards,
Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU. The nVidia web page https://www.geforce.com/drivers does not show the driver 381.22 when I do a search for the driver for my card but shows 375.66 as the latest driver for my GTX 660 card. Is this because that page has yet to be updated to show 381.22 or is it because this driver is not suitable for my GPU? Would appreciate your comment as I would rather, for personal reasons, not go wading thru the nVidia Forum to find an answer. BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 07:48]:
On 09/07/17 12:25, Rodney Baker wrote:
[...] I have a copy of Leap 42.3 installed and kept up-to-date on almost a daily basis.
This morning 42.3 received another update which also upgraded the kernel-default to 4.4.73 and now I am unable compile the nVidia driver (375.66) which I normally do after a kernel upgrade.
When trying to compile the nVidia driver I get this the error msg:
/quote
Kernel module compilation complete. -> Unable to determine if Secure Boot is enabled: No such file or directory ERROR: Unable to load the kernel module 'nvidia-drm.ko'. This happens most frequently when this kernel module was built against the wrong or improperly configured kernel sources, with a version of gcc that differs from the one used to build the target kernel, or if a driver such as rivafb, nvidiafb, or nouveau is present and prevents the NVIDIA kernel module from obtaining ownership of the NVIDIA graphics device(s), or no NVIDIA GPU installed in this system is supported by this NVIDIA Linux graphics driver release.
/unquote
This is not the first time this has happened over the past weeks and some update to 42.3 days later often solves this problem.
BC Suggest you update your nvidia driver to 381.22, or try the new beta 384.47 (or patch your 375.66 driver). Latest versions and patches can be found via
On Saturday, 8 July 2017 11:24:19 ACST Basil Chupin wrote: the nvidia Linux forum - start here:
https://devtalk.nvidia.com/default/topic/533434/linux/current-graphics-drive...
BTW, it is also worth installing and setting up dkms - except when new kernel versions break the nvidia drivers, it makes kernel upgrades much easier by automatically building the nvidia modules for the new kernel (or, for an older kernel if you boot to one that has not had the driver module previously built).
Regards,
Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU.
The nVidia web page
https://www.geforce.com/drivers
does not show the driver 381.22 when I do a search for the driver for my card but shows 375.66 as the latest driver for my GTX 660 card. Is this because that page has yet to be updated to show 381.22 or is it because this driver is not suitable for my GPU? Would appreciate your comment as I would rather, for personal reasons, not go wading thru the nVidia Forum to find an answer.
http://download.nvidia.com/XFree86/Linux-x86_64/ -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/07/17 21:50, Patrick Shanahan wrote:
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 07:48]:
On 09/07/17 12:25, Rodney Baker wrote:
On Saturday, 8 July 2017 11:24:19 ACST Basil Chupin wrote: [pruned]
Suggest you update your nvidia driver to 381.22, or try the new beta 384.47 (or patch your 375.66 driver). Latest versions and patches can be found via the nvidia Linux forum - start here:
https://devtalk.nvidia.com/default/topic/533434/linux/current-graphics-drive...
BTW, it is also worth installing and setting up dkms - except when new kernel versions break the nvidia drivers, it makes kernel upgrades much easier by automatically building the nvidia modules for the new kernel (or, for an older kernel if you boot to one that has not had the driver module previously built).
Regards, Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU.
The nVidia web page
https://www.geforce.com/drivers
does not show the driver 381.22 when I do a search for the driver for my card but shows 375.66 as the latest driver for my GTX 660 card. Is this because that page has yet to be updated to show 381.22 or is it because this driver is not suitable for my GPU? Would appreciate your comment as I would rather, for personal reasons, not go wading thru the nVidia Forum to find an answer.
Thank you, Patrick. URL now copied into Bookmarks. BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Basil Chupin wrote:
http://download.nvidia.com/XFree86/Linux-x86_64/ Thank you, Patrick. URL now copied into Bookmarks. The URL above contains a file "latest.txt" with the content:
375.66 375.66/NVIDIA-Linux-x86_64-375.66.run How could I find out best, which from the drivers is marked as stable: 375.66/ 378.09/ 378.13/ 381.09/ 381.22/ 384.47/ Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Bjoern Voigt <bjoernv@arcor.de> [07-14-17 07:32]:
Basil Chupin wrote:
http://download.nvidia.com/XFree86/Linux-x86_64/ Thank you, Patrick. URL now copied into Bookmarks. The URL above contains a file "latest.txt" with the content:
375.66 375.66/NVIDIA-Linux-x86_64-375.66.run
How could I find out best, which from the drivers is marked as stable:
375.66/ 378.09/ 378.13/ 381.09/ 381.22/ 384.47/
http://www.nvidia.com for "marked as stable" but any/all may actually be "stable" on your hardware. download them and try. install is simple, "sh ./NVIDIA-Linux-x86_64-384.47.run -aqs". I have used each w/o a problem past maybe requiring a patch for which ever kernel was current atm and I have to use "--install-libglvnd" for *my* nvidia box. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-14 13:49, Patrick Shanahan wrote:
* Bjoern Voigt <bjoernv@arcor.de> [07-14-17 07:32]:
Basil Chupin wrote:
http://download.nvidia.com/XFree86/Linux-x86_64/ Thank you, Patrick. URL now copied into Bookmarks. The URL above contains a file "latest.txt" with the content:
375.66 375.66/NVIDIA-Linux-x86_64-375.66.run
How could I find out best, which from the drivers is marked as stable:
375.66/ 378.09/ 378.13/ 381.09/ 381.22/ 384.47/
http://www.nvidia.com for "marked as stable"
but any/all may actually be "stable" on your hardware. download them and try. install is simple, "sh ./NVIDIA-Linux-x86_64-384.47.run -aqs". I have used each w/o a problem past maybe requiring a patch for which ever kernel was current atm and I have to use "--install-libglvnd" for *my* nvidia box.
It may take weeks to find out. I may notice that my system crashes during hibernation, once every week, say, and reverting the nvidia driver to an older version works. As a rule, I install the first driver that comes with the distribution release, and never update it if it works. Thus, with Leap 42.2 I use Nvidia 340.102. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Fri, 14 Jul 2017 13:59:09 +0200 Carlos E. R. wrote:
It may take weeks to find out. I may notice that my system crashes during hibernation, once every week, say, and reverting the nvidia driver to an older version works.
As a rule, I install the first driver that comes with the distribution release, and never update it if it works. Thus, with Leap 42.2 I use Nvidia 340.102.
My 'fallback' 42.2 system is also running 340.102(-17.1.) It has a 'legacy' GeForce 9300M GS adapter, which isn't supported by the later (and current) 'unified' driver. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-14 14:33, Carl Hartung wrote:
On Fri, 14 Jul 2017 13:59:09 +0200 Carlos E. R. wrote:
It may take weeks to find out. I may notice that my system crashes during hibernation, once every week, say, and reverting the nvidia driver to an older version works.
As a rule, I install the first driver that comes with the distribution release, and never update it if it works. Thus, with Leap 42.2 I use Nvidia 340.102.
My 'fallback' 42.2 system is also running 340.102(-17.1.) It has a 'legacy' GeForce 9300M GS adapter, which isn't supported by the later (and current) 'unified' driver.
I have a GeForce 9500 GT. You are worrying me. Will mine be supported? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Fri, 14 Jul 2017 14:47:49 +0200 Carlos E. R. wrote:
On 2017-07-14 14:33, Carl Hartung wrote:
On Fri, 14 Jul 2017 13:59:09 +0200 Carlos E. R. wrote:
It may take weeks to find out. I may notice that my system crashes during hibernation, once every week, say, and reverting the nvidia driver to an older version works.
As a rule, I install the first driver that comes with the distribution release, and never update it if it works. Thus, with Leap 42.2 I use Nvidia 340.102.
My 'fallback' 42.2 system is also running 340.102(-17.1.) It has a 'legacy' GeForce 9300M GS adapter, which isn't supported by the later (and current) 'unified' driver.
I have a GeForce 9500 GT. You are worrying me. Will mine be supported?
That wasn't my intention, Carlos! :) I wouldn't worry too much about it. They still seem to be maintaining 'legacy' drivers for much older adapters than what we're running. regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Freitag, 14. Juli 2017, 13:30:44 schrieb Bjoern Voigt:
Basil Chupin wrote:
Thank you, Patrick. URL now copied into Bookmarks.
The URL above contains a file "latest.txt" with the content:
375.66 375.66/NVIDIA-Linux-x86_64-375.66.run
How could I find out best, which from the drivers is marked as stable:
There is <https://devtalk.nvidia.com/default/board/99/unix-graphics-announcements-and-news/> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-13 12:06, Basil Chupin wrote:
On 09/07/17 12:25, Rodney Baker wrote:
Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU.
On another post Rodney said this: That’s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 13/07/17 22:21, Carlos E. R. wrote:
On 2017-07-13 12:06, Basil Chupin wrote:
On 09/07/17 12:25, Rodney Baker wrote:
Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU. On another post Rodney said this:
That’s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :-) Yep, I saw that and answered. But how about you giving me the answer to what I also asked but awaiting an answer? :-) :
/quote Ah, you seem to have answered my question I asked in another message. Does this really mean that a driver for a 64-bit Linux system will work on any nVidia GPU card installed on a 64-bit Linux-running computer? Only asking just to be sure . /unquote Reason for the above is that I see that there are Legacy Drivers for the GTX 660 and the 550 GPUs which are not numbered 381.22. Will 381.22 work with 660 and 550 cards? BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-14 02:56, Basil Chupin wrote:
On 13/07/17 22:21, Carlos E. R. wrote:
On 2017-07-13 12:06, Basil Chupin wrote:
On 09/07/17 12:25, Rodney Baker wrote:
Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU. On another post Rodney said this:
That’s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :-) Yep, I saw that and answered. But how about you giving me the answer to what I also asked but awaiting an answer? :-) :
/quote
Ah, you seem to have answered my question I asked in another message.
Does this really mean that a driver for a 64-bit Linux system will work on any nVidia GPU card installed on a 64-bit Linux-running computer? Only asking just to be sure .
/unquote
Well, I don't know for sure, but I guess so. But...
Reason for the above is that I see that there are Legacy Drivers for the GTX 660 and the 550 GPUs which are not numbered 381.22. Will 381.22 work with 660 and 550 cards?
...but not that. The driver has to be for the right type of card. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 20:57]:
On 13/07/17 22:21, Carlos E. R. wrote:
On 2017-07-13 12:06, Basil Chupin wrote:
On 09/07/17 12:25, Rodney Baker wrote:
Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU. On another post Rodney said this:
That’s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :-) Yep, I saw that and answered. But how about you giving me the answer to what I also asked but awaiting an answer? :-) :
/quote
Ah, you seem to have answered my question I asked in another message.
Does this really mean that a driver for a 64-bit Linux system will work on any nVidia GPU card installed on a 64-bit Linux-running computer? Only asking just to be sure .
/unquote
Reason for the above is that I see that there are Legacy Drivers for the GTX 660 and the 550 GPUs which are not numbered 381.22. Will 381.22 work with 660 and 550 cards?
for the latest drivers to work with my GT450, I must add: sh ./NVIDIA-Linux-x86_64-384.47.run -aqs --install-libglvnd -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/07/17 12:01, Patrick Shanahan wrote:
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 20:57]:
On 13/07/17 22:21, Carlos E. R. wrote:
On 2017-07-13 12:06, Basil Chupin wrote:
On 09/07/17 12:25, Rodney Baker wrote: Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU. On another post Rodney said this:
That�s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :-) Yep, I saw that and answered. But how about you giving me the answer to what I also asked but awaiting an answer? :-) :
/quote
Ah, you seem to have answered my question I asked in another message.
Does this really mean that a driver for a 64-bit Linux system will work on any nVidia GPU card installed on a 64-bit Linux-running computer? Only asking just to be sure .
/unquote
Reason for the above is that I see that there are Legacy Drivers for the GTX 660 and the 550 GPUs which are not numbered 381.22. Will 381.22 work with 660 and 550 cards? for the latest drivers to work with my GT450, I must add: sh ./NVIDIA-Linux-x86_64-384.47.run -aqs --install-libglvnd
And once again I have to say: "Thank you, Patrick!" :-). I just tried to install/compile the latest driver and even the Legacy driver for the 660 and all bombed out; in one, case error msg: "unable to load 'nvidia-drm', and in the other "...nvidia-drm.ko". This with DKMS. So, now to add the parameters you mention above... BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 23:00]:
On 14/07/17 12:01, Patrick Shanahan wrote:
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 20:57]:
On 13/07/17 22:21, Carlos E. R. wrote:
On 2017-07-13 12:06, Basil Chupin wrote:
On 09/07/17 12:25, Rodney Baker wrote: Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU. On another post Rodney said this:
That�s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :-) Yep, I saw that and answered. But how about you giving me the answer to what I also asked but awaiting an answer? :-) :
/quote
Ah, you seem to have answered my question I asked in another message.
Does this really mean that a driver for a 64-bit Linux system will work on any nVidia GPU card installed on a 64-bit Linux-running computer? Only asking just to be sure .
/unquote
Reason for the above is that I see that there are Legacy Drivers for the GTX 660 and the 550 GPUs which are not numbered 381.22. Will 381.22 work with 660 and 550 cards? for the latest drivers to work with my GT450, I must add: sh ./NVIDIA-Linux-x86_64-384.47.run -aqs --install-libglvnd
And once again I have to say: "Thank you, Patrick!" :-).
I just tried to install/compile the latest driver and even the Legacy driver for the 660 and all bombed out; in one, case error msg: "unable to load 'nvidia-drm', and in the other "...nvidia-drm.ko". This with DKMS.
So, now to add the parameters you mention above...
you did read the error messages. if libglvnd was not mentioned, that parameter will not help. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/07/17 13:08, Patrick Shanahan wrote:
On 14/07/17 12:01, Patrick Shanahan wrote:
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 20:57]:
On 13/07/17 22:21, Carlos E. R. wrote:
On 2017-07-13 12:06, Basil Chupin wrote:
On 09/07/17 12:25, Rodney Baker wrote: Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU. On another post Rodney said this:
That�s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :-) Yep, I saw that and answered. But how about you giving me the answer to what I also asked but awaiting an answer? :-) :
/quote
Ah, you seem to have answered my question I asked in another message.
Does this really mean that a driver for a 64-bit Linux system will work on any nVidia GPU card installed on a 64-bit Linux-running computer? Only asking just to be sure .
/unquote
Reason for the above is that I see that there are Legacy Drivers for the GTX 660 and the 550 GPUs which are not numbered 381.22. Will 381.22 work with 660 and 550 cards? for the latest drivers to work with my GT450, I must add: sh ./NVIDIA-Linux-x86_64-384.47.run -aqs --install-libglvnd And once again I have to say: "Thank you, Patrick!" :-).
I just tried to install/compile the latest driver and even the Legacy driver for the 660 and all bombed out; in one, case error msg: "unable to load 'nvidia-drm', and in the other "...nvidia-drm.ko". This with DKMS.
So, now to add the parameters you mention above... you did read the error messages. if libglvnd was not mentioned, that
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 23:00]: parameter will not help.
Groooaaan :-(. But nevertheless I shall press on..with a cheerful smile on my face and the comforting thought that Leap 42.3 is, afterall, only a Beta...only a Beta...only a Beta... BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/07/17 14:12, Basil Chupin wrote:
On 14/07/17 13:08, Patrick Shanahan wrote:
On 14/07/17 12:01, Patrick Shanahan wrote:
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 20:57]:
On 13/07/17 22:21, Carlos E. R. wrote:
On 2017-07-13 12:06, Basil Chupin wrote: > On 09/07/17 12:25, Rodney Baker wrote: > Thank you, Rodney, for this info. But I have a question re the above and > what I normally see when I go to NVidia to download the latest driver > for my GPU. On another post Rodney said this:
That�s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :-) Yep, I saw that and answered. But how about you giving me the answer to what I also asked but awaiting an answer? :-) :
/quote
Ah, you seem to have answered my question I asked in another message.
Does this really mean that a driver for a 64-bit Linux system will work on any nVidia GPU card installed on a 64-bit Linux-running computer? Only asking just to be sure .
/unquote
Reason for the above is that I see that there are Legacy Drivers for the GTX 660 and the 550 GPUs which are not numbered 381.22. Will 381.22 work with 660 and 550 cards? for the latest drivers to work with my GT450, I must add: sh ./NVIDIA-Linux-x86_64-384.47.run -aqs --install-libglvnd And once again I have to say: "Thank you, Patrick!" :-).
I just tried to install/compile the latest driver and even the Legacy driver for the 660 and all bombed out; in one, case error msg: "unable to load 'nvidia-drm', and in the other "...nvidia-drm.ko". This with DKMS.
So, now to add the parameters you mention above... you did read the error messages. if libglvnd was not mentioned, that
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 23:00]: parameter will not help. Groooaaan :-(. But nevertheless I shall press on..with a cheerful smile on my face and the comforting thought that Leap 42.3 is, afterall, only a Beta...only a Beta...only a Beta...
All now hunky-dory in Leap 42.3 :-). I installed the latest stable kernel 4.12.1 and used the NVidia driver 381.22. During the installation/compilation I selected DKMS and all went well :-). Happiness is a correctly working openSUSE with the latest _proper_ nVidia driver -- NOT nouveau -- installed :-). (And now to mess-up Leap 42.2...) BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/14/2017 01:30 AM, Basil Chupin wrote:
Happiness is a correctly working openSUSE with the latest _proper_ nVidia driver -- NOT nouveau -- installed :-).
(And now to mess-up Leap 42.2...)
Chuckling.... Glad you got it going BC. I'm a bit ambivalent on the nvidia/nouveau issue. When compiz was king and proprietary drivers were needed to make it usable -- I completely agree with you. However, if not using the whiz-bang animations, the nouveau driver provides a lot of benefit that the proprietary driver can't or won't related to the default console itself. Like auto-sizing of the default console to optimal resolution. DPMS poweroff, etc.. Backlight control via /sys/class/backlight (although Kudos to Stefan and team for fixing http://bugzilla.opensuse.org/show_bug.cgi?id=1040718 so it works with the proprietary driver as well now :) Now, of course, I'm no gamer, and I don't watch video, but for the couple of Webinar's I have watched, the nouveau driver did fine. If I did push the GPU more, then I may have more rocks to throw at nouveau, but I can happily report for the 6 months or so I used it with Leap 42.2 - I literally had no complaints. I do have the nvidia driver installed now, and I don't have any complaints there either -- other than the GPU temp does run a bit hotter with it -- but not enough to be any type of an issue, I suspect it's just using more of it than the nouveau driver does. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/14/2017 08:31 PM, David C. Rankin wrote:
On 07/14/2017 01:30 AM, Basil Chupin wrote:
Happiness is a correctly working openSUSE with the latest _proper_ nVidia driver -- NOT nouveau -- installed :-).
(And now to mess-up Leap 42.2...)
Chuckling....
Glad you got it going BC.
I'm a bit ambivalent on the nvidia/nouveau issue. When compiz was king and proprietary drivers were needed to make it usable -- I completely agree with you. However, if not using the whiz-bang animations, the nouveau driver provides a lot of benefit that the proprietary driver can't or won't related to the default console itself. Like auto-sizing of the default console to optimal resolution. DPMS poweroff, etc.. Backlight control via /sys/class/backlight (although Kudos to Stefan and team for fixing http://bugzilla.opensuse.org/show_bug.cgi?id=1040718 so it works with the proprietary driver as well now :)
Now, of course, I'm no gamer, and I don't watch video, but for the couple of Webinar's I have watched, the nouveau driver did fine. If I did push the GPU more, then I may have more rocks to throw at nouveau, but I can happily report for the 6 months or so I used it with Leap 42.2 - I literally had no complaints. I do have the nvidia driver installed now, and I don't have any complaints there either -- other than the GPU temp does run a bit hotter with it -- but not enough to be any type of an issue, I suspect it's just using more of it than the nouveau driver does.
I'd still like to know where (what repository) one finds a opensuse 4.11 or 4.12 kernel that might work in 42.2 or 42.3. There are some amazing swap handling improvements scheduled to arrive in any kernel 4.11 or later, which really are supposed to make major improvements when swap is on an SSD. (to the point of making swap desirable again). -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/14/2017 10:36 PM, John Andersen wrote:
I'd still like to know where (what repository) one finds a opensuse 4.11 or 4.12 kernel that might work in 42.2 or 42.3.
Have you tried building from source with your current kernel config? The latest bleeding edge kernel release is 4.11.9 and it is working fine in Arch. I just don't know what if any suse specific patches would be needed. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
I'd still like to know where (what repository) one finds a opensuse 4.11 or 4.12 kernel that might work in 42.2 or 42.3.
There are some amazing swap handling improvements scheduled to arrive in any kernel 4.11 or later, which really are supposed to make major improvements when swap is on an SSD. (to the point of making swap desirable again).
Well, if you want a repo you could use Kernel-HEAD (http://download.opensuse.org/repositories/Kernel:/HEAD/standard/) That is bleeding edge though... When I needed a more recent one for one of my Leap machines I went for the TW one, but without adding the repo. Just downloaded the relevant rpms and installed them. But you'd have to watch for security issues yourself. Should also be possible to add the TW repo and only install the kernel from there, and then disable again so you don't get wrong packages by accident... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op zaterdag 15 juli 2017 15:42:29 CEST schreef pit:
John Andersen wrote:
I'd still like to know where (what repository) one finds a opensuse 4.11 or 4.12 kernel that might work in 42.2 or 42.3.
There are some amazing swap handling improvements scheduled to arrive in any kernel 4.11 or later, which really are supposed to make major improvements when swap is on an SSD. (to the point of making swap desirable again). Well, if you want a repo you could use Kernel-HEAD (http://download.opensuse.org/repositories/Kernel:/HEAD/standard/) That is bleeding edge though...
When I needed a more recent one for one of my Leap machines I went for the TW one, but without adding the repo. Just downloaded the relevant rpms and installed them. But you'd have to watch for security issues yourself.
Should also be possible to add the TW repo and only install the kernel from there, and then disable again so you don't get wrong packages by accident...
Please, don't even suggest such things. Why break consistency, intergrity of a system's repos. And make it a completely manual operation that no one understands but you. If I was asked to maintain such a system, the answer would be No. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Knurpht - Gertjan Lettink wrote:
Op zaterdag 15 juli 2017 15:42:29 CEST schreef pit:
Well, if you want a repo you could use Kernel-HEAD (http://download.opensuse.org/repositories/Kernel:/HEAD/standard/) That is bleeding edge though...
When I needed a more recent one for one of my Leap machines I went for the TW one, but without adding the repo. Just downloaded the relevant rpms and installed them. But you'd have to watch for security issues yourself.
Should also be possible to add the TW repo and only install the kernel from there, and then disable again so you don't get wrong packages by accident...
Please, don't even suggest such things.
You mean the temporarily add repo thing? Or also the use-the-TW-kernel? The outcome of both is the same, and not really much different (or more inconsistent) than using the kernel-stable repo - the kernels there have not been compiled on an 42.2 system either....
Why break consistency, intergrity of a system's repos. And make it a completely manual operation that no one understands but you. If I was asked to maintain such a system, the answer would be No.
I'm not asking you to do so :D And I'm neither in a mood for a 'fight', so I'll just shut up... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op maandag 17 juli 2017 19:44:44 CEST schreef Peter Suetterlin:
Knurpht - Gertjan Lettink wrote:
Op zaterdag 15 juli 2017 15:42:29 CEST schreef pit:
Well, if you want a repo you could use Kernel-HEAD (http://download.opensuse.org/repositories/Kernel:/HEAD/standard/) That is bleeding edge though...
When I needed a more recent one for one of my Leap machines I went for the TW one, but without adding the repo. Just downloaded the relevant rpms and installed them. But you'd have to watch for security issues yourself.
Should also be possible to add the TW repo and only install the kernel from there, and then disable again so you don't get wrong packages by accident...> Please, don't even suggest such things.
You mean the temporarily add repo thing? Or also the use-the-TW-kernel? The outcome of both is the same, and not really much different (or more inconsistent) than using the kernel-stable repo - the kernels there have not been compiled on an 42.2 system either....
Why break consistency, intergrity of a system's repos. And make it a completely manual operation that no one understands but you. If I was asked to maintain such a system, the answer would be No.
I'm not asking you to do so :D And I'm neither in a mood for a 'fight', so I'll just shut up...
Hey, a fight was never my intention. We 'teach' new users to stick to the distribution repos ( + Packman for desktops ). Adding home:/ , devel:/ and/or openSUSE_Not_The_Running_Version is completely the opposite. In the forums we're ( as an almost daily routine ) dealing with people getting in trouble by mixing/adding repos. IMHO we should not propagate such 'solutions'. -- Gertjan Lettink, a.k.a. Knurphti openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-17 20:00, Knurpht - Gertjan Lettink wrote:
Op maandag 17 juli 2017 19:44:44 CEST schreef Peter Suetterlin:
Knurpht - Gertjan Lettink wrote:
Op zaterdag 15 juli 2017 15:42:29 CEST schreef pit:
Well, if you want a repo you could use Kernel-HEAD (http://download.opensuse.org/repositories/Kernel:/HEAD/standard/) That is bleeding edge though...
When I needed a more recent one for one of my Leap machines I went for the TW one, but without adding the repo. Just downloaded the relevant rpms and installed them. But you'd have to watch for security issues yourself.
Should also be possible to add the TW repo and only install the kernel from there, and then disable again so you don't get wrong packages by accident...> Please, don't even suggest such things.
You mean the temporarily add repo thing? Or also the use-the-TW-kernel? The outcome of both is the same, and not really much different (or more inconsistent) than using the kernel-stable repo - the kernels there have not been compiled on an 42.2 system either....
Why break consistency, intergrity of a system's repos. And make it a completely manual operation that no one understands but you. If I was asked to maintain such a system, the answer would be No.
I'm not asking you to do so :D And I'm neither in a mood for a 'fight', so I'll just shut up...
Hey, a fight was never my intention. We 'teach' new users to stick to the distribution repos ( + Packman for desktops ). Adding home:/ , devel:/ and/or openSUSE_Not_The_Running_Version is completely the opposite. In the forums we're ( as an almost daily routine ) dealing with people getting in trouble by mixing/adding repos. IMHO we should not propagate such 'solutions'.
But you must point people to the appropriate repo when they need a recent kernel that solves their problem - namely, that the Leap kernel simply does not work on their computers. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Op dinsdag 18 juli 2017 12:53:48 CEST schreef Carlos E. R.:
On 2017-07-17 20:00, Knurpht - Gertjan Lettink wrote:
Op maandag 17 juli 2017 19:44:44 CEST schreef Peter Suetterlin:
Knurpht - Gertjan Lettink wrote:
Op zaterdag 15 juli 2017 15:42:29 CEST schreef pit:
Well, if you want a repo you could use Kernel-HEAD (http://download.opensuse.org/repositories/Kernel:/HEAD/standard/) That is bleeding edge though...
When I needed a more recent one for one of my Leap machines I went for the TW one, but without adding the repo. Just downloaded the relevant rpms and installed them. But you'd have to watch for security issues yourself.
Should also be possible to add the TW repo and only install the kernel from there, and then disable again so you don't get wrong packages by accident...>
Please, don't even suggest such things.
You mean the temporarily add repo thing? Or also the use-the-TW-kernel? The outcome of both is the same, and not really much different (or more inconsistent) than using the kernel-stable repo - the kernels there have not been compiled on an 42.2 system either....
Why break consistency, intergrity of a system's repos. And make it a completely manual operation that no one understands but you. If I was asked to maintain such a system, the answer would be No.
I'm not asking you to do so :D And I'm neither in a mood for a 'fight', so I'll just shut up...
Hey, a fight was never my intention. We 'teach' new users to stick to the distribution repos ( + Packman for desktops ). Adding home:/ , devel:/ and/or openSUSE_Not_The_Running_Version is completely the opposite. In the forums we're ( as an almost daily routine ) dealing with people getting in trouble by mixing/adding repos. IMHO we should not propagate such 'solutions'. But you must point people to the appropriate repo when they need a recent kernel that solves their problem - namely, that the Leap kernel simply does not work on their computers.
Agreed to that exception. But in such cases people should also be stimulated to file bugreports, so that the necessary patches / fixes can be backported to Leap's kernel version. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/18/2017 04:32 AM, Knurpht - Gertjan Lettink wrote:
Agreed to that exception. But in such cases people should also be stimulated to file bugreports, so that the necessary patches / fixes can be backported to Leap's kernel version.
But unless its a security issue, the stated opensuse policy is to not mess with the kernel. So this is likely to prove fruitless. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op dinsdag 18 juli 2017 18:29:53 CEST schreef John Andersen:
On 07/18/2017 04:32 AM, Knurpht - Gertjan Lettink wrote:
Agreed to that exception. But in such cases people should also be stimulated to file bugreports, so that the necessary patches / fixes can be backported to Leap's kernel version.
But unless its a security issue, the stated opensuse policy is to not mess with the kernel. So this is likely to prove fruitless.
So, what SUSE is doing with the SLE kernel is fruitless. Good their customers don't know :D. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday 19 July 2017, Knurpht - Gertjan Lettink wrote:
Op dinsdag 18 juli 2017 18:29:53 CEST schreef John Andersen:
On 07/18/2017 04:32 AM, Knurpht - Gertjan Lettink wrote:
Agreed to that exception. But in such cases people should also be stimulated to file bugreports, so that the necessary patches / fixes can be backported to Leap's kernel version.
But unless its a security issue, the stated opensuse policy is to not mess with the kernel. So this is likely to prove fruitless.
So, what SUSE is doing with the SLE kernel is fruitless. Good their customers don't know :D.
No, everybody appreciates bugfix kernel updates for SLE or openSUSE. But sometimes, if you buy the newest hardware, you need a newer kernel to be able to use an existing distro. This is a general Linux problem (not micro kernel). For Linux distros it makes usually no sense to report bugs regarding unsupported hardware. Though it would be nice to have repos for the users offering certain kernel versions. I know we have such repos but nothing like reasonable "LTS backport support". For Ubuntu it's much easier and better supported to get newer kernels for older distro releases. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Knurpht - Gertjan Lettink wrote:
Hey, a fight was never my intention.
I know. Just teasing ;^>
We 'teach' new users to stick to the distribution repos ( + Packman for desktops ). Adding home:/ , devel:/ and/or openSUSE_Not_The_Running_Version is completely the opposite. In the forums we're ( as an almost daily routine ) dealing with people getting in trouble by mixing/adding repos. IMHO we should not propagate such 'solutions'.
I completely unterstand the motivation. But very often it is not possible to run without non-standard repos, that is just reality. Be it some harware that needs a newer kernel or libs that need special compile time settings or versions of software not in the standard repo. If you answer those people with a 'no solution, live with it' they probably leave disappointed. So a clear warning 'no blind copy-paste! Only do if you *know* what this does' is OK. A ban of even mentioning such solutions is not (IMVHO). Many of the really-valuable tips I get from this forum are in the !!! category. Without them it would be a much more dull place here.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday 18 July 2017, Peter Suetterlin wrote:
Knurpht - Gertjan Lettink wrote:
Hey, a fight was never my intention.
I know. Just teasing ;^>
We 'teach' new users to stick to the distribution repos ( + Packman for desktops ). Adding home:/ , devel:/ and/or openSUSE_Not_The_Running_Version is completely the opposite. In the forums we're ( as an almost daily routine ) dealing with people getting in trouble by mixing/adding repos. IMHO we should not propagate such 'solutions'.
I completely unterstand the motivation. But very often it is not possible to run without non-standard repos, that is just reality. Be it some harware that needs a newer kernel or libs that need special compile time settings or versions of software not in the standard repo. If you answer those people with a 'no solution, live with it' they probably leave disappointed.
So a clear warning 'no blind copy-paste! Only do if you *know* what this does' is OK. A ban of even mentioning such solutions is not (IMVHO).
Yes, I'm also using openSUSE 13.1 on many systems with 42.2:Update repo to get a newer Kernel. There are no problems.
Many of the really-valuable tips I get from this forum are in the !!! category. Without them it would be a much more dull place here....
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/07/17 11:36 PM, John Andersen wrote:
I'd still like to know where (what repository) one finds a opensuse 4.11 or 4.12 kernel that might work in 42.2 or 42.3.
There are some amazing swap handling improvements scheduled to arrive in any kernel 4.11 or later, which really are supposed to make major improvements when swap is on an SSD. (to the point of making swap desirable again).
I'm running # uname -a Linux main.HOME.SystemI.ca 4.12.1-1.gb24ee10-default #1 SMP PREEMPT Wed Jul 12 15:08:48 UTC 2017 (b24ee10) x86_64 x86_64 x86_64 GNU/Linux and that comes from the repository Kernel_Stable Information for package kernel-default: --------------------------------------- Repository : Kernel_Stable Name : kernel-default Version : 4.12.1-1.1.gb24ee10 Arch : x86_64 Vendor : obs://build.opensuse.org/Kernel Installed Size : 330.2 MiB Installed : Yes Status : up-to-date Source package : kernel-default-4.12.1-1.1.gb24ee10.nosrc Summary : The Standard Kernel Description : The standard kernel for both uniprocessor and multiprocessor systems. Source Timestamp: 2017-07-12 17:08:48 +0200 GIT Revision: b24ee102c8a070ce5a3e40b8bfb2402195fdd914 GIT Branch: stable No need for bleeding edge http://download.opensuse.org/repositories/Kernel:/stable/standard/ -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/15/2017 07:22 AM, Anton Aylward wrote:
No need for bleeding edge
http://download.opensuse.org/repositories/Kernel:/stable/standard/
Thanks, that was wat I was looking for. That kernel seems to work flawlessly on my machine, everything seems to be running However, it took me all of 5 minutes to find a problem when Vmware Workstation needed to compile some of its modules. It wanted gcc 7.1.1. which exists nowhere for opensuse 42.2. I can find one-click installs here https://software.opensuse.org/package/gcc7 but only for tumbleweed and 42.3. What Opensuse are you running Anton? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/07/17 02:41 PM, John Andersen wrote:
On 07/15/2017 07:22 AM, Anton Aylward wrote:
No need for bleeding edge
http://download.opensuse.org/repositories/Kernel:/stable/standard/
Thanks, that was wat I was looking for. That kernel seems to work flawlessly on my machine, everything seems to be running
However, it took me all of 5 minutes to find a problem when Vmware Workstation needed to compile some of its modules. It wanted gcc 7.1.1. which exists nowhere for opensuse 42.2.
I can find one-click installs here https://software.opensuse.org/package/gcc7 but only for tumbleweed and 42.3.
What Opensuse are you running Anton?
# uname -a Linux main.HOME.SystemI.ca 4.12.1-1.gb24ee10-default #1 SMP PREEMPT Wed Jul 12 15:08:48 UTC 2017 (b24ee10) x86_64 x86_64 x86_64 GNU/Linux # cat /etc/os-release NAME="openSUSE Leap" VERSION="42.2" ID=opensuse ID_LIKE="suse" VERSION_ID="42.2" PRETTY_NAME="openSUSE Leap 42.2" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:leap:42.2" -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/07/17 02:41 PM, John Andersen wrote:
However, it took me all of 5 minutes to find a problem when Vmware Workstation needed to compile some of its modules. It wanted gcc 7.1.1. which exists nowhere for opensuse 42.2.
I have # rpm -qa | grep gcc libgcc_s1-6.2.1+r239768-5.5.2.x86_64 gcc48-4.8.5-22.1.x86_64 gcc-4.8-9.61.x86_64 # which gcc /usr/bin/gcc main:~ # ls -l /usr/bin/gcc lrwxrwxrwx 1 root root 7 Jun 20 08:57 /usr/bin/gcc -> gcc-4.8 But I also don't use vmware. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/15/2017 06:41 PM, Anton Aylward wrote:
But I also don't use vmware.
Apparently that kernel is compiled with gcc7, as is the tumbleweed kernel. (Or at least Vmware believes it is). -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/07/17 13:36, John Andersen wrote:
On 07/14/2017 08:31 PM, David C. Rankin wrote:
On 07/14/2017 01:30 AM, Basil Chupin wrote:
Happiness is a correctly working openSUSE with the latest _proper_ nVidia driver -- NOT nouveau -- installed :-).
(And now to mess-up Leap 42.2...) Chuckling....
Glad you got it going BC.
I'm a bit ambivalent on the nvidia/nouveau issue. When compiz was king and proprietary drivers were needed to make it usable -- I completely agree with you. However, if not using the whiz-bang animations, the nouveau driver provides a lot of benefit that the proprietary driver can't or won't related to the default console itself. Like auto-sizing of the default console to optimal resolution. DPMS poweroff, etc.. Backlight control via /sys/class/backlight (although Kudos to Stefan and team for fixing http://bugzilla.opensuse.org/show_bug.cgi?id=1040718 so it works with the proprietary driver as well now :)
Now, of course, I'm no gamer, and I don't watch video, but for the couple of Webinar's I have watched, the nouveau driver did fine. If I did push the GPU more, then I may have more rocks to throw at nouveau, but I can happily report for the 6 months or so I used it with Leap 42.2 - I literally had no complaints. I do have the nvidia driver installed now, and I don't have any complaints there either -- other than the GPU temp does run a bit hotter with it -- but not enough to be any type of an issue, I suspect it's just using more of it than the nouveau driver does.
I'd still like to know where (what repository) one finds a opensuse 4.11 or 4.12 kernel that might work in 42.2 or 42.3. Here you go,John:
download.opensuse.org/repositories/Kernel:/stable/standard/ note the colon after 'Kernel'. After you create this repo in Yast, search for 'kernel' in the packages and then click on Versions and the 4.12.x (the latest) will be shown -- and you know the rest about how to install it. I also suggest that you give this new kernel repo a priority level 95 (not the default of 99) so that any updates to the existing kernel in 42.2 and 42.3 doesn't come along and clobber the new 4.12.x kernel.
There are some amazing swap handling improvements scheduled to arrive in any kernel 4.11 or later, which really are supposed to make major improvements when swap is on an SSD. (to the point of making swap desirable again).
BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/07/17 20:34, Basil Chupin wrote:
On 15/07/17 13:36, John Andersen wrote:
On 07/14/2017 08:31 PM, David C. Rankin wrote:
On 07/14/2017 01:30 AM, Basil Chupin wrote:
Happiness is a correctly working openSUSE with the latest _proper_ nVidia driver -- NOT nouveau -- installed :-).
(And now to mess-up Leap 42.2...) Chuckling....
Glad you got it going BC.
I'm a bit ambivalent on the nvidia/nouveau issue. When compiz was king and proprietary drivers were needed to make it usable -- I completely agree with you. However, if not using the whiz-bang animations, the nouveau driver provides a lot of benefit that the proprietary driver can't or won't related to the default console itself. Like auto-sizing of the default console to optimal resolution. DPMS poweroff, etc.. Backlight control via /sys/class/backlight (although Kudos to Stefan and team for fixing http://bugzilla.opensuse.org/show_bug.cgi?id=1040718 so it works with the proprietary driver as well now :)
Now, of course, I'm no gamer, and I don't watch video, but for the couple of Webinar's I have watched, the nouveau driver did fine. If I did push the GPU more, then I may have more rocks to throw at nouveau, but I can happily report for the 6 months or so I used it with Leap 42.2 - I literally had no complaints. I do have the nvidia driver installed now, and I don't have any complaints there either -- other than the GPU temp does run a bit hotter with it -- but not enough to be any type of an issue, I suspect it's just using more of it than the nouveau driver does.
I'd still like to know where (what repository) one finds a opensuse 4.11 or 4.12 kernel that might work in 42.2 or 42.3. Here you go,John:
download.opensuse.org/repositories/Kernel:/stable/standard/
note the colon after 'Kernel'.
After you create this repo in Yast, search for 'kernel' in the packages and then click on Versions and the 4.12.x (the latest) will be shown -- and you know the rest about how to install it. I also suggest that you give this new kernel repo a priority level 95 (not the default of 99) so that any updates to the existing kernel in 42.2 and 42.3 doesn't come along and clobber the new 4.12.x kernel.
Hi John, I'll add a bit more to what I stated above re doing something so as not to clobber the 4.11 or 4.12 kernel from /repo/Kernel:/stable.... If you are using zypper to update your oS or even use Yast itself, both or either will try and re-install the original installed kernel ie, 4.4.x because in all probability it is marked as being installed in Yast's Version information. You will see what I mean if you: * start Yast * search for 'kernel' and you will see a number of entries with 'kernel' in them * highlight each one (by clicking on each one) and then select VERSION * you may see that kernel 4.4.x is still ticked as being installed even though 4.11/4.12 is also shown as installed and this last item is what will make zypper or Yast try an re-install 4.4.x kernel. To stop this re-installation of the 4.4.x kernel one has to do some heart-in-the-mouth fiddling which involves DELETING in the Version panel the 4.4.x kernel; Yast may then come up with dependency errors which you have to resolve before Yast will delete 4.4.x. You may have to go thru this process more than once. But you are not a newbie so I am sure that you will sort this out :-). And for all 'newbies' to this mail list, installing the kernel from the ../Kernel:/stable/... repo and doing the above manual fiddles: DO NOT DO ANY OF THE ABOVE -- stick with the kernel as installed, and progressively updated, when you first installed Leap of whatever flavour. You are stepping into a pit full of dragons if you try and do the above! Wait until you have gained more experience. BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-18 05:26, Basil Chupin wrote:
Hi John,
I'll add a bit more to what I stated above re doing something so as not to clobber the 4.11 or 4.12 kernel from /repo/Kernel:/stable....
If you are using zypper to update your oS or even use Yast itself, both or either will try and re-install the original installed kernel ie, 4.4.x because in all probability it is marked as being installed in Yast's Version information. You will see what I mean if you:
* start Yast * search for 'kernel' and you will see a number of entries with 'kernel' in them * highlight each one (by clicking on each one) and then select VERSION * you may see that kernel 4.4.x is still ticked as being installed even though 4.11/4.12 is also shown as installed
and this last item is what will make zypper or Yast try an re-install 4.4.x kernel.
Nevertheless, grub will boot the most recent kernel by default, no matter if the original is still installed. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 18/07/17 20:59, Carlos E. R. wrote:
On 2017-07-18 05:26, Basil Chupin wrote:
Hi John,
I'll add a bit more to what I stated above re doing something so as not to clobber the 4.11 or 4.12 kernel from /repo/Kernel:/stable....
If you are using zypper to update your oS or even use Yast itself, both or either will try and re-install the original installed kernel ie, 4.4.x because in all probability it is marked as being installed in Yast's Version information. You will see what I mean if you:
* start Yast * search for 'kernel' and you will see a number of entries with 'kernel' in them * highlight each one (by clicking on each one) and then select VERSION * you may see that kernel 4.4.x is still ticked as being installed even though 4.11/4.12 is also shown as installed
and this last item is what will make zypper or Yast try an re-install 4.4.x kernel. Nevertheless, grub will boot the most recent kernel by default, no matter if the original is still installed.
Umm, not necessarily... But you may absolutely correct in what you say. Let me explain... I experienced just the opposite to what you wrote above only yesterday (and before I wrote the above 'addendum to the addendum'). Perhaps something did not happen which I expected and therefore what happened did happen :-). After installing the new 4.12.x kernel, I looked in /boot and found that the '@vmlinuz' and @initrd' both pointed to the old (4.4.x) kernel. Now this may have resulted from some part of the kernel family of files not being installed during the many attempts I had to go thru while trying to stop Yast from re-installing 4.4.x :-). I guess the point here is to check in /boot as to which kernel is actually configured for use at boot time before hitting the 'reboot' "button" :-). BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-19 08:38, Basil Chupin wrote:
On 18/07/17 20:59, Carlos E. R. wrote:
On 2017-07-18 05:26, Basil Chupin wrote:
Hi John,
I'll add a bit more to what I stated above re doing something so as not to clobber the 4.11 or 4.12 kernel from /repo/Kernel:/stable....
If you are using zypper to update your oS or even use Yast itself, both or either will try and re-install the original installed kernel ie, 4.4.x because in all probability it is marked as being installed in Yast's Version information. You will see what I mean if you:
* start Yast * search for 'kernel' and you will see a number of entries with 'kernel' in them * highlight each one (by clicking on each one) and then select VERSION * you may see that kernel 4.4.x is still ticked as being installed even though 4.11/4.12 is also shown as installed
and this last item is what will make zypper or Yast try an re-install 4.4.x kernel. Nevertheless, grub will boot the most recent kernel by default, no matter if the original is still installed.
Umm, not necessarily... But you may absolutely correct in what you say. Let me explain...
I experienced just the opposite to what you wrote above only yesterday (and before I wrote the above 'addendum to the addendum'). Perhaps something did not happen which I expected and therefore what happened did happen :-).
After installing the new 4.12.x kernel, I looked in /boot and found that the '@vmlinuz' and @initrd' both pointed to the old (4.4.x) kernel. Now this may have resulted from some part of the kernel family of files not being installed during the many attempts I had to go thru while trying to stop Yast from re-installing 4.4.x :-).
I do not know what maintains those links, and what criteria. Specially when you install an extra kernel.
I guess the point here is to check in /boot as to which kernel is actually configured for use at boot time before hitting the 'reboot' "button" :-).
Grub 2 uses the kernel with the bigger number. Currently openSUSE grub2's doesn't use those symlinks, I believe. You can go "read" /boot/grub2/grub.cfg. Search for "### BEGIN /etc/grub.d/10_linux ###", and the next entry is the main one. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 19/07/17 21:39, Carlos E. R. wrote:
On 2017-07-19 08:38, Basil Chupin wrote:
On 18/07/17 20:59, Carlos E. R. wrote:
On 2017-07-18 05:26, Basil Chupin wrote:
Hi John,
I'll add a bit more to what I stated above re doing something so as not to clobber the 4.11 or 4.12 kernel from /repo/Kernel:/stable....
If you are using zypper to update your oS or even use Yast itself, both or either will try and re-install the original installed kernel ie, 4.4.x because in all probability it is marked as being installed in Yast's Version information. You will see what I mean if you:
* start Yast * search for 'kernel' and you will see a number of entries with 'kernel' in them * highlight each one (by clicking on each one) and then select VERSION * you may see that kernel 4.4.x is still ticked as being installed even though 4.11/4.12 is also shown as installed
and this last item is what will make zypper or Yast try an re-install 4.4.x kernel. Nevertheless, grub will boot the most recent kernel by default, no matter if the original is still installed. Umm, not necessarily... But you may absolutely correct in what you say. Let me explain...
I experienced just the opposite to what you wrote above only yesterday (and before I wrote the above 'addendum to the addendum'). Perhaps something did not happen which I expected and therefore what happened did happen :-).
After installing the new 4.12.x kernel, I looked in /boot and found that the '@vmlinuz' and @initrd' both pointed to the old (4.4.x) kernel. Now this may have resulted from some part of the kernel family of files not being installed during the many attempts I had to go thru while trying to stop Yast from re-installing 4.4.x :-). I do not know what maintains those links, and what criteria. Specially when you install an extra kernel.
I guess the point here is to check in /boot as to which kernel is actually configured for use at boot time before hitting the 'reboot' "button" :-). Grub 2 uses the kernel with the bigger number. Currently openSUSE grub2's doesn't use those symlinks, I believe.
You can go "read" /boot/grub2/grub.cfg. Search for "### BEGIN /etc/grub.d/10_linux ###", and the next entry is the main one.
OK, let's make something clear at this point in time. My comment about the kernel goes back some 12 days ago and by now I suspect that most, if not all, people have forgotten what I said which was that//I have Leap 42.3 BETA installed (but it is due for official release next Tuesday OZ time/day) and that I also installed the latest kernel 4.12.x from the .../stable/standard/ repo and am, therefore, not using the normal kernel which comes with Leap 42.3. Well, my comments relate _only_ to this combo: Leap 42.3 and kernel 4.12.x. Let's carry on.... Earlier today I booted into Leap 42.3 and then did the "zypper three-step dance" routine -- the very first thing I do when I first switch on the computer. To my surprise 'zypper patch' came up with wanting to install kernel 4.4.76 when the damn thing is not showing in Yast as I had labouriously deleted the damn thing! I also looked in /boot and found that both '@initrd' and '@vmlinuz' were _still_ symlinked to kernel 4.4.76 -- but grub.cfg showed that initrd had kernel 4.12.2 to use. To cut a long story short: the person-in-the-woodpile was a file which appeared in Leap 42.3 (but is not in Leap 42.2) and is the cause of this hassle of zypper/Yast wanting to re-install kernel 4.4.76. The file is drm-kmp-default. When you try and install kernel 4.12.x using Yast and deleting kernel 4.4.x, you will get a dependency error(s) and one of them will contain a reference to drm-kmp-default. Select to DELETE this file and this will stop 4.4.x from being re-installed. As I said, this applies only Leap 42.3 and does NOT apply to Leap 42.2. BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-20 04:15, Basil Chupin wrote:
On 19/07/17 21:39, Carlos E. R. wrote:
...
Earlier today I booted into Leap 42.3 and then did the "zypper three-step dance" routine -- the very first thing I do when I first switch on the computer. To my surprise 'zypper patch' came up with wanting to install kernel 4.4.76 when the damn thing is not showing in Yast as I had labouriously deleted the damn thing! I also looked in /boot and found that both '@initrd' and '@vmlinuz' were _still_ symlinked to kernel 4.4.76 -- but grub.cfg showed that initrd had kernel 4.12.2 to use.
Dependency by another package.
To cut a long story short: the person-in-the-woodpile was a file which appeared in Leap 42.3 (but is not in Leap 42.2) and is the cause of this hassle of zypper/Yast wanting to re-install kernel 4.4.76. The file is drm-kmp-default.
Ahhhh!
When you try and install kernel 4.12.x using Yast and deleting kernel 4.4.x, you will get a dependency error(s) and one of them will contain a reference to drm-kmp-default. Select to DELETE this file and this will stop 4.4.x from being re-installed.
As I said, this applies only Leap 42.3 and does NOT apply to Leap 42.2.
Well, that rpm is quite important. I'm not sure of the consequences. There was some talk about it and nvidia, but at this time of the night (5 AM) I don't remember what and I'm not going to look it up ;-) And then, I could be totally mistaken. Somebody knows? Me, goes to bed. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 20/07/17 13:02, Carlos E. R. wrote:
On 2017-07-20 04:15, Basil Chupin wrote:
On 19/07/17 21:39, Carlos E. R. wrote: ...
Earlier today I booted into Leap 42.3 and then did the "zypper three-step dance" routine -- the very first thing I do when I first switch on the computer. To my surprise 'zypper patch' came up with wanting to install kernel 4.4.76 when the damn thing is not showing in Yast as I had labouriously deleted the damn thing! I also looked in /boot and found that both '@initrd' and '@vmlinuz' were _still_ symlinked to kernel 4.4.76 -- but grub.cfg showed that initrd had kernel 4.12.2 to use. Dependency by another package.
To cut a long story short: the person-in-the-woodpile was a file which appeared in Leap 42.3 (but is not in Leap 42.2) and is the cause of this hassle of zypper/Yast wanting to re-install kernel 4.4.76. The file is drm-kmp-default. Ahhhh!
When you try and install kernel 4.12.x using Yast and deleting kernel 4.4.x, you will get a dependency error(s) and one of them will contain a reference to drm-kmp-default. Select to DELETE this file and this will stop 4.4.x from being re-installed.
As I said, this applies only Leap 42.3 and does NOT apply to Leap 42.2. Well, that rpm is quite important. I'm not sure of the consequences. There was some talk about it and nvidia, but at this time of the night (5 AM) I don't remember what and I'm not going to look it up ;-)
And then, I could be totally mistaken.
Somebody knows?
Me, goes to bed.
Well, with Leap 42.3 being released in 5 days time and with me getting a bunch of updates to 42.3 earlier today and you claiming that this drm-kmp-default file as being important for nvidia devices then someone needs to "put the pedal to the metal" to get drk-kmp-default adjusted before the files for Leap 42.3 go into the "production stage" :-) . Having said that, I find no difference in the behaviour of my Leap 42.3 with that file removed. (But, pounds to peanuts, the thing will bite me on the bum the next time I restart the computer! :-D.) BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-07-20 08:22, Basil Chupin wrote:
On 20/07/17 13:02, Carlos E. R. wrote:
On 2017-07-20 04:15, Basil Chupin wrote:
On 19/07/17 21:39, Carlos E. R. wrote: ...
Earlier today I booted into Leap 42.3 and then did the "zypper three-step dance" routine -- the very first thing I do when I first switch on the computer. To my surprise 'zypper patch' came up with wanting to install kernel 4.4.76 when the damn thing is not showing in Yast as I had labouriously deleted the damn thing! I also looked in /boot and found that both '@initrd' and '@vmlinuz' were _still_ symlinked to kernel 4.4.76 -- but grub.cfg showed that initrd had kernel 4.12.2 to use. Dependency by another package.
To cut a long story short: the person-in-the-woodpile was a file which appeared in Leap 42.3 (but is not in Leap 42.2) and is the cause of this hassle of zypper/Yast wanting to re-install kernel 4.4.76. The file is drm-kmp-default. Ahhhh!
When you try and install kernel 4.12.x using Yast and deleting kernel 4.4.x, you will get a dependency error(s) and one of them will contain a reference to drm-kmp-default. Select to DELETE this file and this will stop 4.4.x from being re-installed.
As I said, this applies only Leap 42.3 and does NOT apply to Leap 42.2. Well, that rpm is quite important. I'm not sure of the consequences. There was some talk about it and nvidia, but at this time of the night (5 AM) I don't remember what and I'm not going to look it up ;-)
And then, I could be totally mistaken.
Somebody knows?
Me, goes to bed.
Well, with Leap 42.3 being released in 5 days time and with me getting a bunch of updates to 42.3 earlier today and you claiming that this drm-kmp-default file as being important for nvidia devices then someone needs to "put the pedal to the metal" to get drk-kmp-default adjusted before the files for Leap 42.3 go into the "production stage" :-) .
But most people are staying with kernel 4.4, the rpm is designed for it. You are testing a different kernel, so you found a problem. I think you should mention this in a bugzilla. Or ask in the factory mail list.
Having said that, I find no difference in the behaviour of my Leap 42.3 with that file removed. (But, pounds to peanuts, the thing will bite me on the bum the next time I restart the computer! :-D.)
It seems that some people installing the NVidia driver may need to remove this package, but on the other hand, people using Intel may need it. So a problem for hybrids is looming. Have a look at: Subject: [opensuse-factory] Leap 42.3 and drm-kmp-default packages Subject: [opensuse-factory] [Resolved] Leap 42.3 kernel 4.4.71x and problem installing the Nvidia driver Subject: Big conflict oops (was: [opensuse-factory] Leap 42.3 Build 0289 released!) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 07/19/2017 11:22 PM, Basil Chupin wrote:
Having said that, I find no difference in the behaviour of my Leap 42.3 with that file removed. (But, pounds to peanuts, the thing will bite me on the bum the next time I restart the computer! :-D.)
Will this (having a 4.4 kernel installed) really hurt you? I've heard it said (Carlos I think) that the system always boots the most recent kernel, so your 4.12 should still rule the roost, with 4.4 serving as an emergency backup. Cheap insurance IMHO. ----side note: Note: I've given up on 4.12 for the moment. It demanded a switch to gcc7, for compiling kernel modules for VMware, which is essential for my workflow on this particular machine. I was never able to get that to work properly and the press of business demanded I back down to something that did work with VMware. The only reason I wanted 4.12 on on this old beast was for the newer swap handling that might maximize performance when swap is on SSD, which became available in kernels 4.11 and later. https://lwn.net/Articles/704478/ -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* David C. Rankin <drankinatty@suddenlinkmail.com> [07-14-17 23:33]:
On 07/14/2017 01:30 AM, Basil Chupin wrote:
Happiness is a correctly working openSUSE with the latest _proper_ nVidia driver -- NOT nouveau -- installed :-).
(And now to mess-up Leap 42.2...)
Chuckling....
Glad you got it going BC.
I'm a bit ambivalent on the nvidia/nouveau issue. When compiz was king and proprietary drivers were needed to make it usable -- I completely agree with you. However, if not using the whiz-bang animations, the nouveau driver provides a lot of benefit that the proprietary driver can't or won't related to the default console itself. Like auto-sizing of the default console to optimal resolution. DPMS poweroff, etc.. Backlight control via /sys/class/backlight (although Kudos to Stefan and team for fixing http://bugzilla.opensuse.org/show_bug.cgi?id=1040718 so it works with the proprietary driver as well now :)
Now, of course, I'm no gamer, and I don't watch video, but for the couple of Webinar's I have watched, the nouveau driver did fine. If I did push the GPU more, then I may have more rocks to throw at nouveau, but I can happily report for the 6 months or so I used it with Leap 42.2 - I literally had no complaints. I do have the nvidia driver installed now, and I don't have any complaints there either -- other than the GPU temp does run a bit hotter with it -- but not enough to be any type of an issue, I suspect it's just using more of it than the nouveau driver does.
if you work photographs or any kind of video, the nv prop driver is a necessity. while nouveau is impressive, it just cannot stack up, yet ... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/07/17 13:31, David C. Rankin wrote:
On 07/14/2017 01:30 AM, Basil Chupin wrote:
Happiness is a correctly working openSUSE with the latest _proper_ nVidia driver -- NOT nouveau -- installed :-).
(And now to mess-up Leap 42.2...) Chuckling....
Glad you got it going BC.
I'm a bit ambivalent on the nvidia/nouveau issue. When compiz was king and proprietary drivers were needed to make it usable -- I completely agree with you. However, if not using the whiz-bang animations, the nouveau driver provides a lot of benefit that the proprietary driver can't or won't related to the default console itself. Like auto-sizing of the default console to optimal resolution. DPMS poweroff, etc.. Backlight control via /sys/class/backlight (although Kudos to Stefan and team for fixing http://bugzilla.opensuse.org/show_bug.cgi?id=1040718 so it works with the proprietary driver as well now :)
Now, of course, I'm no gamer, and I don't watch video, but for the couple of Webinar's I have watched, the nouveau driver did fine. If I did push the GPU more, then I may have more rocks to throw at nouveau, but I can happily report for the 6 months or so I used it with Leap 42.2 - I literally had no complaints. I do have the nvidia driver installed now, and I don't have any complaints there either -- other than the GPU temp does run a bit hotter with it -- but not enough to be any type of an issue, I suspect it's just using more of it than the nouveau driver does.
Well, I use my monitor to watch TV HD channels, watching Blu-ray videos, and also doing some photo work using Gimp. For me the nouveau driver just doesn't cut it, I'm afraid. Besides, why eat chuck steak when one can have fillet? :-). BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, 14 July 2017 03:01:54 BST Patrick Shanahan wrote:
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 20:57]:
On 13/07/17 22:21, Carlos E. R. wrote:
On 2017-07-13 12:06, Basil Chupin wrote:
On 09/07/17 12:25, Rodney Baker wrote:
Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU.
On another post Rodney said this:
That’s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :-) <snip> for the latest drivers to work with my GT450, I must add: sh ./NVIDIA-Linux-x86_64-384.47.run -aqs --install-libglvnd
What are -aqs options? Regards -- Sudhir Anand
On Friday, 14 July 2017 14:03:35 BST Sudhir Anand wrote:
On Friday, 14 July 2017 03:01:54 BST Patrick Shanahan wrote:
* Basil Chupin <blchupin@iinet.net.au> [07-13-17 20:57]:
On 13/07/17 22:21, Carlos E. R. wrote:
On 2017-07-13 12:06, Basil Chupin wrote:
On 09/07/17 12:25, Rodney Baker wrote:
Thank you, Rodney, for this info. But I have a question re the above and what I normally see when I go to NVidia to download the latest driver for my GPU.
On another post Rodney said this:
That’s why I provided the link to the nvidia support forum - latest driver releases are announced there, while the driver search page seems to lag 1-2 generations behind. :-)
<snip>
for the latest drivers to work with my GT450, I must add:
sh ./NVIDIA-Linux-x86_64-384.47.run -aqs --install-libglvnd
What are -aqs options?
Regards
-- Sudhir Anand ��칻 �&�zf���^�ˬ{맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���w������ ��
Just answered my own question. The options are listed using -A option. Regards. -- Sudhir Anand N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�: �{Zr�az�'z��j)h���Ǿ� ޮ�^�ˬz��
On 09/07/17 12:25, Rodney Baker wrote:
[...] I have a copy of Leap 42.3 installed and kept up-to-date on almost a daily basis.
This morning 42.3 received another update which also upgraded the kernel-default to 4.4.73 and now I am unable compile the nVidia driver (375.66) which I normally do after a kernel upgrade.
When trying to compile the nVidia driver I get this the error msg:
/quote
Kernel module compilation complete. -> Unable to determine if Secure Boot is enabled: No such file or directory ERROR: Unable to load the kernel module 'nvidia-drm.ko'. This happens most frequently when this kernel module was built against the wrong or improperly configured kernel sources, with a version of gcc that differs from the one used to build the target kernel, or if a driver such as rivafb, nvidiafb, or nouveau is present and prevents the NVIDIA kernel module from obtaining ownership of the NVIDIA graphics device(s), or no NVIDIA GPU installed in this system is supported by this NVIDIA Linux graphics driver release.
/unquote
This is not the first time this has happened over the past weeks and some update to 42.3 days later often solves this problem.
BC Suggest you update your nvidia driver to 381.22, or try the new beta 384.47 (or patch your 375.66 driver). Latest versions and patches can be found via
On Saturday, 8 July 2017 11:24:19 ACST Basil Chupin wrote: the nvidia Linux forum - start here:
https://devtalk.nvidia.com/default/topic/533434/linux/current-graphics-drive...
BTW, it is also worth installing and setting up dkms - except when new kernel versions break the nvidia drivers, it makes kernel upgrades much easier by automatically building the nvidia modules for the new kernel (or, for an older kernel if you boot to one that has not had the driver module previously built).
Regards,
Well, a short time ago I updated my Leap 42.3 with the latest and greatest and .... DKMS or not the 375.66 driver bombs out and won't compile for the GTX 660 GPU :-). Will now try the 381.22 driver... BC -- You are NOT entitled to your opinion. You are entitled to your INFORMED opinion. Nobody is entitled to be ignorant. Harlan Ellison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (16)
-
Anton Aylward -
Basil Chupin -
Bjoern Voigt -
Carl Hartung -
Carlos E. R. -
Carlos E. R. -
David C. Rankin -
John Andersen -
Knurpht - Gertjan Lettink -
Markus Koßmann -
Patrick Shanahan -
Peter Suetterlin -
pit
-
Rodney Baker -
Ruediger Meier -
Sudhir Anand