[opensuse] RIP 42.3 - damn good release.
All, Another end-of-life has come to pass. 42.3 joins 13.1, 11.4, 11.0 (minus the KDE 4.0.4a mess), 10.3, 10.0, 9.2 Pro, 9.0 Pro, 8.2 Pro, 8.0 Pro, 7.2 Pro, and 7.0 Pro in a long line of good releases. (others will remember earlier, but the (Air) release was my first, Mandy before then and DSL) So now what to do?? 15.0 end-of-life is scheduled for November, 15.1 is scheduled for November 2020, but I would miss trying a zypper dup. So many choices... So is a change of repo versions to 15.0 and a: zypper dup --download-in-advance a good path for now? -- 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/02/2019 11:43 PM, David C. Rankin wrote:
All,
Another end-of-life has come to pass. 42.3 joins 13.1, 11.4, 11.0 (minus the KDE 4.0.4a mess), 10.3, 10.0, 9.2 Pro, 9.0 Pro, 8.2 Pro, 8.0 Pro, 7.2 Pro, and 7.0 Pro in a long line of good releases. (others will remember earlier, but the (Air) release was my first, Mandy before then and DSL)
So now what to do?? 15.0 end-of-life is scheduled for November, 15.1 is scheduled for November 2020, but I would miss trying a zypper dup. So many choices...
So is a change of repo versions to 15.0 and a:
zypper dup --download-in-advance
a good path for now?
Oh, and what about Nvidia? I recall a few issues with zypper dup and Nvidia. Are those fixed? -- 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
David C. Rankin composed on 2019-07-02 23:45 (UTC-0500):
Oh, and what about Nvidia? I recall a few issues with zypper dup and Nvidia. Are those fixed?
The first update kernel lp151.28.4.1 for 15.1 users of NVidia hardware with either FOSS DDX was foobar. It was 18 days before lp151.28.7.1 fixed it. Takashi went on vacation right before problem was reported. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 03.07.19 um 07:24 schrieb Felix Miata:
David C. Rankin composed on 2019-07-02 23:45 (UTC-0500):
Oh, and what about Nvidia? I recall a few issues with zypper dup and Nvidia. Are those fixed?
The first update kernel lp151.28.4.1 for 15.1 users of NVidia hardware with either FOSS DDX was foobar. It was 18 days before lp151.28.7.1 fixed it. Takashi went on vacation right before problem was reported.
I read this and updated to 15.1. Got kernel-default-4.12.14-lp151.28.7.1.x86_64. Installed the G05 drivers (430.26-lp151.14.1) for my 1050Ti. Rebooted. Black screen. Which combination of kernel and nVidia driver is expected to work, preferrably with plasma desktop? And if I get a black screen again, and - as usual - no errors in /var/log/Xorg.0.log, where else can I look? Regards, Werner -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op zondag 7 juli 2019 02:46:13 CEST schreef Werner Flamme:
Am 03.07.19 um 07:24 schrieb Felix Miata:
David C. Rankin composed on 2019-07-02 23:45 (UTC-0500):
Oh, and what about Nvidia? I recall a few issues with zypper dup and Nvidia. Are those fixed?
The first update kernel lp151.28.4.1 for 15.1 users of NVidia hardware with either FOSS DDX was foobar. It was 18 days before lp151.28.7.1 fixed it. Takashi went on vacation right before problem was reported.
I read this and updated to 15.1. Got kernel-default-4.12.14-lp151.28.7.1.x86_64. Installed the G05 drivers (430.26-lp151.14.1) for my 1050Ti. Rebooted. Black screen.
Which combination of kernel and nVidia driver is expected to work, preferrably with plasma desktop?
And if I get a black screen again, and - as usual - no errors in /var/log/Xorg.0.log, where else can I look?
Regards, Werner -- Some have reported they need the G04 driver instead of the G05......
-- 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/06/2019 07:54 PM, Knurpht-openSUSE wrote:
I read this and updated to 15.1. Got kernel-default-4.12.14-lp151.28.7.1.x86_64. Installed the G05 drivers (430.26-lp151.14.1) for my 1050Ti. Rebooted. Black screen.
Which combination of kernel and nVidia driver is expected to work, preferrably with plasma desktop?
And if I get a black screen again, and - as usual - no errors in /var/log/Xorg.0.log, where else can I look?
Regards, Werner -- Some have reported they need the G04 driver instead of the G05......
My card uses the G04 drivers and that is what is installed with 42.3. Is there any reason I shouldn't expect the G04 drivers to be the ones pulled in with the zypper dup? -- 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
Werner Flamme composed on 2019-07-07 02:46 (UTC+0200):
The first update kernel lp151.28.4.1 for 15.1 users of NVidia hardware with either FOSS DDX was foobar. It was 18 days before lp151.28.7.1 fixed it. Takashi went on vacation right before problem was reported.
I read this and updated to 15.1. Got kernel-default-4.12.14-lp151.28.7.1.x86_64. Installed the G05 drivers (430.26-lp151.14.1) for my 1050Ti. Rebooted. Black screen.
Did you try using 15.1 with either of the FOSS DDX first? One should ensure an installation or upgrade was successful before tainting it with software that didn't go through openSUSE QA.
Which combination of kernel and nVidia driver is expected to work, preferrably with plasma desktop?
I only use FOSS DDX, so cannot make any such suggestions.
And if I get a black screen again, and - as usual - no errors in /var/log/Xorg.0.log, where else can I look?
Start with dmesg. Your problem may or may not have anthing to do with the kernel. Take a read of: <https://en.opensuse.org/SDB:Nomodeset:_Work_Around_Graphic_Upgrade_&_Installation_Obstacles> Near the bottom are three things to try. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 07.07.19 um 03:04 schrieb Felix Miata:
Werner Flamme composed on 2019-07-07 02:46 (UTC+0200):
The first update kernel lp151.28.4.1 for 15.1 users of NVidia hardware with either FOSS DDX was foobar. It was 18 days before lp151.28.7.1 fixed it. Takashi went on vacation right before problem was reported.
I read this and updated to 15.1. Got kernel-default-4.12.14-lp151.28.7.1.x86_64. Installed the G05 drivers (430.26-lp151.14.1) for my 1050Ti. Rebooted. Black screen.
Did you try using 15.1 with either of the FOSS DDX first? One should ensure an installation or upgrade was successful before tainting it with software that didn't go through openSUSE QA.
Yes, I did. The screen was painstakingly slow. 3840x2160 is not what one wants to do with a noveau driver.
Which combination of kernel and nVidia driver is expected to work, preferrably with plasma desktop?
I only use FOSS DDX, so cannot make any such suggestions.
The FOSS driver gives me a non-black screen, but is very slow in painting it.
And if I get a black screen again, and - as usual - no errors in /var/log/Xorg.0.log, where else can I look?
Start with dmesg. Your problem may or may not have anthing to do with the kernel.
Take a read of: <https://en.opensuse.org/SDB:Nomodeset:_Work_Around_Graphic_Upgrade_&_Installation_Obstacles> Near the bottom are three things to try.
Thanks for the pointer, Felix. I'll try soon :) In the meantime, I have a system like I never had. After getting the black screen, I "rpm -e"d all nvidia packages. Rebooted (as always to multi-user target), did the "startx" and had a graphic, non-black, working screen. With very small fonts and extremely tiny decoration, which wasn't the case before. And tadaa: # lsmod | egrep '(nvi|nou)' | sort button 16384 1 nouveau drm 491520 6 nouveau,ttm,nvidia_drm,drm_kms_helper drm_kms_helper 208896 2 nouveau,nvidia_drm i2c_algo_bit 16384 1 nouveau ipmi_msghandler 65536 2 nvidia,ipmi_devintf mxm_wmi 16384 1 nouveau nouveau 2170880 0 nvidia 18829312 2 nvidia_modeset,nvidia_uvm nvidia_drm 49152 1 nvidia_modeset 1114112 1 nvidia_drm nvidia_uvm 921600 0 ttm 126976 1 nouveau video 45056 2 asus_wmi,nouveau wmi 28672 4 asus_wmi,wmi_bmof,mxm_wmi,nouveau Both drivers have been loaded. I am baffled. # modinfo nvidia filename: /lib/modules/4.12.14-lp151.28.7-default/updates/nvidia.ko alias: char-major-195-* version: 430.26 supported: external license: NVIDIA suserelease: openSUSE Leap 15.1 srcversion: 89BDA0F56877588EC9454C6 [...] # rpm -qf /lib/modules/4.12.14-lp151.28.7-default/updates/nvidia.ko file /lib/modules/4.12.14-lp151.28.7-default/updates/nvidia.ko is not owned by any package Sigh. Neither /lib/modules/4.12.14-lp151.28.7-default/updates/ nor the files inside are symlinks. And neither belongs to a package. Well, at least 430.26 is the versin that nVidia's driver search engine tells me to use for my card. I basically followed the proceedings on <https://en.opensuse.org/SDB:NVIDIA_drivers>, just that I chose the G05 driver without research first. The card is new enough :^). Regards, Werner -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/07/2019 19.44, Werner Flamme wrote:
Am 07.07.19 um 03:04 schrieb Felix Miata:
...
I basically followed the proceedings on <https://en.opensuse.org/SDB:NVIDIA_drivers>, just that I chose the G05 driver without research first. The card is new enough :^).
When you activate the NVidia repository, it automatically selects the correct driver on most cases. I don't know how this is done. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Werner Flamme composed on 2019-07-07 19:44 (UTC+0200):
Felix Miata composed:
I only use FOSS DDX, so cannot make any such suggestions.
The FOSS driver gives me a non-black screen, but is very slow in painting it.
There are these FOSS drivers available for NVidia graphics: FBDEV VESA Nouveau DDX Modesetting DDX The first two are generic, primarily for emergency and/or troubleshooting use. They are both very very slow. Normally one of the first two is used for X when the nouveau kernel driver is blacklisted. The Nouveau DDX and/or kernel's nouveau are typically blacklisted when a non-FOSS NVidia driver is installed. This prevents use of the two competent FOSS DDX. I believe this accounts for your "very slow in painting". I would like to have seen your Xorg.0.log and/or 'inxi -Gxx' output from before installing the NVidia drivers to be sure. The blacklisting probably survived the upgrade from 15.0 to 15.1, without a corresponding NVidia driver matching the 15.1 kernel. The modesetting is the upstream default, but a default openSUSE installation installs the upstream optional xf86-video-nouveau DDX package, preventing its use until such time as the optional DDX is uninstalled, or the modesetting DDX is specified through /etc/X11/xorg.con*. I use only the modesetting with all non-ancient NVidia graphics that it supports. Its every bit as fast as my eyes can follow on 2560x1440. I had a 3840x2160, but returned it for several reasons, among which eyestrain trying to configure it to eliminate the eyestrain. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata schrieb am 07.07.19 um 20:18:
Werner Flamme composed on 2019-07-07 19:44 (UTC+0200):
Felix Miata composed:
I only use FOSS DDX, so cannot make any such suggestions.
The FOSS driver gives me a non-black screen, but is very slow in painting it.
There are these FOSS drivers available for NVidia graphics:
FBDEV VESA Nouveau DDX Modesetting DDX
I think I find the nouveau driver. On my host, I have the packages libdrm_nouveau2-2.4.97-lp151.1.1.x86_64 libdrm_nouveau2-32bit-2.4.97-lp151.1.1.x86_64 libvdpau_nouveau-18.3.2-lp151.22.4.x86_64 Mesa-dri-nouveau-18.3.2-lp151.22.4.x86_64 Mesa-dri-nouveau-32bit-18.3.2-lp151.22.4.x86_64 xf86-video-nouveau-1.0.15-lp151.4.1.x86_64 Modesetting seems to be included somewhere. Ah, yes. rpm -qf /usr/share/man/man4/modesetting.4.gz xorg-x11-server-1.20.3-lp151.3.1.x86_64
The first two are generic, primarily for emergency and/or troubleshooting use. They are both very very slow. Normally one of the first two is used for X when the nouveau kernel driver is blacklisted. The Nouveau DDX and/or kernel's nouveau are typically blacklisted when a non-FOSS NVidia driver is installed. This prevents use of the two competent FOSS DDX. I believe this accounts for your "very slow in painting". I would like to have seen your Xorg.0.log and/or 'inxi -Gxx' output from before installing the NVidia drivers to be sure.
Only from now: inxi -Gxx Graphics: Device-1: NVIDIA GP107 [GeForce GTX 1050 Ti] driver: nvidia v: 430.26 bus ID: 01:00.0 chip ID: 10de:1c82 Display: server: X.Org 1.20.3 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa alternate: nv compositor: kwin_x11 resolution: 1920x1200~60Hz, 1920x1200~60Hz OpenGL: renderer: llvmpipe (LLVM 7.0 256 bits) v: 3.3 Mesa 18.3.2 compat-v: 3.1 direct render: Yes "hwinfo --gfxcard" says (among others) Driver Info #0: Driver Status: nouveau is active Driver Activation Cmd: "modprobe nouveau" Driver Info #1: Driver Status: nvidia_drm is active Driver Activation Cmd: "modprobe nvidia_drm" Driver Info #2: Driver Status: nvidia is active Driver Activation Cmd: "modprobe nvidia" xrandr is confused and tells me I got 2 screens, attached via HDMI-I (1920x1200+0+0) and DP-1 (1920x1200+1920+0). Quite false, there is only one HDMI cable attached, and KDEsettings tell me 3840x2160.
The blacklisting probably survived the upgrade from 15.0 to 15.1, without a corresponding NVidia driver matching the 15.1 kernel.
/etc/modprobe.d> grep -rin noveau * I don't think it has survived...
The modesetting is the upstream default, but a default openSUSE installation installs the upstream optional xf86-video-nouveau DDX package, preventing its use until such time as the optional DDX is uninstalled, or the modesetting DDX is specified through /etc/X11/xorg.con*.
The files matching /etc/X11/xorg.conf.* have been touched last in November 2018 (two have "nvidia-xconfig" in their first line). Files inside /etc/X11/xorg.conf.d: -rw-r--r-- 1 root root 361 20. Okt 2015 00-keyboard.conf -rw-r--r-- 1 root root 361 27. Jan 2015 00-keyboard.conf.backup -rw-r--r-- 1 root root 92 17. Dez 2018 10-amdgpu.conf -rw-r--r-- 1 root root 1099 17. Dez 2018 10-evdev.conf -rw-r--r-- 1 root root 489 17. Mär 14:21 10-libvnc.conf -rw-r--r-- 1 root root 1350 29. Jan 13:50 10-quirks.conf -rw-r--r-- 1 root root 484 17. Dez 2018 11-evdev.conf -rw-r--r-- 1 root root 975 17. Dez 2018 40-libinput.conf -rw-r--r-- 1 root root 529 1. Jul 2011 50-device.conf -rw-r--r-- 1 root root 199 17. Dez 2018 50-elotouch.conf -rw-r--r-- 1 root root 264 29. Jan 13:50 50-extensions.conf -rw-r--r-- 1 root root 527 1. Jul 2011 50-monitor.conf -rw-r--r-- 1 root root 491 1. Jul 2011 50-screen.conf -rw-r--r-- 1 root root 1913 17. Dez 2018 70-synaptics.conf -rw-r--r-- 1 root root 115 13. Dez 2018 70-vmmouse.conf -rw-r--r-- 1 root root 2747 25. Mär 12:58 70-wacom.conf -rw-r--r-- 1 root root 226 19. Jun 15:16 90-xpra-virtual.conf The update took place last weekend, so I guess there has nothing changed. I find neither "modes" nor "sett" inside the files.
I use only the modesetting with all non-ancient NVidia graphics that it supports. Its every bit as fast as my eyes can follow on 2560x1440. I had a 3840x2160, but returned it for several reasons, among which eyestrain trying to configure it to eliminate the eyestrain.
Up to (and including) 42.3, I had no problems using the proprietary nVidia driver. I used to make the display fitting to my eyesight (-4.5 dpt). I still say that you better have a screen > 30" to work with 3840x2160, I have only 27", and my company offered the same size. I'm using 2 x 1920x1200 (24") screens here now... with Intel "HD Graphics 630", Driver i915, BTW. How do you configure "modesetting" as the default driver? Werner -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Werner Flamme composed on 2019-07-08 13:26 (UTC+0200):
Felix Miata composed:
There are these FOSS drivers available for NVidia graphics:
FBDEV VESA Nouveau DDX Modesetting DDX
I think I find the nouveau driver. On my host, I have the packages
libdrm_nouveau2-2.4.97-lp151.1.1.x86_64 libdrm_nouveau2-32bit-2.4.97-lp151.1.1.x86_64 libvdpau_nouveau-18.3.2-lp151.22.4.x86_64 Mesa-dri-nouveau-18.3.2-lp151.22.4.x86_64 Mesa-dri-nouveau-32bit-18.3.2-lp151.22.4.x86_64 xf86-video-nouveau-1.0.15-lp151.4.1.x86_64
xf86-video-nouveau is the DDX. DDX is the competent X driver foundation. Which other bits are used depend on which foundational selection is enabled.
Modesetting seems to be included somewhere. Ah, yes. rpm -qf /usr/share/man/man4/modesetting.4.gz xorg-x11-server-1.20.3-lp151.3.1.x86_64
Modesetting is the default competent FOSS foundation. ...
xrandr is confused and tells me I got 2 screens, attached via HDMI-I (1920x1200+0+0) and DP-1 (1920x1200+1920+0). Quite false, there is only one HDMI cable attached, and KDEsettings tell me 3840x2160. ... I'm using 2 x 1920x1200 (24") screens here now... with Intel "HD Graphics 630", Driver i915, BTW.
I am confused too. Only a HDMI cable, but two 1920x1200 screens??? i915 is a kernel driver. The issues with black screens are usually about DDX drivers when only FOSS is installed. When there are two screens, and one or both are black, it's sometimes a result of server mixup, lighting up only a secondary screen on which a mouse pointer can be made to appear. Last I saw something like this was last month. A local gamer bought a new PC with a new screen. Contrary to the bold text in the quick connection guide, he hooked up both DVI and DisplayPort cables to both the gfxcard and the single display. Windows dutifully made the desktop 3840x1080, but the single display only showed the right half. The mouse pointer could be seen at top, bottom and right edges, but only after moving it to the right, off the primary/left/invisible/missing screen "connected" to the DVI cable.
How do you configure "modesetting" as the default driver?
Halfway down the page on <https://en.opensuse.org/SDB:Nomodeset:_Work_Around_Graphic_Upgrade_&_Installation_Obstacles> read the paragraph beginning "If you experience no improvement, or if". -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata schrieb am 08.07.19 um 19:06:
Werner Flamme composed on 2019-07-08 13:26 (UTC+0200):
Felix Miata composed:
There are these FOSS drivers available for NVidia graphics:
FBDEV VESA Nouveau DDX Modesetting DDX
I think I find the nouveau driver. On my host, I have the packages
libdrm_nouveau2-2.4.97-lp151.1.1.x86_64 libdrm_nouveau2-32bit-2.4.97-lp151.1.1.x86_64 libvdpau_nouveau-18.3.2-lp151.22.4.x86_64 Mesa-dri-nouveau-18.3.2-lp151.22.4.x86_64 Mesa-dri-nouveau-32bit-18.3.2-lp151.22.4.x86_64 xf86-video-nouveau-1.0.15-lp151.4.1.x86_64
xf86-video-nouveau is the DDX. DDX is the competent X driver foundation. Which other bits are used depend on which foundational selection is enabled.
I did not install any of them manually, either they already were present with 15.0 or they werde added with the upgrade to 15.1.
Modesetting seems to be included somewhere. Ah, yes. rpm -qf /usr/share/man/man4/modesetting.4.gz xorg-x11-server-1.20.3-lp151.3.1.x86_64
Modesetting is the default competent FOSS foundation. ...
xrandr is confused and tells me I got 2 screens, attached via HDMI-I (1920x1200+0+0) and DP-1 (1920x1200+1920+0). Quite false, there is only one HDMI cable attached, and KDEsettings tell me 3840x2160. ... I'm using 2 x 1920x1200 (24") screens here now... with Intel "HD Graphics 630", Driver i915, BTW.
I am confused too. Only a HDMI cable, but two 1920x1200 screens??? i915 is a kernel driver. The issues with black screens are usually about DDX drivers when only FOSS is installed.
This is what xrandr tells me at home. Obviously, xrandr is confused. I'm using one screen with a resolution of 3840x2160 at home. Neither xrandr's number of screens nor its resolution matches reality. The output of xrandr at the office and at home are the same, I just see, just some decimals at the given resolutions differ... The Esprimo's xrandr even tells me about DP-1 and -2 and HDMI-1 and -2, when there ist only one DP and one DVI connector.
When there are two screens, and one or both are black, it's sometimes a result of server mixup, lighting up only a secondary screen on which a mouse pointer can be made to appear.
In my case (at the office), the monitor connected via DP remains black on startup ("no signal"). If I switch it off, and on again when initrd shows "switching root...", I get a wonderfult 2 screen display. But that's at the office, with the Esprimo, containing Intel graphics. The late picture on DP if used together in a 2-screen-solution is known in the company to occur also with windows. Seems to be a hardware thing.
Last I saw something like this was last month. A local gamer bought a new PC with a new screen. Contrary to the bold text in the quick connection guide, he hooked up both DVI and DisplayPort cables to both the gfxcard and the single display. Windows dutifully made the desktop 3840x1080, but the single display only showed the right half. The mouse pointer could be seen at top, bottom and right edges, but only after moving it to the right, off the primary/left/invisible/missing screen "connected" to the DVI cable.
You can use xrandr under Linux to switch monitors like you want them. Sometimes it takes a while until you get what you want, but everything is possible :) But: there are no two monitors connected to my nVidia card at home. There only is one. At the office, I have 2 monitors, but an Intel grapchics chip.
How do you configure "modesetting" as the default driver?
Halfway down the page on
<https://en.opensuse.org/SDB:Nomodeset:_Work_Around_Graphic_Upgrade_&_Installation_Obstacles>
read the paragraph beginning "If you experience no improvement, or if".
Gnaa... thanks! Werner -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Werner Flamme composed on 2019-07-07 02:46 (UTC+0200): ....... ....... ....... In the meantime, I have a system like I never had. After getting the black screen, I "rpm -e"d all nvidia packages. Rebooted (as always to multi-user target), did the "startx" and had a graphic, non-black, working screen. With very small fonts and extremely tiny decoration, which wasn't the case before. And tadaa:
# lsmod | egrep '(nvi|nou)' | sort button 16384 1 nouveau drm 491520 6 nouveau,ttm,nvidia_drm,drm_kms_helper drm_kms_helper 208896 2 nouveau,nvidia_drm i2c_algo_bit 16384 1 nouveau ipmi_msghandler 65536 2 nvidia,ipmi_devintf mxm_wmi 16384 1 nouveau nouveau 2170880 0 nvidia 18829312 2 nvidia_modeset,nvidia_uvm nvidia_drm 49152 1 nvidia_modeset 1114112 1 nvidia_drm nvidia_uvm 921600 0 ttm 126976 1 nouveau video 45056 2 asus_wmi,nouveau wmi 28672 4 asus_wmi,wmi_bmof,mxm_wmi,nouveau
Both drivers have been loaded. I am baffled. I haven't looked at this for a long while, so I may be out of date. With
On 7/7/19 1:44 PM, Werner Flamme wrote: that said ... The nvidia drivers from the repo should create the file /etc/modprobe.d/nvidia-default.conf which will have the line "blacklist nouveau". That should prevent the kernel from loading the nouveau driver(s). Have you checked this? --dg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
DennisG schrieb am 07.07.19 um 20:36:
Werner Flamme composed on 2019-07-07 02:46 (UTC+0200): ....... ....... ....... In the meantime, I have a system like I never had. After getting the black screen, I "rpm -e"d all nvidia packages. Rebooted (as always to multi-user target), did the "startx" and had a graphic, non-black, working screen. With very small fonts and extremely tiny decoration, which wasn't the case before. And tadaa:
# lsmod | egrep '(nvi|nou)' | sort button 16384 1 nouveau drm 491520 6 nouveau,ttm,nvidia_drm,drm_kms_helper drm_kms_helper 208896 2 nouveau,nvidia_drm i2c_algo_bit 16384 1 nouveau ipmi_msghandler 65536 2 nvidia,ipmi_devintf mxm_wmi 16384 1 nouveau nouveau 2170880 0 nvidia 18829312 2 nvidia_modeset,nvidia_uvm nvidia_drm 49152 1 nvidia_modeset 1114112 1 nvidia_drm nvidia_uvm 921600 0 ttm 126976 1 nouveau video 45056 2 asus_wmi,nouveau wmi 28672 4 asus_wmi,wmi_bmof,mxm_wmi,nouveau
Both drivers have been loaded. I am baffled. I haven't looked at this for a long while, so I may be out of date. With
On 7/7/19 1:44 PM, Werner Flamme wrote: that said ...
The nvidia drivers from the repo should create the file /etc/modprobe.d/nvidia-default.conf which will have the line "blacklist nouveau". That should prevent the kernel from loading the nouveau driver(s). Have you checked this?
Yes, I checked. The file is not present since I "rpm -e"'d all the nvidia packages; it was before. I assumed that the kernel module files were gone too, but obviously I was wrong. Besides having the effect that drivers are loaded that should not: now the nvidia driver (kernel module) has been loaded, and I have a working desktop. The files that are contained in the G05 packages from the nvidia repo should be the same as there are now. What might cause my desktop staying black wehen the packages are present, but going to work when the module files are still there, but the rest isn't? Maybe the reason for the detailed display is nvidia, and the reason for being slow is nouveau? ;) Werner -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/8/19 6:41 AM, Werner Flamme wrote:
DennisG schrieb am 07.07.19 um 20:36:
Werner Flamme composed on 2019-07-07 02:46 (UTC+0200): ....... ....... ....... In the meantime, I have a system like I never had. After getting the black screen, I "rpm -e"d all nvidia packages. Rebooted (as always to multi-user target), did the "startx" and had a graphic, non-black, working screen. With very small fonts and extremely tiny decoration, which wasn't the case before. And tadaa:
# lsmod | egrep '(nvi|nou)' | sort button 16384 1 nouveau drm 491520 6 nouveau,ttm,nvidia_drm,drm_kms_helper drm_kms_helper 208896 2 nouveau,nvidia_drm i2c_algo_bit 16384 1 nouveau ipmi_msghandler 65536 2 nvidia,ipmi_devintf mxm_wmi 16384 1 nouveau nouveau 2170880 0 nvidia 18829312 2 nvidia_modeset,nvidia_uvm nvidia_drm 49152 1 nvidia_modeset 1114112 1 nvidia_drm nvidia_uvm 921600 0 ttm 126976 1 nouveau video 45056 2 asus_wmi,nouveau wmi 28672 4 asus_wmi,wmi_bmof,mxm_wmi,nouveau
Both drivers have been loaded. I am baffled. I haven't looked at this for a long while, so I may be out of date. With
On 7/7/19 1:44 PM, Werner Flamme wrote: that said ...
The nvidia drivers from the repo should create the file /etc/modprobe.d/nvidia-default.conf which will have the line "blacklist nouveau". That should prevent the kernel from loading the nouveau driver(s). Have you checked this? Yes, I checked. The file is not present since I "rpm -e"'d all the nvidia packages; it was before.
I assumed that the kernel module files were gone too, but obviously I was wrong.
Besides having the effect that drivers are loaded that should not: now the nvidia driver (kernel module) has been loaded, and I have a working desktop. The files that are contained in the G05 packages from the nvidia repo should be the same as there are now. What might cause my desktop staying black wehen the packages are present, but going to work when the module files are still there, but the rest isn't?
Maybe the reason for the detailed display is nvidia, and the reason for being slow is nouveau? ;)
Werner Both driver filesets are being loaded, hence a conflict. And yes, nouveau does not perform as well as nvidia (at least with the various cards I have used), particularly if compositing is used. Nouveau is loaded by default unless the kernel is instructed to not do so (i.e., blacklisted).
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
DennisG schrieb am 08.07.19 um 17:43:
Both driver filesets are being loaded, hence a conflict. And yes, nouveau does not perform as well as nvidia (at least with the various cards I have used), particularly if compositing is used. Nouveau is loaded by default unless the kernel is instructed to not do so (i.e., blacklisted).
Yes, I know that. I never thought I'd come to this situation since I thought the nVidia drivers were gone after my "rpm -e" of everything containing "*nvid*". The driver files are still present in the update directory in /lib/modules, though - and rpm tells me they don't belong to any rpm package. I better check next time. I'll remove those nvidia kernel files and restart the pc, since I found that rmmod'ding may cause problems, even when there is no X server running. And I will blacklist the nvidia driver :) Werner -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/07/2019 10.11, Werner Flamme wrote:
DennisG schrieb am 08.07.19 um 17:43:
Both driver filesets are being loaded, hence a conflict. And yes, nouveau does not perform as well as nvidia (at least with the various cards I have used), particularly if compositing is used. Nouveau is loaded by default unless the kernel is instructed to not do so (i.e., blacklisted).
Yes, I know that. I never thought I'd come to this situation since I thought the nVidia drivers were gone after my "rpm -e" of everything containing "*nvid*". The driver files are still present in the update directory in /lib/modules, though - and rpm tells me they don't belong to any rpm package. I better check next time.
It is possible they don't belong to any rpm, but were created by the post-install script in the nvidia rpm, and not erased by the corresponding script on uninstall.
I'll remove those nvidia kernel files and restart the pc, since I found that rmmod'ding may cause problems, even when there is no X server running. And I will blacklist the nvidia driver :)
Werner
-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Werner Flamme composed on 2019-07-07 19:44 (UTC+0200):
I "rpm -e"d all nvidia packages. Was that what the uninstallation instructions accompanying the installation instructions directed? I doubt it. Following those instructions fully is the only way to ensure successful removal, other than reinstalling all of X and its components or the whole OS. -- Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata schrieb am 10.07.19 um 19:41:
Werner Flamme composed on 2019-07-07 19:44 (UTC+0200):
I "rpm -e"d all nvidia packages. Was that what the uninstallation instructions accompanying the installation instructions directed? I doubt it. Following those instructions fully is the only way to ensure successful removal, other than reinstalling all of X and its components or the whole OS.
What are installation instructions with rpm packages? What are uninstall instructions with rpm packages? If the are not in the respective script sections, they are poorly packaged, and I sure do not expect this from a package distributed by the vendor of the packaged software. If the remaining files were created in a script section when installing, I expect another script section to care about them when uninstalling. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/07/2019 09.35, Werner Flamme wrote:
Felix Miata schrieb am 10.07.19 um 19:41:
Werner Flamme composed on 2019-07-07 19:44 (UTC+0200):
I "rpm -e"d all nvidia packages. Was that what the uninstallation instructions accompanying the installation instructions directed? I doubt it. Following those instructions fully is the only way to ensure successful removal, other than reinstalling all of X and its components or the whole OS.
What are installation instructions with rpm packages? What are uninstall instructions with rpm packages? If the are not in the respective script sections, they are poorly packaged, and I sure do not expect this from a package distributed by the vendor of the packaged software.
I think he refers to the wiki page at opensuse.org. <https://en.opensuse.org/SDB:NVIDIA_drivers> +++--------- *Uninstalling the NVIDIA drivers* 1 Start YaST, go to: Software -> Software Management 2 Change the 'Filter' to filter by software repositories 3 Select the respective NVIDIA repository 4 Mark any installed package from this repository for deletion and press 'Accept'. You may be prompted for conflicts, please ignore any conflicts and chose to break dependencies. 5 Now in YaST select: Software -> Software Repositories 6 Chose the respective NVIDIA repository and mark it 'disabled' - don't delete it as it will return enabled the next time the repositories are synced with the server. Uninstalling the proprietary drivers will restore the previous X configuration file /etc/X11/xorg.conf if one existed. If the hardware has changed in the mean time it may be necessary to manually edit this file. On Leap 42.3 you may want to install the drm-kmp-default package again. sudo zypper in drm-kmp-default ---------++- I have a doubt here if some other package should be reinstalled because nvidia replaces some file, but perhaps I'm confused on doing it the hard way. <https://en.opensuse.org/SDB:NVIDIA_the_hard_way>
If the remaining files were created in a script section when installing, I expect another script section to care about them when uninstalling.
Yes. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. schrieb am 11.07.19 um 12:17:
On 11/07/2019 09.35, Werner Flamme wrote:
Felix Miata schrieb am 10.07.19 um 19:41:
Werner Flamme composed on 2019-07-07 19:44 (UTC+0200):
I "rpm -e"d all nvidia packages. Was that what the uninstallation instructions accompanying the installation instructions directed? I doubt it. Following those instructions fully is the only way to ensure successful removal, other than reinstalling all of X and its components or the whole OS.
What are installation instructions with rpm packages? What are uninstall instructions with rpm packages? If the are not in the respective script sections, they are poorly packaged, and I sure do not expect this from a package distributed by the vendor of the packaged software.
I think he refers to the wiki page at opensuse.org.
<https://en.opensuse.org/SDB:NVIDIA_drivers>
+++--------- *Uninstalling the NVIDIA drivers*
1 Start YaST, go to: Software -> Software Management 2 Change the 'Filter' to filter by software repositories 3 Select the respective NVIDIA repository 4 Mark any installed package from this repository for deletion and press 'Accept'. You may be prompted for conflicts, please ignore any conflicts and chose to break dependencies. 5 Now in YaST select: Software -> Software Repositories 6 Chose the respective NVIDIA repository and mark it 'disabled' - don't delete it as it will return enabled the next time the repositories are synced with the server.
Uninstalling the proprietary drivers will restore the previous X configuration file /etc/X11/xorg.conf if one existed. If the hardware has changed in the mean time it may be necessary to manually edit this file.
On Leap 42.3 you may want to install the drm-kmp-default package again.
sudo zypper in drm-kmp-default ---------++-
Thank you for re-reading the page for me. All that YaST stuff does nothing more but rpm -e does - it removes the packages. Afterwards, I can "zypper mr -d nvidia_151" - that's my repo name for the nVidia drivers. I did not ignore the dependencies, BTW. I treid to uninstall the driver packages only, but the compute-G05 package wanted to be uninstalled too. I did so. Maybe next time I try "zypper rm <packename>", and hopefully the dependencies are removed automatically along with the package.
I have a doubt here if some other package should be reinstalled because nvidia replaces some file, but perhaps I'm confused on doing it the hard way.
I installed the nVidia drivers at command line via zypper, and I did not see that any package has been removed then.
That's a whole nother story :) BTDT, had no fun. Werner -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Werner Flamme <werner.flamme@email.de> [07-12-19 07:58]:
Carlos E. R. schrieb am 11.07.19 um 12:17:
On 11/07/2019 09.35, Werner Flamme wrote:
Felix Miata schrieb am 10.07.19 um 19:41:
Werner Flamme composed on 2019-07-07 19:44 (UTC+0200):
I "rpm -e"d all nvidia packages. Was that what the uninstallation instructions accompanying the installation instructions directed? I doubt it. Following those instructions fully is the only way to ensure successful removal, other than reinstalling all of X and its components or the whole OS.
What are installation instructions with rpm packages? What are uninstall instructions with rpm packages? If the are not in the respective script sections, they are poorly packaged, and I sure do not expect this from a package distributed by the vendor of the packaged software.
I think he refers to the wiki page at opensuse.org.
<https://en.opensuse.org/SDB:NVIDIA_drivers>
+++--------- *Uninstalling the NVIDIA drivers*
1 Start YaST, go to: Software -> Software Management 2 Change the 'Filter' to filter by software repositories 3 Select the respective NVIDIA repository 4 Mark any installed package from this repository for deletion and press 'Accept'. You may be prompted for conflicts, please ignore any conflicts and chose to break dependencies. 5 Now in YaST select: Software -> Software Repositories 6 Chose the respective NVIDIA repository and mark it 'disabled' - don't delete it as it will return enabled the next time the repositories are synced with the server.
Uninstalling the proprietary drivers will restore the previous X configuration file /etc/X11/xorg.conf if one existed. If the hardware has changed in the mean time it may be necessary to manually edit this file.
On Leap 42.3 you may want to install the drm-kmp-default package again.
sudo zypper in drm-kmp-default ---------++-
Thank you for re-reading the page for me. All that YaST stuff does nothing more but rpm -e does - it removes the packages. Afterwards, I can "zypper mr -d nvidia_151" - that's my repo name for the nVidia drivers.
I did not ignore the dependencies, BTW. I treid to uninstall the driver packages only, but the compute-G05 package wanted to be uninstalled too. I did so.
Maybe next time I try "zypper rm <packename>", and hopefully the dependencies are removed automatically along with the package.
most applications display a short "help" page, ie: zypper --help zypper rm -u <packagename> displays subj packages and waits for you to approve
I have a doubt here if some other package should be reinstalled because nvidia replaces some file, but perhaps I'm confused on doing it the hard way.
I installed the nVidia drivers at command line via zypper, and I did not see that any package has been removed then.
my choice and has been for *many* years. sh ./<package>.run -aqs --install-libglvnd you may not need --inst... if you choose this method, try w/o first. if fails, no harm and include it. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op vrijdag 12 juli 2019 14:27:54 CEST schreef Patrick Shanahan:
* Werner Flamme <werner.flamme@email.de> [07-12-19 07:58]:
Carlos E. R. schrieb am 11.07.19 um 12:17:
On 11/07/2019 09.35, Werner Flamme wrote:
Felix Miata schrieb am 10.07.19 um 19:41:
Werner Flamme composed on 2019-07-07 19:44 (UTC+0200):
I "rpm -e"d all nvidia packages.
Was that what the uninstallation instructions accompanying the installation instructions directed? I doubt it. Following those instructions fully is the only way to ensure successful removal, other than reinstalling all of X and its components or the whole OS.
What are installation instructions with rpm packages? What are uninstall instructions with rpm packages? If the are not in the respective script sections, they are poorly packaged, and I sure do not expect this from a package distributed by the vendor of the packaged software.
I think he refers to the wiki page at opensuse.org.
<https://en.opensuse.org/SDB:NVIDIA_drivers>
+++--------- *Uninstalling the NVIDIA drivers*
1 Start YaST, go to: Software -> Software Management 2 Change the 'Filter' to filter by software repositories 3 Select the respective NVIDIA repository 4 Mark any installed package from this repository for deletion and
press 'Accept'. You may be prompted for conflicts, please ignore any conflicts and chose to break dependencies.
5 Now in YaST select: Software -> Software Repositories 6 Chose the respective NVIDIA repository and mark it 'disabled' -
don't delete it as it will return enabled the next time the repositories are synced with the server.
Uninstalling the proprietary drivers will restore the previous X configuration file /etc/X11/xorg.conf if one existed. If the hardware has changed in the mean time it may be necessary to manually edit this file.
On Leap 42.3 you may want to install the drm-kmp-default package again.
sudo zypper in drm-kmp-default ---------++-
Thank you for re-reading the page for me. All that YaST stuff does nothing more but rpm -e does - it removes the packages. Afterwards, I can "zypper mr -d nvidia_151" - that's my repo name for the nVidia drivers.
I did not ignore the dependencies, BTW. I treid to uninstall the driver packages only, but the compute-G05 package wanted to be uninstalled too. I did so.
Maybe next time I try "zypper rm <packename>", and hopefully the dependencies are removed automatically along with the package.
most applications display a short "help" page, ie: zypper --help
zypper rm -u <packagename> displays subj packages and waits for you to approve
I have a doubt here if some other package should be reinstalled because nvidia replaces some file, but perhaps I'm confused on doing it the hard way.
I installed the nVidia drivers at command line via zypper, and I did not see that any package has been removed then.
my choice and has been for *many* years.
sh ./<package>.run -aqs --install-libglvnd
you may not need --inst... if you choose this method, try w/o first. if fails, no harm and include it. You might include dkms, for automated rebuilds on kernel updates. zypper install dkms systemctl enable dkms.service systemctl start dkms.service sh ./<package>.run -aqs --dkms $whateverotheroptions
I have no NVIDIA hardware myself, but on a friend's 15.0 / 15..1 this works like a charm. -- 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-openSUSE <knurpht@opensuse.org> [07-12-19 09:58]:
Op vrijdag 12 juli 2019 14:27:54 CEST schreef Patrick Shanahan:
* Werner Flamme <werner.flamme@email.de> [07-12-19 07:58]:
Carlos E. R. schrieb am 11.07.19 um 12:17:
On 11/07/2019 09.35, Werner Flamme wrote:
Felix Miata schrieb am 10.07.19 um 19:41:
Werner Flamme composed on 2019-07-07 19:44 (UTC+0200): > I "rpm -e"d all nvidia packages.
Was that what the uninstallation instructions accompanying the installation instructions directed? I doubt it. Following those instructions fully is the only way to ensure successful removal, other than reinstalling all of X and its components or the whole OS.
What are installation instructions with rpm packages? What are uninstall instructions with rpm packages? If the are not in the respective script sections, they are poorly packaged, and I sure do not expect this from a package distributed by the vendor of the packaged software.
I think he refers to the wiki page at opensuse.org.
<https://en.opensuse.org/SDB:NVIDIA_drivers>
+++--------- *Uninstalling the NVIDIA drivers*
1 Start YaST, go to: Software -> Software Management 2 Change the 'Filter' to filter by software repositories 3 Select the respective NVIDIA repository 4 Mark any installed package from this repository for deletion and
press 'Accept'. You may be prompted for conflicts, please ignore any conflicts and chose to break dependencies.
5 Now in YaST select: Software -> Software Repositories 6 Chose the respective NVIDIA repository and mark it 'disabled' -
don't delete it as it will return enabled the next time the repositories are synced with the server.
Uninstalling the proprietary drivers will restore the previous X configuration file /etc/X11/xorg.conf if one existed. If the hardware has changed in the mean time it may be necessary to manually edit this file.
On Leap 42.3 you may want to install the drm-kmp-default package again.
sudo zypper in drm-kmp-default ---------++-
Thank you for re-reading the page for me. All that YaST stuff does nothing more but rpm -e does - it removes the packages. Afterwards, I can "zypper mr -d nvidia_151" - that's my repo name for the nVidia drivers.
I did not ignore the dependencies, BTW. I treid to uninstall the driver packages only, but the compute-G05 package wanted to be uninstalled too. I did so.
Maybe next time I try "zypper rm <packename>", and hopefully the dependencies are removed automatically along with the package.
most applications display a short "help" page, ie: zypper --help
zypper rm -u <packagename> displays subj packages and waits for you to approve
I have a doubt here if some other package should be reinstalled because nvidia replaces some file, but perhaps I'm confused on doing it the hard way.
I installed the nVidia drivers at command line via zypper, and I did not see that any package has been removed then.
my choice and has been for *many* years.
sh ./<package>.run -aqs --install-libglvnd
you may not need --inst... if you choose this method, try w/o first. if fails, no harm and include it. You might include dkms, for automated rebuilds on kernel updates. zypper install dkms systemctl enable dkms.service systemctl start dkms.service sh ./<package>.run -aqs --dkms $whateverotheroptions
I have no NVIDIA hardware myself, but on a friend's 15.0 / 15..1 this works like a charm.
what function does the "--dkms" fill, only allow reinstalling XXxx.run on a new kernel w/o rebooting first? tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op vrijdag 12 juli 2019 18:00:38 CEST schreef Patrick Shanahan:
* Knurpht-openSUSE <knurpht@opensuse.org> [07-12-19 09:58]:
Op vrijdag 12 juli 2019 14:27:54 CEST schreef Patrick Shanahan:
* Werner Flamme <werner.flamme@email.de> [07-12-19 07:58]:
Carlos E. R. schrieb am 11.07.19 um 12:17:
On 11/07/2019 09.35, Werner Flamme wrote:
Felix Miata schrieb am 10.07.19 um 19:41: > Werner Flamme composed on 2019-07-07 19:44 (UTC+0200): >> I "rpm -e"d all nvidia packages. > > Was that what the uninstallation instructions accompanying the > installation > instructions directed? I doubt it. Following those instructions > fully > is the only way to ensure successful removal, other than > reinstalling > all of X and its components or the whole OS.
What are installation instructions with rpm packages? What are uninstall instructions with rpm packages? If the are not in the respective script sections, they are poorly packaged, and I sure do not expect this from a package distributed by the vendor of the packaged software.
I think he refers to the wiki page at opensuse.org.
<https://en.opensuse.org/SDB:NVIDIA_drivers>
+++--------- *Uninstalling the NVIDIA drivers*
1 Start YaST, go to: Software -> Software Management 2 Change the 'Filter' to filter by software repositories 3 Select the respective NVIDIA repository 4 Mark any installed package from this repository for deletion and
press 'Accept'. You may be prompted for conflicts, please ignore any conflicts and chose to break dependencies.
5 Now in YaST select: Software -> Software Repositories 6 Chose the respective NVIDIA repository and mark it 'disabled' -
don't delete it as it will return enabled the next time the repositories are synced with the server.
Uninstalling the proprietary drivers will restore the previous X configuration file /etc/X11/xorg.conf if one existed. If the hardware has changed in the mean time it may be necessary to manually edit this file.
On Leap 42.3 you may want to install the drm-kmp-default package again.
sudo zypper in drm-kmp-default ---------++-
Thank you for re-reading the page for me. All that YaST stuff does nothing more but rpm -e does - it removes the packages. Afterwards, I can "zypper mr -d nvidia_151" - that's my repo name for the nVidia drivers.
I did not ignore the dependencies, BTW. I treid to uninstall the driver packages only, but the compute-G05 package wanted to be uninstalled too. I did so.
Maybe next time I try "zypper rm <packename>", and hopefully the dependencies are removed automatically along with the package.
most applications display a short "help" page, ie: zypper --help
zypper rm -u <packagename>
displays subj packages and waits for you to approve
I have a doubt here if some other package should be reinstalled because nvidia replaces some file, but perhaps I'm confused on doing it the hard way.
I installed the nVidia drivers at command line via zypper, and I did not see that any package has been removed then.
my choice and has been for *many* years.
sh ./<package>.run -aqs --install-libglvnd
you may not need --inst... if you choose this method, try w/o first. if fails, no harm and include it.
You might include dkms, for automated rebuilds on kernel updates. zypper install dkms systemctl enable dkms.service systemctl start dkms.service sh ./<package>.run -aqs --dkms $whateverotheroptions
I have no NVIDIA hardware myself, but on a friend's 15.0 / 15..1 this works like a charm.
what function does the "--dkms" fill, only allow reinstalling XXxx.run on a new kernel w/o rebooting first?
tks, Yep.
-- 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/07/2019 02.46, Werner Flamme wrote:
Am 03.07.19 um 07:24 schrieb Felix Miata:
David C. Rankin composed on 2019-07-02 23:45 (UTC-0500):
Oh, and what about Nvidia? I recall a few issues with zypper dup and Nvidia. Are those fixed?
The first update kernel lp151.28.4.1 for 15.1 users of NVidia hardware with either FOSS DDX was foobar. It was 18 days before lp151.28.7.1 fixed it. Takashi went on vacation right before problem was reported.
I read this and updated to 15.1. Got kernel-default-4.12.14-lp151.28.7.1.x86_64. Installed the G05 drivers (430.26-lp151.14.1) for my 1050Ti. Rebooted. Black screen.
Which combination of kernel and nVidia driver is expected to work, preferrably with plasma desktop?
The driver should depend only on the card. If you think that the desktop might be an issue, try another desktop.
And if I get a black screen again, and - as usual - no errors in /var/log/Xorg.0.log, where else can I look?
I would look up the log very carefully, just in case. And maybe, just maybe, reinstall the driver again with zypper and watch carefully the text output. In my case, I found that there was an error and the script aborted, but zypper continued happily as if nothing has happened and claimed successful install. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 7/7/19 2:46 AM, Werner Flamme wrote:
Am 03.07.19 um 07:24 schrieb Felix Miata:
David C. Rankin composed on 2019-07-02 23:45 (UTC-0500):
Oh, and what about Nvidia? I recall a few issues with zypper dup and Nvidia. Are those fixed?
The first update kernel lp151.28.4.1 for 15.1 users of NVidia hardware with either FOSS DDX was foobar. It was 18 days before lp151.28.7.1 fixed it. Takashi went on vacation right before problem was reported.
I read this and updated to 15.1. Got kernel-default-4.12.14-lp151.28.7.1.x86_64. Installed the G05 drivers (430.26-lp151.14.1) for my 1050Ti. Rebooted. Black screen.
Which combination of kernel and nVidia driver is expected to work, preferrably with plasma desktop?
And if I get a black screen again, and - as usual - no errors in /var/log/Xorg.0.log, where else can I look?
Regards, Werner --
G05 driver is 146% the right one to use for your card. Boot, get a black screen, switch to tty1 with Ctrl+Alt+F1. Log in. Make sure you don't have any nouveau-specific kernel command line options. If you use GRUB, that's the GRUB_CMDLINE_LINUX and GRUB_CMDLINE_LINUX_DEFAULT variables in /etc/default/grub. If you have edited the file, execute: sudo grub2-mkconfig -o /boot/grub2/grub.cfg Remove G04 drivers, if you still have them: sudo zypper rm '*nvidia*G04*' Reinstall G05 drivers: sudo zypper in -f nvidia-computeG05 nvidia-gfxG05-kmp-default nvidia-glG05 x11-video-nvidiaG05 Make sure /etc/modprobe.d/nvidia-default.conf contains one line: blacklist nouveau Reboot. If you still get a black screen, execute sudo journalctl -b > journal.txt sudo cat /var/log/Xorg.0.log > xorg.txt and attach both files to your next email. The correct behaviour is when you run sudo lspci -v | grep -i nvidia and it produces something like 01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1) (prog-if 00 [VGA controller]) Kernel driver in use: nvidia Kernel modules: nouveau, nvidia_drm, nvidia with the important line being Kernel driver in use: nvidia I also have Mesa-dri-nouveau package blacklisted automatically (no idea whether by nvidia packages or something else), it might or might not matter. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Mittwoch, 3. Juli 2019, 06:43:13 CEST schrieb David C. Rankin:
All,
Another end-of-life has come to pass. 42.3 joins 13.1, 11.4, 11.0 (minus the KDE 4.0.4a mess), 10.3, 10.0, 9.2 Pro, 9.0 Pro, 8.2 Pro, 8.0 Pro, 7.2 Pro, and 7.0 Pro in a long line of good releases. (others will remember earlier, but the (Air) release was my first, Mandy before then and DSL)
My all time favorites were: 9.3 and 13.2, but take my appraisal with a grain of salt: I'd been running fat 9.3 desktops mostly diskless (with nfs/aufs filesystem stack on the clients), KDE desktop and XP in windows... 40 desktops in a transport company, some systems had uptimes of a few month without a twitch. A 9.3 with Asterisk 1.0.2/ISDN survived until in January this year. The 13.2 is my most bent distro ever.. (Kernel, gcc, llvm, Python{2,3}, Qt, LibreOffice, NVidia & ffmpeg (on local obs), ...), but I'm pretty happy with TW now (but on servers/telco systems and w/o btrfs). Cheers, Pete -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/07/2019 06.43, David C. Rankin wrote:
All,
Another end-of-life has come to pass. 42.3 joins 13.1, 11.4, 11.0 (minus the KDE 4.0.4a mess), 10.3, 10.0, 9.2 Pro, 9.0 Pro, 8.2 Pro, 8.0 Pro, 7.2 Pro, and 7.0 Pro in a long line of good releases. (others will remember earlier, but the (Air) release was my first, Mandy before then and DSL)
So now what to do?? 15.0 end-of-life is scheduled for November, 15.1 is scheduled for November 2020, but I would miss trying a zypper dup. So many choices...
So is a change of repo versions to 15.0 and a:
zypper dup --download-in-advance
a good path for now?
To 15.0 or to 15.1? I did that upgrade to 15.0 via zypper dup, it was fine. The upgrade via DVD was impossible: I don't remember all the issues, I think it was two. One was on bugzilla, some update was needed, which is impossible on the DVD. I forget what it was... :-? The other issue is that the DVD upgrade refuses to continue if fstab has a reiserfs partition listed. Even if it is a data partition. I still have pending work to do: migrate from SuSEfirewall2 to firewalld. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 07/03/2019 06:01 AM, Carlos E. R. wrote:
To 15.0 or to 15.1?
I did that upgrade to 15.0 via zypper dup, it was fine. The upgrade via DVD was impossible: I don't remember all the issues, I think it was two. One was on bugzilla, some update was needed, which is impossible on the DVD. I forget what it was... :-? The other issue is that the DVD upgrade refuses to continue if fstab has a reiserfs partition listed. Even if it is a data partition.
I still have pending work to do: migrate from SuSEfirewall2 to firewalld.
Oh 42.3 - 15.0 and then 15.0 - 15.1 when 15.0 hist e-o-l in November. (SDB page says you can't jump a release with zypper dup) I'll give it a try. Worst that can happen is I have to wipe /, and do a fresh NET-Install and roll /home back in. -- David C. Rankin, J.D.,P.E.
David C. Rankin composed on 2019-07-03 17:21 (UTC-0500):
Oh 42.3 - 15.0 and then 15.0 - 15.1 when 15.0 hist e-o-l in November. (SDB page says you can't jump a release with zypper dup)
It /must/ say that because the process gets no official testing. :-p Don't expect any kind of trouble unrelated to proprietary NVidia video drivers (which I never install anywhere). Of my 22+ 15.1 installations, ~20 or more are upgrades. Roughly half of those are from 13.1, 13.2, 42.1, 42.2 or 42.3 directly to 15.1, the same process that has been happening here for much longer than I can remember, but likely back as far as 11.0 on some hosts. All 15.1s except one with IceWM, and two or more not my own with Plasma, are using either KDE3 or TDE. Most dups were using various 15.1 pre-releases, but all were/are current as of June 18 or later. Zypper is /very/ good at duping. It gets lots of practice from Tumbleweeders, including me. With TW just this past week I upgraded one that had last been updated Dec 2016. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/2019 00.21, David C. Rankin wrote:
On 07/03/2019 06:01 AM, Carlos E. R. wrote:
To 15.0 or to 15.1?
I did that upgrade to 15.0 via zypper dup, it was fine. The upgrade via DVD was impossible: I don't remember all the issues, I think it was two. One was on bugzilla, some update was needed, which is impossible on the DVD. I forget what it was... :-? The other issue is that the DVD upgrade refuses to continue if fstab has a reiserfs partition listed. Even if it is a data partition.
I still have pending work to do: migrate from SuSEfirewall2 to firewalld.
Oh 42.3 - 15.0 and then 15.0 - 15.1 when 15.0 hist e-o-l in November. (SDB page says you can't jump a release with zypper dup)
Actually you can. Several versions, in fact. Tested in openQA. <https://lists.opensuse.org/opensuse-factory/2017-12/msg00315.html>
I'll give it a try. Worst that can happen is I have to wipe /, and do a fresh NET-Install and roll /home back in.
-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
I still have pending work to do: migrate from SuSEfirewall2 to firewalld.
My biggest concern, too. So does a zypper dup keep SuSEfirewall2 installed and working? Or is the system without a working firewall after the upgrade? Would be a no-go for our server.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/07/2019 16.16, Peter Suetterlin wrote:
Carlos E. R. wrote:
I still have pending work to do: migrate from SuSEfirewall2 to firewalld.
My biggest concern, too.
So does a zypper dup keep SuSEfirewall2 installed and working? Or is the system without a working firewall after the upgrade? Would be a no-go for our server....
It is kept. At least on 15.0 - I have two machines (or is it three) in that state. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 06/07/2019 00:00, Carlos E. R. wrote:
On 05/07/2019 16.16, Peter Suetterlin wrote:
Carlos E. R. wrote:
I still have pending work to do: migrate from SuSEfirewall2 to firewalld.
My biggest concern, too.
So does a zypper dup keep SuSEfirewall2 installed and working? Or is the system without a working firewall after the upgrade? Would be a no-go for our server....
It is kept. At least on 15.0 - I have two machines (or is it three) in that state.
I imagine it should stay until Leap 16 so you have some time. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/07/2019 01.52, Simon Lees wrote:
On 06/07/2019 00:00, Carlos E. R. wrote:
On 05/07/2019 16.16, Peter Suetterlin wrote:
Carlos E. R. wrote:
I still have pending work to do: migrate from SuSEfirewall2 to firewalld.
My biggest concern, too.
So does a zypper dup keep SuSEfirewall2 installed and working? Or is the system without a working firewall after the upgrade? Would be a no-go for our server....
It is kept. At least on 15.0 - I have two machines (or is it three) in that state.
I imagine it should stay until Leap 16 so you have some time.
:-D -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 03/07/2019 00:43, David C. Rankin wrote:
So is a change of repo versions to 15.0 and a:
zypper dup --download-in-advance
a good path for now?
You mean as an alternative to downloading the DVD or the network DVD and installing a baseline using that? It makes me wonder, sometimes, what I have installed that isn't going to be in 15.0 or 15.1 from the Days of Old. Or for that matter what archaisms I have have at present that never got updated. Someone is going to tell me that I can run a 'rpm' search to determine what is not 42.3 to show up archaisms. Yes I'll do that but its not going to help. The reason I think that is that I seem to recall when I installed 42.0 from DVD the first think it did was destroy the old RPM database so I could cherry-pick in detail what was going to be installed for new. BUT I also didn't reformat /usr and hence /usr/bin. Or the ROOTFS for that matter and hence /bin. So, perhaps, updating all and I mean ALL my repos from 42.3 to 15.0 (after establishing that exists for each and every one of them) and doing the "dup" for all of them might be the best way to preserve things. That is, not starting with a zapped RPM database. -- 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/03/2019 12:49 PM, Anton Aylward wrote:
So, perhaps, updating all and I mean ALL my repos from 42.3 to 15.0 (after establishing that exists for each and every one of them) and doing the "dup" for all of them might be the best way to preserve things. That is, not starting with a zapped RPM database.
Yes, amazingly, all these years I've just done fresh installs, never trusting this (Voodoo) of duping to another release -- But... if it works, I would save hours of getting everything going and I suspect with --no-recommends set, it should be a sane package for (existing package) update. Like I wrote in response to Carlos, worst case scenario, it all goes to hell and I reformat / and roll /home back in when done. My biggest concern in the Nvidia drivers. The rest is just vanilla 42.3, so from the threads over the past year or so, the base zypper dup seems OK for most (minus a network connection problem, etc..), but if the Nvidia drives don't get updated, I can see being left without X until I can get that sorted (which will be fine as long as I have a full mult-user target to make the repairs in) -- 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 04/07/2019 00.29, David C. Rankin wrote:
On 07/03/2019 12:49 PM, Anton Aylward wrote:
So, perhaps, updating all and I mean ALL my repos from 42.3 to 15.0 (after establishing that exists for each and every one of them) and doing the "dup" for all of them might be the best way to preserve things. That is, not starting with a zapped RPM database.
Yes, amazingly, all these years I've just done fresh installs, never trusting this (Voodoo) of duping to another release -- But... if it works, I would save hours of getting everything going and I suspect with --no-recommends set, it should be a sane package for (existing package) update.
Be sure to run, after done, this: rpmconfigcheck It produces an output like this: Telcontar:~ # rpmconfigcheck Searching for unresolved configuration files Please check the following files (see /var/adm/rpmconfigcheck): /etc/apparmor.d/usr.lib.dovecot.auth.rpmnew /etc/apparmor.d/usr.lib.dovecot.config.rpmnew /etc/apparmor.d/usr.lib.dovecot.dovecot-lda.rpmnew /etc/apparmor.d/usr.sbin.smbd.rpmnew /etc/my.cnf.rpmnew /etc/pam.d/login.rpmnew /etc/postfix/main.cf.rpmnew /etc/postfix/master.cf.rpmnew /etc/pulse/client.conf.d/50-system.conf.rpmsave /etc/rsyslog.conf.rpmnew /etc/ssh/ssh_config.rpmnew /etc/ssh/sshd_config.rpmnew Telcontar:~ # The procedure then is to verify each of those against the config file, like this: meld /etc/ssh/sshd_config.rpmnew /etc/ssh/sshd_config & And see what changes I want to apply or keep. For example, the first line is: # $OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $ compared to # $OpenBSD: sshd_config,v 1.98 2016/02/17 05:29:04 djm Exp $ So I overwrite. Just a mouse click. Finish review of the file, and save. Repeat for all the files, till the list is empty.
Like I wrote in response to Carlos, worst case scenario, it all goes to hell and I reformat / and roll /home back in when done.
Yes, having a full backup is a good thing at this point. I recomend it.
My biggest concern in the Nvidia drivers. The rest is just vanilla 42.3, so from the threads over the past year or so, the base zypper dup seems OK for most (minus a network connection problem, etc..), but if the Nvidia drives don't get updated, I can see being left without X until I can get that sorted (which will be fine as long as I have a full mult-user target to make the repairs in)
Normally, you simply have the NVidia repo enabled, and it is updated just fine. The problem was specific to 15.1. In case of problems, my recommendation is to repeat the upgrade of each nvidia rpm by hand (command rpm) and watch carefully the output. I hit a problem where the script failed, but the rpm command is not told about it and claims success. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
i just did a 'zypper up' on my 42.3 installation and it seemed to go fine -- is there a time (soon?) when it will fail? On Thu, Jul 4, 2019 at 7:29 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 04/07/2019 00.29, David C. Rankin wrote:
On 07/03/2019 12:49 PM, Anton Aylward wrote:
So, perhaps, updating all and I mean ALL my repos from 42.3 to 15.0 (after establishing that exists for each and every one of them) and doing the "dup" for all of them might be the best way to preserve things. That is, not starting with a zapped RPM database.
Yes, amazingly, all these years I've just done fresh installs, never trusting this (Voodoo) of duping to another release -- But... if it works, I would save hours of getting everything going and I suspect with --no-recommends set, it should be a sane package for (existing package) update.
Be sure to run, after done, this:
rpmconfigcheck
It produces an output like this:
Telcontar:~ # rpmconfigcheck Searching for unresolved configuration files Please check the following files (see /var/adm/rpmconfigcheck): /etc/apparmor.d/usr.lib.dovecot.auth.rpmnew /etc/apparmor.d/usr.lib.dovecot.config.rpmnew /etc/apparmor.d/usr.lib.dovecot.dovecot-lda.rpmnew /etc/apparmor.d/usr.sbin.smbd.rpmnew /etc/my.cnf.rpmnew /etc/pam.d/login.rpmnew /etc/postfix/main.cf.rpmnew /etc/postfix/master.cf.rpmnew /etc/pulse/client.conf.d/50-system.conf.rpmsave /etc/rsyslog.conf.rpmnew /etc/ssh/ssh_config.rpmnew /etc/ssh/sshd_config.rpmnew Telcontar:~ #
The procedure then is to verify each of those against the config file, like this:
meld /etc/ssh/sshd_config.rpmnew /etc/ssh/sshd_config &
And see what changes I want to apply or keep.
For example, the first line is:
# $OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $
compared to
# $OpenBSD: sshd_config,v 1.98 2016/02/17 05:29:04 djm Exp $
So I overwrite. Just a mouse click. Finish review of the file, and save.
Repeat for all the files, till the list is empty.
Like I wrote in response to Carlos, worst case scenario, it all goes to hell and I reformat / and roll /home back in when done.
Yes, having a full backup is a good thing at this point. I recomend it.
My biggest concern in the Nvidia drivers. The rest is just vanilla 42.3, so from the threads over the past year or so, the base zypper dup seems OK for most (minus a network connection problem, etc..), but if the Nvidia drives don't get updated, I can see being left without X until I can get that sorted (which will be fine as long as I have a full mult-user target to make the repairs in)
Normally, you simply have the NVidia repo enabled, and it is updated just fine. The problem was specific to 15.1.
In case of problems, my recommendation is to repeat the upgrade of each nvidia rpm by hand (command rpm) and watch carefully the output. I hit a problem where the script failed, but the rpm command is not told about it and claims success.
-- Cheers / Saludos,
Carlos E. R. (from 15.0 x86_64 at Telcontar)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* tooth pik <toothpik6@gmail.com> [07-04-19 09:07]:
i just did a 'zypper up' on my 42.3 installation and it seemed to go fine -- is there a time (soon?) when it will fail?
On Thu, Jul 4, 2019 at 7:29 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 04/07/2019 00.29, David C. Rankin wrote:
On 07/03/2019 12:49 PM, Anton Aylward wrote:
So, perhaps, updating all and I mean ALL my repos from 42.3 to 15.0 (after establishing that exists for each and every one of them) and doing the "dup" for all of them might be the best way to preserve things. That is, not starting with a zapped RPM database.
Yes, amazingly, all these years I've just done fresh installs, never trusting this (Voodoo) of duping to another release -- But... if it works, I would save hours of getting everything going and I suspect with --no-recommends set, it should be a sane package for (existing package) update.
Be sure to run, after done, this:
rpmconfigcheck
It produces an output like this:
Telcontar:~ # rpmconfigcheck Searching for unresolved configuration files Please check the following files (see /var/adm/rpmconfigcheck): /etc/apparmor.d/usr.lib.dovecot.auth.rpmnew /etc/apparmor.d/usr.lib.dovecot.config.rpmnew /etc/apparmor.d/usr.lib.dovecot.dovecot-lda.rpmnew /etc/apparmor.d/usr.sbin.smbd.rpmnew /etc/my.cnf.rpmnew /etc/pam.d/login.rpmnew /etc/postfix/main.cf.rpmnew /etc/postfix/master.cf.rpmnew /etc/pulse/client.conf.d/50-system.conf.rpmsave /etc/rsyslog.conf.rpmnew /etc/ssh/ssh_config.rpmnew /etc/ssh/sshd_config.rpmnew Telcontar:~ #
The procedure then is to verify each of those against the config file, like this:
meld /etc/ssh/sshd_config.rpmnew /etc/ssh/sshd_config &
And see what changes I want to apply or keep.
For example, the first line is:
# $OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $
compared to
# $OpenBSD: sshd_config,v 1.98 2016/02/17 05:29:04 djm Exp $
So I overwrite. Just a mouse click. Finish review of the file, and save.
Repeat for all the files, till the list is empty.
Like I wrote in response to Carlos, worst case scenario, it all goes to hell and I reformat / and roll /home back in when done.
Yes, having a full backup is a good thing at this point. I recomend it.
My biggest concern in the Nvidia drivers. The rest is just vanilla 42.3, so from the threads over the past year or so, the base zypper dup seems OK for most (minus a network connection problem, etc..), but if the Nvidia drives don't get updated, I can see being left without X until I can get that sorted (which will be fine as long as I have a full mult-user target to make the repairs in)
Normally, you simply have the NVidia repo enabled, and it is updated just fine. The problem was specific to 15.1.
In case of problems, my recommendation is to repeat the upgrade of each nvidia rpm by hand (command rpm) and watch carefully the output. I hit a problem where the script failed, but the rpm command is not told about it and claims success.
-- Cheers / Saludos,
Carlos E. R. (from 15.0 x86_64 at Telcontar)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
when you least expect it. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/2019 09:05, tooth pik wrote:
i just did a 'zypper up' on my 42.3 installation and it seemed to go fine -- is there a time (soon?) when it will fail?
Mine is: # zypper up File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/repositories/KDE:/Applications/KDE_Frameworks5_...' Abort, retry, ignore? [a/r/i/...? shows all options] (a): i Do you want to disable the repository 423 KDE_Framework5_Leap permanently? [yes/no] (no): Warning: Skipping repository '423 KDE_Framework5_Leap' because of the above error. File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_Leap_42.3/' Abort, retry, ignore? [a/r/i/...? shows all options] (a): i Do you want to disable the repository 423 KDE_Qt5_Leap permanently? [yes/no] (no): Warning: Skipping repository '423 KDE_Qt5_Leap' because of the above error. File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Leap_42....' Abort, retry, ignore? [a/r/i/...? shows all options] (a): i Do you want to disable the repository 423_KDE_Framework5 permanently? [yes/no] (no): Warning: Skipping repository '423_KDE_Framework5' because of the above error. File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_Leap_42.3/' Abort, retry, ignore? [a/r/i/...? shows all options] (a): i Do you want to disable the repository KDE:Qt5 permanently? [yes/no] (no): n Warning: Skipping repository 'KDE:Qt5' because of the above error. A few others like "Printing" have already failed and been cancelled. -- 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
* Anton Aylward <opensuse@antonaylward.com> [07-07-19 09:14]:
On 04/07/2019 09:05, tooth pik wrote:
i just did a 'zypper up' on my 42.3 installation and it seemed to go fine -- is there a time (soon?) when it will fail?
Mine is:
# zypper up File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/repositories/KDE:/Applications/KDE_Frameworks5_...' Abort, retry, ignore? [a/r/i/...? shows all options] (a): i Do you want to disable the repository 423 KDE_Framework5_Leap permanently? [yes/no] (no): Warning: Skipping repository '423 KDE_Framework5_Leap' because of the above error. File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_Leap_42.3/' Abort, retry, ignore? [a/r/i/...? shows all options] (a): i Do you want to disable the repository 423 KDE_Qt5_Leap permanently? [yes/no] (no): Warning: Skipping repository '423 KDE_Qt5_Leap' because of the above error. File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/repositories/KDE:/Frameworks5/openSUSE_Leap_42....' Abort, retry, ignore? [a/r/i/...? shows all options] (a): i Do you want to disable the repository 423_KDE_Framework5 permanently? [yes/no] (no): Warning: Skipping repository '423_KDE_Framework5' because of the above error. File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/repositories/KDE:/Qt5/openSUSE_Leap_42.3/' Abort, retry, ignore? [a/r/i/...? shows all options] (a): i Do you want to disable the repository KDE:Qt5 permanently? [yes/no] (no): n Warning: Skipping repository 'KDE:Qt5' because of the above error.
A few others like "Printing" have already failed and been cancelled.
would probably save you a lot of time to check if the web addresses for the failing repos actually still exist and disable/remove those which do not. 42.3 is EOL 1 JUL 2019. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/07/2019 19.49, Anton Aylward wrote:
On 03/07/2019 00:43, David C. Rankin wrote:
So is a change of repo versions to 15.0 and a:
zypper dup --download-in-advance
a good path for now?
You mean as an alternative to downloading the DVD or the network DVD and installing a baseline using that?
It makes me wonder, sometimes, what I have installed that isn't going to be in 15.0 or 15.1 from the Days of Old. Or for that matter what archaisms I have have at present that never got updated.
Someone is going to tell me that I can run a 'rpm' search to determine what is not 42.3 to show up archaisms.
rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist \ | egrep -v "openSUSE\ Leap\ 42\.3|openSUSE_Leap_42\.3" | less -S :-D -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
In data mercoledì 3 luglio 2019 06:43:13 CEST, David C. Rankin ha scritto:
All,
Another end-of-life has come to pass. 42.3 joins 13.1, 11.4, 11.0 (minus the KDE 4.0.4a mess), 10.3, 10.0, 9.2 Pro, 9.0 Pro, 8.2 Pro, 8.0 Pro, 7.2 Pro, and 7.0 Pro in a long line of good releases. (others will remember earlier, but the (Air) release was my first, Mandy before then and DSL)
So now what to do?? 15.0 end-of-life is scheduled for November, 15.1 is scheduled for November 2020, but I would miss trying a zypper dup. So many choices...
So is a change of repo versions to 15.0 and a:
zypper dup --download-in-advance
a good path for now? My advice for you if you haven't yet updated: if you use KDE (only if you use this, I cannot speak for gnome) then I can highly advice to jump directly with zypper dup to 15.1. The numbers of issues that the KDE version alone solves already are impressive. I updated in general about 3 Month after each release. But this time I was happy to do it before. Lower CPU load, better stability, better applications. So my advice would be 15.1.
Of course if you are bound to some special software running only on 15.0 then the story is a different one. All the best for the upgrade. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin composed on 2019-07-02 23:43 (UTC-0500):
a good path for now?
Might depend on what you expect from it. On my main box, upgrading from 42.3 to 15.1 killed CIFS client access to my NTLM1 OS/2 host, so I'm still using 42.3. System sounds also took a hit, clicking loudly at start and end of each sound byte. :-( The update process it self mostly went well. OS/2 client can access Samba server's shares. One of KDE3's graphics or MM apps didn't get upgraded, as no such exists, kde3-digikam I think. Kdegraphics3-pdf is still reportedly "broken" by pdftools_any not being provided. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
By the way. Is anybody going to support evergreen for 42.x? 03.07.2019 7:43, David C. Rankin пишет:
All,
Another end-of-life has come to pass. 42.3 joins 13.1, 11.4, 11.0 (minus the KDE 4.0.4a mess), 10.3, 10.0, 9.2 Pro, 9.0 Pro, 8.2 Pro, 8.0 Pro, 7.2 Pro, and 7.0 Pro in a long line of good releases. (others will remember earlier, but the (Air) release was my first, Mandy before then and DSL)
So now what to do?? 15.0 end-of-life is scheduled for November, 15.1 is scheduled for November 2020, but I would miss trying a zypper dup. So many choices...
So is a change of repo versions to 15.0 and a:
zypper dup --download-in-advance
a good path for now?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/07/2019 17.34, Matwey V. Kornilov wrote:
By the way. Is anybody going to support evergreen for 42.x?
No, that project finished. Instead you get Leap major versions that can be updated to 3 or 4 minor versions easily. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 07/05/2019 10:34 AM, Matwey V. Kornilov wrote:
By the way. Is anybody going to support evergreen for 42.x?
I would go for that in a heartbeat. Last release with a properly working valgrind set of exclusion files that properly report the number of bytes allocated, e.g. #include <stdio.h> #include <stdlib.h> #define NVAL 5 int main (void) { int *a = malloc (NVAL * sizeof *a); if (!a) { perror ("malloc"); return 1; } for (int i = 0; i < NVAL; i++) { a[i] = NVAL - i; printf (i ? " %d" : "%d", a[i]); } putchar ('\n'); free (a); } 42.3 Correctly Reports: $ valgrind ./bin/vgtest ==10632== Memcheck, a memory error detector ==10632== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==10632== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==10632== Command: ./bin/vgtest ==10632== 5 4 3 2 1 ==10632== ==10632== HEAP SUMMARY: ==10632== in use at exit: 0 bytes in 0 blocks ==10632== total heap usage: 1 allocs, 1 frees, 20 bytes allocated ==10632== ==10632== All heap blocks were freed -- no leaks are possible ==10632== ==10632== For counts of detected and suppressed errors, rerun with: -v ==10632== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Yes Virginia, an allocation of 5 int requires 20 bytes of storage... Both 15.0 and 15.1 Incorrectly Report: $ valgrind ./bin/vgtest ==2015== Memcheck, a memory error detector ==2015== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2015== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2015== Command: ./bin/vgtest ==2015== 5 4 3 2 1 ==2015== ==2015== HEAP SUMMARY: ==2015== in use at exit: 0 bytes in 0 blocks ==2015== total heap usage: 2 allocs, 2 frees, 1,044 bytes allocated ==2015== ==2015== All heap blocks were freed -- no leaks are possible ==2015== ==2015== For counts of detected and suppressed errors, rerun with: -v ==2015== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Students, you can confirm and verify the corresponding allocation by checking with valgrind -- Wait... WTF? valgrind doesn't do that correctly anymore :( -- 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 06/07/2019 03:04, David C. Rankin wrote:
On 07/05/2019 10:34 AM, Matwey V. Kornilov wrote:
By the way. Is anybody going to support evergreen for 42.x?
I would go for that in a heartbeat. Last release with a properly working valgrind set of exclusion files that properly report the number of bytes allocated, e.g.
#include <stdio.h> #include <stdlib.h>
#define NVAL 5
int main (void) {
int *a = malloc (NVAL * sizeof *a); if (!a) { perror ("malloc"); return 1; } for (int i = 0; i < NVAL; i++) { a[i] = NVAL - i; printf (i ? " %d" : "%d", a[i]); } putchar ('\n');
free (a); }
42.3 Correctly Reports:
$ valgrind ./bin/vgtest ==10632== Memcheck, a memory error detector ==10632== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==10632== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==10632== Command: ./bin/vgtest ==10632== 5 4 3 2 1 ==10632== ==10632== HEAP SUMMARY: ==10632== in use at exit: 0 bytes in 0 blocks ==10632== total heap usage: 1 allocs, 1 frees, 20 bytes allocated ==10632== ==10632== All heap blocks were freed -- no leaks are possible ==10632== ==10632== For counts of detected and suppressed errors, rerun with: -v ==10632== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Yes Virginia, an allocation of 5 int requires 20 bytes of storage...
Both 15.0 and 15.1 Incorrectly Report:
$ valgrind ./bin/vgtest ==2015== Memcheck, a memory error detector ==2015== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2015== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2015== Command: ./bin/vgtest ==2015== 5 4 3 2 1 ==2015== ==2015== HEAP SUMMARY: ==2015== in use at exit: 0 bytes in 0 blocks ==2015== total heap usage: 2 allocs, 2 frees, 1,044 bytes allocated ==2015== ==2015== All heap blocks were freed -- no leaks are possible ==2015== ==2015== For counts of detected and suppressed errors, rerun with: -v ==2015== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Students, you can confirm and verify the corresponding allocation by checking with valgrind -- Wait... WTF? valgrind doesn't do that correctly anymore :(
Have you reported a bug yet? thats how the issue will get fixed. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/05/2019 06:53 PM, Simon Lees wrote:
Have you reported a bug yet? thats how the issue will get fixed.
Yes, https://bugs.kde.org/show_bug.cgi?id=392855 Nobody sees this dramatic departure from past behavior as a bug: Status: RESOLVED NOT A BUG and https://bugzilla.opensuse.org/show_bug.cgi?id=1092054 Can you see the difference in valgrind behavior? -- 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 Fri, Jul 05, 2019 at 10:46:23PM -0500, David C. Rankin wrote:
On 07/05/2019 06:53 PM, Simon Lees wrote:
Have you reported a bug yet? thats how the issue will get fixed.
Yes, https://bugs.kde.org/show_bug.cgi?id=392855
Nobody sees this dramatic departure from past behavior as a bug:
Status: RESOLVED NOT A BUG
and
https://bugzilla.opensuse.org/show_bug.cgi?id=1092054
Can you see the difference in valgrind behavior?
yes, but it might just mean that the underlying allocator changed, or there are some more mallocs happening due to the printf calls or similar? Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
On 07/05/2019 06:53 PM, Simon Lees wrote:
Have you reported a bug yet? thats how the issue will get fixed.
Yes, https://bugs.kde.org/show_bug.cgi?id=392855
Nobody sees this dramatic departure from past behavior as a bug:
Status: RESOLVED NOT A BUG
and
https://bugzilla.opensuse.org/show_bug.cgi?id=1092054
Can you see the difference in valgrind behavior?
I've read the longish kde report - I don't see any difference in valgrind's behaviour, it just reports what it sees? Are you saying valgrind would previously ignore or suppress allocations made by library calls? (possibly directed by some blacklist). The two devs don't seem to think valgrind ever had such functionality. Anyway, showing a regression should be straight forward - with the same code and the same libraries, run it with the old and the new valgrind ? -- Per Jessen, Zürich (21.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/06/2019 02:07 AM, Per Jessen wrote:
I've read the longish kde report - I don't see any difference in valgrind's behaviour, it just reports what it sees? Are you saying valgrind would previously ignore or suppress allocations made by library calls? (possibly directed by some blacklist). The two devs don't seem to think valgrind ever had such functionality.
Yes, exactly. Since time began for valgrind, up until the point I filed the bug reports, valgrind always shipped with proper exclusion files that masked the non-user allocations that take place behind the scene. There is no doubt that an allocator of something similar changed in later glibc, but the point is nobody at valgrind will take the time to prepare updated exclusion files to restore proper allocation tracking by valgrind. Simply compile the new code and pipe the output to capture it. valgrind now repots 4096 additional bytes allocated instead of just 1024 for printf I/O. It's really simple, look at the bytes reported below: Correct: ==10632== total heap usage: 1 allocs, 1 frees, 20 bytes allocated Incorrect: ==2015== total heap usage: 2 allocs, 2 frees, 1,044 bytes allocated How many user calls to malloc are present in: #include <stdio.h> #include <stdlib.h> #define NVAL 5 int main (void) { int *a = malloc (NVAL * sizeof *a); if (!a) { perror ("malloc"); return 1; } for (int i = 0; i < NVAL; i++) { a[i] = NVAL - i; printf (i ? " %d" : "%d", a[i]); } putchar ('\n'); free (a); } There is 1 allocation of 20 bytes that takes place, everything has always been, and should be, masked by proper exclusion files. But 15.0 on show a separate 1K allocation taking place that is not properly masked. This is a TRIVIAL example. In an actual real-world program it makes the number valgrind reports completely batshit worthless. There will be scores of invisible allocations reported and tens of thousands or hundreds of thousands of system allocations mixed in with the total making that number completely meaningless for any type of analysis of user allocation requirements. valgrind has always been dead on for Linux gcc with its exclusion files -- making valgrind a very useful tool in this regard. When it broke, the response is "Oh well....", which is bewildering to say the least. Why even report the number of allocs if it isn't the number the programmer has control over? And then why only report some system allocations and mask others? If what is reported is a dice-roll combination of what the programmer did and what the library did behind the scenes, it doesn't mean anything. -- 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
David C. Rankin wrote:
On 07/06/2019 02:07 AM, Per Jessen wrote:
I've read the longish kde report - I don't see any difference in valgrind's behaviour, it just reports what it sees? Are you saying valgrind would previously ignore or suppress allocations made by library calls? (possibly directed by some blacklist). The two devs don't seem to think valgrind ever had such functionality.
Yes, exactly. Since time began for valgrind, up until the point I filed the bug reports, valgrind always shipped with proper exclusion files that masked the non-user allocations that take place behind the scene.
Okay, understood.
It's really simple, look at the bytes reported below:
Oh, I understand the problem. I'm just thinking about how it might be solved with a (simple?) patch to those suppression files. On a memcheck, you can add your own with '--suppression='. ISTR valgrind will even help you produce those files.
In an actual real-world program it makes the number valgrind reports completely batshit worthless. There will be scores of invisible allocations reported and tens of thousands or hundreds of thousands of system allocations mixed in with the total making that number completely meaningless for any type of analysis of user allocation requirements.
That sounds like a bit of a stretch. I am assuming the standard set of suppression files are still in place, but need updating to suit the libraries ? -- Per Jessen, Zürich (18.7°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
In an actual real-world program it makes the number valgrind reports completely batshit worthless. There will be scores of invisible allocations reported and tens of thousands or hundreds of thousands of system allocations mixed in with the total making that number completely meaningless for any type of analysis of user allocation requirements.
That sounds like a bit of a stretch. I am assuming the standard set of suppression files are still in place, but need updating to suit the libraries ? Yes, I've tried producing my own exclusion files and it isn't that simple. Here is another example where I simply fill a ternary tree with data: 42.3 ==16882== total heap usage: 1,768,013 allocs, 1,768,013 frees, 56,984,713 bytes allocated 15.0 15.1 ==2161== total heap usage: 1,768,016 allocs, 1,768,016 frees, 56,990,857 bytes allocated Simply loading the words there is now 3 additional allocations and 6144 bytes unaccounted for. If you actually query data and output information, or write files, that number goes up dramatically. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
David C. Rankin wrote:
In an actual real-world program it makes the number valgrind reports completely batshit worthless. There will be scores of invisible allocations reported and tens of thousands or hundreds of thousands of system allocations mixed in with the total making that number completely meaningless for any type of analysis of user allocation requirements.
That sounds like a bit of a stretch. I am assuming the standard set of suppression files are still in place, but need updating to suit the libraries ?
Yes, I've tried producing my own exclusion files and it isn't that simple.
Yeah agree - I had a look at it too. Only a brief look, but my impression was only problems could be suppressed? What I'm not sure I quite understand - apparently a library call makes an extra allocation now, but is this so unusual? Surely plenty of library calls do that - getaddrinfo() for instance. Would you not want those listed by a valgrind memcheck? -- Per Jessen, Zürich (17.2°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/07/2019 12:16, David C. Rankin wrote:
On 07/06/2019 02:07 AM, Per Jessen wrote:
I've read the longish kde report - I don't see any difference in valgrind's behaviour, it just reports what it sees? Are you saying valgrind would previously ignore or suppress allocations made by library calls? (possibly directed by some blacklist). The two devs don't seem to think valgrind ever had such functionality.
Yes, exactly. Since time began for valgrind, up until the point I filed the bug reports, valgrind always shipped with proper exclusion files that masked the non-user allocations that take place behind the scene.
Then you are somewhat lucky, using it in the real world i've always had to write my own suppression for stuff in 3rd party libraries. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (18)
-
Anton Aylward -
Carlos E. R. -
Carlos E.R. -
David C. Rankin -
DennisG -
Felix Miata -
Hans-Peter Jansen -
Knurpht-openSUSE -
Marcus Meissner -
Matwey V. Kornilov -
Oleksii Vilchanskyi -
Patrick Shanahan -
Per Jessen -
Peter Suetterlin -
Simon Lees -
stakanov -
tooth pik -
Werner Flamme