Newest upgrade of Debian testing breaks Nvidia & Xorg

[sej7278]

Isn't it fixed yet?

I haven't do any update till now, there are several updates waiting, and whenever I mark to do the updates it prompts to remove nvidia-xlg and some relatives.

Is there something going to happen?

its pretty crazy its taking this long - i thought all they had to do was blacklist some part of it?

what i've been doing is using synaptic's gui and picking all the non-nvidia or X11 packages to be updated.

[roseway]

As far as I know, the problem is with nvidia-glx. If you uninstall this before running sgfxi, it ought to be OK. I've got the nVidia driver installed via sgfxi and the current problem hasn't touched me.

[h2]

You don't need to change to stable, that's silly.

If you see a complaint about a conflict, it means that sgfxi was unable to remove the nvidia dkms garbage, which is a bug in the dkms packaging. I can't have sgfxi purge dkms itself because other modules might also be under its control, sad to say, though I may have to add a feature that allows that if the user selects that choice, I'm not really sure how to handle these package breaks to be honest, to me, a debian package should be cleanly installable and cleanly removable, but that is simply not happening, and why, I cannot say.

The solution is to get rid of dkms, then everything will work fine.

I have no idea why the nvidia dkms packages are being allowed into the debian pool at this point,. because a simple: apt-get remove nvidia-current-dkms should remove the package, but it fails due to packaging errors and conflicts.

That's what sgfxi attempts to do, prior to driver install, but I can't track the various inconsistencies and packing errors that have long been a hallmark of those packaged drivers month to month, so I years ago permanently solved that problem by never using them. they are fine in stable pool releases, they are not fine in rolling releases. sgfxi tries to remove all nvidia/fglrx packages, and that removal should be clean and final, but something changed recently that makes dkms puke and die on removal, and then fail, which makes the nvidia package removal fail, which makes the direct nvidia installer run fail. There's very little I can do more than sgfxi already does to handle this, I suggest filing bug reports on the dkms package removal failure, I guess, but I suppose I could insert a user interactive option that would allow them to purge everything, including dkms, which tends to solve the problem.

Ubuntu has the same problem by the way, which suggests to me that the debian package is just the ubuntu package slightly reworked, and this problem just started appearing in the last few months, that's all I know for certain, something changed, for ubuntu users, the only solution is to purge dkms, then proceed, then everything is fine.

Remember, all the debian nvidia packages do is put a wrapper over the nvidia binary blob, there's nothing magical or special about them, and dkms from what I can see has been broken by design ever since its introduction, except for stable pools, which is what Dell originally coded it to handle. In other words, the packaged debian drivers add one layer of failure, and dkms adds another, and 3 layers of possible failure is in my opinion too many for my taste. Dkms itself is a huge mess, and doesn't even have simple clean ways to remove modules, that's why I avoid it always.

If there is some new procedure required now to remove nvidia dkms, please post the exact coded steps required so I can update sgfxi again to handle yet another dkms issue, why anything beyond dpkg --purge <nvidia packages> should be required however is totally incomprehensible, that's not how debian is supposed to work.

[julian516]

h2 says:

I years ago permanently solved that problem by never using them. they are fine in stable pool releases, they are not fine in rolling releases.

So should I infer that if we have nVidia graphics and we choose to run either wheezy or sid, that use of the nouveau driver is where we ought to be?

[shmerl]

There is no way out now, if you want accelerated OpenGL support with Nvidia hardware - you need their drivers. So having this mess is very unpleasant. For now I just do apt-get update && apt-get upgrade and nvidia relevant packages are shown as held back.

[h2]

Julian, no, you should not infer this. The only people having issues at this point with nvidia are dkms users of the packaged nvidia blobs. Nobody else is having these types of issues, nobody. The cause is the packaging, so just dump those packages and use the direct installer, which is what sgfxi defaults to. If you have to dump dkms to do that, then wave it goodbye and enjoy years of steady, consistent, working driver support. Or don't.

On my systems, I have never used this junk, and I have never had any issues. I also, by the way, use the direct download of virtualbox from oracle/sun, for the same exact reason, I do not want dkms on my system, in any shape or form, it's a contaminated, poorly written piece of software that leads to difficult to solve failures and issues, and has no clean clear/remove path beyond a blanket purging of it totally. The design, which I had the misfortune to actually try to code around, is essentially impossible to fix as far as I can tell, unless it's been majorly improved. Clearly the debian package maintainers for nvidia-dkms have been unable to find a clean uninstall route, and that does not surprise me at all, I also was unable to find one when doing extensive testing when I first saw that dkms monstrosity appear.

sgfxi defaults to a clean install of the direct package from nvidi (the same exact package that the deb is made out of), and does not default to using dkms etc.

The inference is odd to me, because my conclusion some 5 years ago was that using the debian packaged nvidia / fglrx drivers on testing/sid was a very bad idea.

Nothing has appeared to make me change this view, though I do re-examine it every year or so to make sure nothing has changed. As you can see from this and many other threads, nothing has changed.

Nobody is having issues with nvidia EXCEPT packaged nvidia dkms users. The obvious and clear conclusion is to dump those buggy methods and use the direct installer, which has ALWAYS been far more consistent and reliable. And also has the advantage of having only one bug source: the actual driver, which is constant across all methods.

I have never used dkms on a rolling release, nor will I ever use it, unless the package is totally reprogrammed. I have also, by the way, always had nothing but contempt for dell and it's products, so it was no surprise to me to experience the horrible design and programming of dkms ever since dell rushed it out the door.

It's simple: frozen pool, sticking to default kernels and drivers: dkms works as advertised, just fine. Leave the defaults, new kernel, new drivers, new vbox, failure instantly. This is not robust software, it's a crude hack that has apparently never been fixable, and appears to remain a hack which is just used out of desperation and lack of anything better. Direct install of modules is clear, clean, and reliable. That's why I use it and recommend that method on rolling release systems. No problems, no issues.

[h2]

I am firing up my venerable test box now however, updating debian testing, and I'm going to see what mess the dkms nvidia stuff actually creates in the system, and what happens on removal, I will maybe add an option to sgfxi to let you purge all the dkms garbage if you ok it, that I know works, because it's teh only way users have been able to free their system of a stuck/non removable nvidia dkms package.

[kevmitch]

h2 says:

I years ago permanently solved that problem by never using them. they are fine in stable pool releases, they are not fine in rolling releases.

So should I infer that if we have nVidia graphics and we choose to run either wheezy or sid, that use of the nouveau driver is where we ought to be?

While h2's comment has some truth, I would have to say yes to this. I wouldn't trust a private company operating outside the accepted kernel and xorg development cycle to keep up to date with it. At best they will be playing catchup to API changes. If they have anecdotally managed to do so to date, it is counterbalanced by the fact that a graphics driver is such a fundamental part of the system that sticking in a foreign blob is ill advised unless you are prepared to deal with X failing to start on any given upgrade. There is also the more general concern that the Nvidia driver consists of a undisclosed third party code running in the kernel which is the lowest, most privileged level possible.

It may well be that you are expert enough and concerned enough with graphics performance that this is an acceptable risk. But particularly if you try nouveau and don't notice any difference in performance (because most people don't even come close to maxing out their GPU in day to day use), I would say stick with it the open source driver.

[h2]

Oh, I was not talking about nouveau, which is another mess, but if nouveau is adequate for your needs, then that's fine.

However, your comment is not really that correct: with nouveau, you are trusting to a relatively tiny, underfunded group of admittedly clever but resource constrained hackers who are forced to reverse engineer every single card the driver works with.

Comparing that to the actual nvidia corporation's skill/resource level is... well, let's say that's blindly optimistic, among other things.

However, if the essential requirement is that the software you run be free, then of course, nouveau is the only way to go, but I do not believe this thread is about that question in general, it's about the non free driver as packaged via ubuntu/debian packages failing on debian testing.

While it's great to idealize the work of free software projects like nouveau, it's also useful to admit the limits they work under, and the vast challenges they face, given that the hardware specs are not open in the first place, and that writing video driver code is one of the most challenging and complex software issues in the world. So nouveau does well given those limits and challenges, but it usually fails, although it is getting better every year, and if it is enough for your needs, then it's a good choice. But it's not enough for most users of modern hardware at this point last I checked. Give the nvidia guys some credit, that group contains some great hackers, they are paid, they have full access to all core system data they need, they just have advantages nouveau will never have. It's the same for radeon, if ati/amd didn't pay the xorg radeon guys the drivers just wouldn't be happening, and those guys at least have specs to work off of, unlike nouveau, who have to suffer with reverse engineering everything. Give them credit for their efforts, but don't ignore the reality of inconsistent and barely working support for many card features, models, etc. Look at their todo list sometimes, they have a nice wiki, they aren't even remotely close to the level of the non free blob.

[h2]

Testing now: on Sid, I'm happy to report that sgfxi -d (using debian method and packages, but no explicit dkms) does NOT pull in dkms, which I thought it did.

-d runs the cleanup then installs according to debian wiki steps, so that's working in sid now. I'll have to do an install of Testing, I thought I had one, but I didn't, it's unusual for testing to have an issue but sid not to.

<update>
Found and fixed at least one place where sgfxi would have failed to properly purge debian nvidia packages, this may only affect aptitude users, I'm not sure, I should have tested apt-get too but forgot. I'll see how it goes.

<update 2>
Very happy to report that at least some issues with dkms removal appear to be fixed, from what I can see, appears to uninstall, which is a big improvement. So that's a plus, and an area I'm happy to be wrong about.

[kevmitch]

I assure you that I'm not being contrary for the sake of being contrary, but I've found dkms to be a definite step forward from having to reinstall/recompile out of tree kernel modules on each kernel upgrade. I would argue it is one of the reasons that recommends the debian packaged nvidia driver. I have definitely put it through its paces by compiling my own kernels with make-kpkg and by using sid, and has always worked as advertised when I install new kernels as well as when I upgrade the out-of-tree modules it manages. If it is found to fail in some circumstance, a bug report should be filed. It is not unfixable.

Just to be clear, the problem that started this thread is related to a change in the way the /lib and /usr/lib directories are structured to better accommodate multi-architecture systems (e.g., i386/amd64) and not a failing of dkms.

[sej7278]

I assure you that I'm not being contrary for the sake of being contrary, but I've found dkms to be a definite step forward from having to reinstall/recompile out of tree kernel modules on each kernel upgrade. I would argue it is one of the reasons that recommends the debian packaged nvidia driver. I have definitely put it through its paces by compiling my own kernels with make-kpkg and by using sid, and has always worked as advertised when I install new kernels as well as when I upgrade the out-of-tree modules it manages. If it is found to fail in some circumstance, a bug report should be filed. It is not unfixable.

Just to be clear, the problem that started this thread is related to a change in the way the /lib and /usr/lib directories are structured to better accommodate multi-architecture systems (e.g., i386/amd64) and not a failing of dkms.

agree completely - dkms is a useful system and the nvidia issue is down to multi-arch problems not dkms packaging.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630710

i'm more worried that nothing seems to have been done about the bug in the last 3 weeks - or is it all happening in sid offlist?

[h2]

Since one of my main problems with dkms, the failure to do clean remove/installs seems to finally have been resolved, that can finally be marked as fixed in debian, though drivers breaking on xorg/kernel updates of course will remain an issue when things aren't all matching and synced, but that's not an issue that worries me, since I don't use the stuff at all.

Here's a, finally (many installer bugs and failures later), debian testing, fresh install. This is via sgfxi, default, binary run file / download, cleanup, install:

Code: Select all

inxi -bx
System:    Host: deb-32-test-nv Kernel: 2.6.39-2-686-pae i686 (32 bit, gcc: 4.4.6) 
           Desktop KDE 4.6.4 (Qt 4.7.3) Distro: Debian GNU/Linux wheezy/sid
Machine:   System: HP Pavilion 061 product: RJ181AA-ABA a1600n version: 0nx1114RE101NODM300
           Mobo: ASUSTek model: NODUSM3 version: 1.05 Bios: Phoenix version: 3.06 date: 07/14/2006
CPU:       Dual core AMD Athlon 64 X2 3800+ (-MCP-) clocked at 2000.00 MHz 
Graphics:  Card-1: nVidia C51 [GeForce 6150 LE] bus-ID: 00:05.0 
           Card-2: ATI RV710 [Radeon HD 4350] bus-ID: 02:00.0 
           X.Org: 1.10.2.902 driver: nvidia Resolution: 1280x1024@50.0hz 
           GLX Renderer: GeForce 6150 LE/PCI/SSE2/3DNOW! GLX Version: 2.1.2 NVIDIA 275.09.07 Direct Rendering: Yes
Network:   Card: nVidia MCP51 Ethernet Controller driver: forcedeth port: c800 bus-ID: 00:14.0
Drives:    HDD Total Size: 122.9GB (1.9% used)
Info:      Processes: 111 Uptime: 2 min Memory: 331.1/945.3MB Runlevel: 3 Gcc sys: 4.6.1 Client: Shell inxi: 1.7.15-1 

Now to test the debian way to confirm cleanup and reinstall issues are also fixed.

<update>
and that's a confirmed full fail for the debian packaged nvidia. So there's no problem at all with the actual nvidia driver, it's a packaging issue. That's the norm in my experience too, so nothing in this area has changed. dkms however I'm very glad to see has finally grown into a somewhat usable package, and now follows standard and predictable debian package behaviors, which I'm glad to see. Big improvement.

<update>
Just to see, tried the new beta: sgfxi -B

Code: Select all

inxi -Gx
Graphics:  Card-1: nVidia C51 [GeForce 6150 LE] bus-ID: 00:05.0 
           Card-2: ATI RV710 [Radeon HD 4350] bus-ID: 02:00.0 
           X.Org: 1.10.2.902 driver: nvidia Resolution: 1280x1024@50.0hz 
           GLX Renderer: GeForce 6150 LE/PCI/SSE2/3DNOW! GLX Version: 2.1.2 NVIDIA 280.04 Direct Rendering: Yes

there's a kde desktops effects bug but otherwise works, but that's a beta issue, not related to anything else.

Useful thread, may have finally found and fixed a lingering install issue that's tormented users for a while now for nvidia, so that was good to maybe get fixed. Seems to do a clean install/uninstall no matter what now, whew.

<update>
and to be fair, a quick test of nouveau: sgfxi -N nouveau
(removes all non free stuff, removes nomodeset in grub, then installs/updates xorg/nouveau)

Code: Select all

inxi -Gx
Graphics:  Card-1: nVidia C51 [GeForce 6150 LE] bus-ID: 00:05.0 
           Card-2: ATI RV710 [Radeon HD 4350] bus-ID: 02:00.0 
           X.Org: 1.10.2.902 driver: nouveau Resolution: 1280x1024@60.0hz 
           GLX Renderer: Rasterizer GLX Version: 2.1 Mesa 7.10.3 Direct Rendering: Yes

notice that this is an older card, but not too old, which is probably your best bet if you're going to run nouveau happily. Very very slow glxgears, but it does work more or less.

[julian516]

Well, here is where one user is at.

With Debian I use smxi/sgfxi to manage updates and upgrades. If I need to re-install nVidia drivers after a kernel upgrade I do that. I do not fool with my system if h2 posts warnings. So most recently when warnings were removed I did upgrade & re-installed the newest nVidia driver and went away happy. I run Debian because its management tools seem superior to others; dpkg/apt work and work well. Add the smxi/sgfxi scripts and for me, at least, that is about as good as it gets in Linux. Suffice it to say I have a great respect for the people who produce the tools on which I rely.

Over on my Arch system I am running the nouveau driver, which seems adequate for what I do there. (Good system but not a Debian replacement.) But bear in mind I am not playing games, watching moves, or doing things that otherwise make great demands on the video system of this 15 inch laptop. I have a hunch that if I did I would quickly discover the limits of the nouveau driver. So long as it works I'll let it do what it does.

[Eck]

I think the reason that bug discussion isn't offering continuing details is because the packaging that fixes the multi-lib linking problem has been making its way through getting into testing. From what I see it should enter tomorrow if no sudden critical bug appears.

So as of tomorrow whenever the new packages are released into testing and the repos are synched, wheezy users should be able to install the nvidia stuff direct from the wheezy repos without a problem.

Since I use Squeeze and aren't sure how those new packages will interact with the old style lib64 linking, I jumped the gun a bit when the new Nvidia driver, 275.19, came out from nvidia.com the other day. I purged all the debian nvidia, cuda, etc, etc, stuff and installed the nvidia blob.

Maybe that's how stable users should do it at this point if we need a newer driver than the one in Squeeze. The creation of an /etc/modprobe.d/disable-nouveau.conf with the contents:

blacklist nouveau
options nouveau modeset=0

solves the nouveau interaction problems with the installer running as per the Nvidia readme. The debian package nvidia-kernel-common does similar and so with that removed I went and created that file myself so I wouldn't have to reboot after the nvidia-installer did it to get the driver to install.

For those that run the nvidia download, the splash screen will say it's a beta driver but it's not. It just got released with that in there by mistake.

[g1annos]

Everything fixed. I did the upgrade without braking the system.

[shmerl]

Yes, fixed at last.

[PAP]

I usually go the easy way, installing nvidia-kernel-dkms and let it install its dependencies. I can confirm it works again. Not sure if the problem is fixed due to the recent (3 days ago, I think) kernel or xorg upgrade, but it works as expected now. Also, a small bug that used to leave artifacts on the screen when maximizing a window vertically is fixed as well.

[odinbaal]

Upgrade worked fine here.

Back to Wheezy (from a remastered dvd) after three weeks with Squeeze.

The question is how do we avoid this recurring in the future? The bug/whatever stopped my productivity for quite some time, and going back to Stable whenever this happens is, to say the least, problematic.

[shmerl]

That's what rolling slice was proposed for, which will be standing between stable and testing, closer to testing, but avoiding this kind of inconsistencies. I.e. it's supposed to be aimed for common / non tech savvy users, who don't want or can't research arcane methods of updating testing, to avoid such breakdowns, and on the other hand prefer newer and more up to date packages in contrast with stable. But I have no idea what state that proposal is, and how things are progressing. Anyone has an idea?