|
nvidia 295.40 on older cards: possible problems
I came across this, if you have an older nvidia card, pre G80 series, like 8800, or earlier model, read this: nvidia driver problems
New cards, g200 etc, are fine, no problems. But if you have experienced crashes or corruptions and you use an older (but newer than the gforce5xxx series) then consider rolling back your dirver until nvidia releases a fixed driver, which should be quite soon. You can roll back easily by: sgfxi -o 295.33 then just wait for the next fixed nvidia driver and update when it comes out. To see currently supported drivers in sgfxi, do: sgfxi -Ld Back to top |
|
The method above uses nvidia way, if I understood correctly? Is there a way to use debian-nvidia method, while holding off the driver packages from the update?
(I asked the question in detail here: forums.debian.net/viewtopic.php?f=6&t=78532 ). Back to top |
|
In general this type of scenario is why I personally do not use the debian way.
However, if you do, and if 295.40 is not the testing driver, and if you run sid, then you simply put the driver package on hold and wait until the new nvidia driver is in the debian package. Same as any other package you want to hold and not update. Back to top |
|
I'm using Debian testing (and 295.40-1 just hit the testing repo, thus my concern to update to it). So using hold on the nvidia related packages will work well with smxi/sgfxi? (Since hold is removed when something calls apt-get install, and apparently smxi removes Nvidia packages first and reinstalls them).
However I'm leaning to what you said - just to use the Nvidia way, at least until this issue is resolved. Back to top |
|
smxi won't install a held package. It also has an option to set user holds in the smxi config file, that way those get held/unheld during each smxi upgrade, that is, they get put on hold prior to the upgrade, and get taken off hold post upgrade.
this helps avoid forgetting to remove something from hold, but of course is only useful if you only upgrade with smxi. Allowing 295.40 into testing this quickly is why I don't use the debian way, when nvidia notes a core bug that will be fixed in a later release, it's not that wise to move something into testing. although this bug was caused by a fix to the driver for some security issue, but you'd be amazed how hard many security holes are to actually exploit, usually they require direct access to the computer, and as I'm fond of noting, if someone has direct access to your computer, you have bigger security problems than a theoretical local exploit... Back to top |
|
Holding nvidia packages and running the upgrade with smxi failed, since it couldn't remove them.
By the way, can one install ia32 nvidia drivers for 64 bit Debian with sgfxi? Back to top |
|
I am unclear what you are talking about here, did you for some reason install the nvidia driver via smxi again? why would you have done this?
When you hold the driver, it's held. smxi doesn't remove it, and doesn't try to upgrade it, unless there is an xorg dependency or something, I can't tell you. It sounds to me like you ran the upgrade with the nvidia debian packages held, then you for some odd reason ran sgfxi at the end, via smxi. At least that's the only thing I can think of, you'll have to try being a lot more descriptive of what you are seeing here if you want help. I seem to remember that there is an ia32libs install option at the end of sgfxi, but I don't know if it's active. sgfxi was also recently updated to not remove ia32libs if detected since it is not a dependency of anything related to nvidia. Back to top |
|
These are packages which I put on hold:
:: Code :: libgl1-nvidia-alternatives hold
libgl1-nvidia-alternatives-ia32 hold libgl1-nvidia-glx:amd64 hold libgl1-nvidia-glx-ia32 hold libglx-nvidia-alternatives hold nvidia-alternative hold nvidia-glx hold nvidia-kernel-dkms hold nvidia-kernel-source hold nvidia-settings hold nvidia-vdpau-driver:amd64 hold xserver-xorg-video-nvidia hold I run smxi, let it finish dist-upgrade, got to option "continue to graphics". At that point sgfxi is executed if I understand correctly, and I chose debian-nvidia option. And that's what happens (from /var/log/sgfxi/sgfxi.log): :: Code :: ...
Function: list_installed_packages - Utility: Start Args: nvidia (libgl1-nvidia-glx-ia32|modalias|libvdpau|nvidia-bl-dkms|nvidia-cg-toolkit) packageList: glx-alternative-nvidia libgl1-nvidia-alternatives libgl1-nvidia-alternatives-ia32 libgl1-nvidia-glx:amd64 libglx-nvidia-alternatives nvidia-alternative nvidia-glx nvidia-installer-cleanup nvidia-kernel-3.2.0-2-amd64 nvidia-kernel-common nvidia-kernel-dkms nvidia-kernel-source nvidia-settings nvidia-support nvidia-vdpau-driver:amd64 xserver-xorg-video-nvidia Function: list_installed_packages - Utility: End Function: list_installed_packages - Utility: Start Args: (glx-alternative-mesa|glx-diversions) packageList: glx-alternative-mesa glx-diversions Function: list_installed_packages - Utility: End Function: remove_package - Utility: Start Args: glx-alternative-nvidia libgl1-nvidia-alternatives libgl1-nvidia-alternatives-ia32 libgl1-nvidia-glx:amd64 libglx-nvidia-alternatives nvidia-alternative nvidia-glx nvidia-installer-cleanup nvidia-kernel-3.2.0-2-amd64 nvidia-kernel-common nvidia-kernel-dkms nvidia-kernel-source nvidia-settings nvidia-support nvidia-vdpau-driver:amd64 xserver-xorg-video-nvidia glx-alternative-mesa glx-diversions no-loop yes ERROR: (190) Removing package glx-alternative-nvidia libgl1-nvidia-alternatives libgl1-nvidia-alternatives-ia32 libgl1-nvidia-glx:amd64 libglx-nvidia-alternatives nvidia-alternative nvidia-glx nvidia-installer-cleanup nvidia-kernel-3.2.0-2-amd64 nvidia-kernel-common nvidia-kernel-dkms nvidia-kernel-source nvidia-settings nvidia-support nvidia-vdpau-driver:amd64 xserver-xorg-video-nvidia glx-alternative-mesa glx-diversions failed. May be I misunderstood the advised approach when some packages are held. Back to top |
|
Why on earth are you trying to reinstall debian nvidia after putting debian nvidia on hold? That makes no sense at all. Sgfxi/smxi, poor fellows are only trying to do what you tell them to do.
If you have held debian nvidia of course you are not going to reinstall them, that defeats the entire purpose of putting them on hold in the first place. When you are done with the upgrade, you're done, installing the video driver the debian method via sgfxi cleans out all nvidia and installs it, as you requested. You only install the debian method one time, why you are trying to reinstall it at all is beyond me, but don't do that, you're not clear on the concept here, you reinstall the NON debian method if xorg got overwirtten, which smxi will tell you happened during the upgrade, but in no case do you ever need to reinstall the debian method drivers, that's the entire purpose of using thm. I'll mark this case closed. Back to top |
|
May be I misunderstood the process of installation. It doesn't just install binary packages, it does some internal work with building the module from source, using the kernel sources and etc. So I expected that if kernel changes, it's good to rebuild the driver, even if you keep the same version.
Back to top |
|
All times are GMT - 8 Hours |