installing NVIDIA non-free binary package requires manual configuration

Bug #32853 reported by Jonathon Conte on 2006-02-25
Affects Status Importance Assigned to Milestone
linux-restricted-modules-2.6.15 (Ubuntu)
linux-restricted-modules-2.6.17 (Ubuntu)
linux-restricted-modules-2.6.19 (Ubuntu)
linux-restricted-modules-2.6.20 (Ubuntu)

Bug Description

I'm running Dapper Drake testing (Flight 4 + updates). When installing the proprietary nvidia-glx package, apt fails to completely integrate the nvidia driver with the rest of the system and much manual configuration is left to the user. Xorg.conf must be tweaked by hand and there is no menu item for the nvidia-settings program that is included with the nvidia-glx package. I propose that the nvidia-glx package is adapted to automate this process. xorg.conf should be altered automatically and a desktop file should be included for the nvidia-settings program so that it appears under System-->Preferences.

The following alterations to xorg.conf are required (per NVIDIA's website) in order to use the driver: The device driver must be changed to "nvidia", both the "dri" and "GLCore" modules must be disabled and the "glx" module should be enabled.

It also might be a good idea to automatically disable the NVIDIA logo via the "NoLogo" option to smooth the visual transition from usplash to gdm but this is by no means mandatory.

I suspect that the nvidia-glx-legacy package is also affected by this bug. If that is indeed the case, it would also require the same patches to be applied to it.

Sitsofe Wheeler (sitsofe) wrote :

As an nvidia-glx-legacy user please don't do this. The non-legacy nvidia binary package is installed by default so if things were defaulted to the nvidia binary driver X would (by default) appear broken to me. Also software suspend is horribly broken with the binary drivers for me and further, nvidia have yet to release patches to make it work in 2.6.16 kernels (see )

At least under the current system people quickly know if the binary driver is going to be problematic because they have to enable it by hand.

Jonathon Conte (thesicktwist) wrote :

If that is in fact the case then perhaps the nvidia binary driver should not be installed by default. However, I was under the impression that it had to be installed explicitly.

In any case, I am not advocating that the proprietary driver should be part of the default ubuntu-desktop installation. My criticism is that when a user installs the nvidia-glx package, it is left in a somewhat unconfigured state unlike the many other packages in the repositories that are cleanly installed and removed.

Xavier Claessens (zdra) wrote :

I totaly agree with Jonathon. It was discuted in the ML [1]. The best solution was to add a debconf key which ask the user if he want to "activate" to driver. The default should be "yes" and the priority should be high. like that normal users will have the driver enabled by default without any question, and power-users can still disable the driver easily.

To enable the driver, just run on the postinst of nvidia-glx a command like «nvidia-glx-config enable».

Many other configs can be added to debconf keys and applied using «nvidia-xconfig» command.

As mentioned in the thread [1] this is not the ideal solution, X should automaticaly select the right driver when starting, without any configuration, but I think that's the long-term solution. We really need a simple workaround in time for dapper !


By the way guys, the NVIDIA commercial driver is everything but a binary package. IF and only IF you take the time to extract their installer archive (and they do provide a convenient command-line switch to do that), you will notice that their whole driver is distributed as source code so that it can adapt to every kind of configuration without NVIDIA having to release millions of different module versions.

Sitsofe Wheeler (sitsofe) wrote :

> you will notice that their whole driver is distributed as source code


I'm being pedantic but it is a binary package with a bit of glue source to let the kernel try and call various functions in the binary object. If the whole thing is distributed as source, where on earth is the source to nv-kernel.o ? What about the source for the distributed libraries* and so forth? What do all the different Xid messages mean? If you don't distribute all the source then you are anything but a source package.

That isn't to say this doesn't allow support for a wider range of kernels than a pure binary distribution - it does. However let's say the upstream kernel changes its support for how supsend to ram works. The only thing you can do now is change the glue source hooks to disable suspend to ram until NVIDIA release a new binary driver with the required support.

Currently, glue kernel source and a binary lump are about the only way to feasibly distribute binary drivers which have to run on more than one distro. This is the minimum that could be done.

Xavier Claessens (zdra) wrote :

The problem isn't if the driver is open source or not. The problem is that now an ubuntu user with a NVIDIA card has to manually run a command-line to activate the driver after his installation. I personnaly thinks it's unacceptable. The fix (workaround) is easy and can make the live of dapper's users easier.

Please considere to run the command « nvidia-glx-config enable » at the end of postinst !

Marco Cimmino (cimmo) wrote :

Hope to see in the next release of the package!

Added link in

julian (0x4d4a) wrote :

look at the livna fedora RPMs to see how this can be solved ideally (for the user):

"The Livna Nvidia and ATI driver RPMS come with a small python script, which works as an extension to system-config-xfree86. It does all the editing of the Xorg configuration file for you while installing/activating the driver.
Also, you do not need to drop out of X to perform the installation. And if you boot a kernel without Nvidia support, a boot script will automatically detect that the Nvidia kernel module is missing and revert to Xorg configuration."

julian (0x4d4a) wrote :

so what? i just said that this is how it is supposed to work for the end user (no manual configuration needed)

i understand that the livna method can't be copied 1:1 due to distribution differences, but i think it's worth a look

btw, the problem you mention is already fixed:

Xavier Claessens (zdra) wrote :

Is it so hard to add «nvidia-glx-config enable» in the postinst of nvidia-glx package ?!? I *really* don't understand why it's still not done. If there are some technical problem please tell me, otherwise please just add this command and close this bug.


Users of ATI video card has the same problem - installing ATI xorg-driver-fglrx drivers package requires manual configuration too :( xorg-driver-fglrx package contains fireglcontrolpanel configuration utility, but there are no menu launcher for this :(

I think same activation method - a debconf key, which ask the user if he want to "activate" to driver, should be used for xorg-driver-fglrx package too. Only command will be different:
aticonfig --initial

Should I report separate bug against xorg-driver-fglrx package ?

Btw, some time ago I've made initial script for automatic installation of video-drivers (currently supports new NVIDIA and ATI Radeon drivers), look at

I think this script could be extended to work with nvidia-legacy and other video drivers, which requires manual installing of driver packages and manual configuration.

Changed in linux-restricted-modules-2.6.19:
status: Unconfirmed → Rejected
Sitsofe Wheeler (sitsofe) wrote :

Is this somewhat mitigated by restricted-manager in Feisty?

zeddock (zeddock) wrote :

No mitigation if R-M isn't handling firmware correctly.


Sitsofe Wheeler (sitsofe) wrote :

To the best of my knowledge there is no firmware for the NVIDIA binary drivers (when you say firmware I assume small pieces of code that have to uploaded into the a given device before that device will function at all. An example of this is the firmware for Intel wireless cards that needs to be uploaded to the device before the driver can use the device).

So sorry!
I have two ONGOING problems in the linux/Ubuntu world... The nVidia Driver
for the 4200 and the bcm43xx firmware for the integrated wireless module. I
was confusing the two, driver versus firmware. Everything else is the same.

For instance,
R-M does not handle the nVidia driver (1.936??) correctly. So my statement
is still valid in that R-M would mitigate the real problem if it worked to
properly install the correct driver and configure xorg.conf to use it. But
it doesn't, so there is no mitigation through R-M.

Again, sorry for the mixup in my terms.

On 9/12/07, Sitsofe Wheeler <email address hidden> wrote:
> zeddock:
> To the best of my knowledge there is no firmware for the NVIDIA binary
> drivers (when you say firmware I assume small pieces of code that have to
> uploaded into the a given device before that device will function at all. An
> example of this is the firmware for Intel wireless cards that needs to be
> uploaded to the device before the driver can use the device).
> --
> installing NVIDIA non-free binary package requires manual configuration
> You received this bug notification because you are a direct subscriber
> of the bug.

zeddock (zeddock) wrote :

I am happy that it seems BOTH of my issues have been fixed in the latest Gusty.


Marco Cimmino (cimmo) wrote :

zeddock please don't talk about OT things like wireless in this bug, please keep on topic.

This bug is fixed? Does Gutsy install correctly drivers and change xorg.conf at the same time?

Xavier Claessens (zdra) wrote :

This bug is fixed, yes !!! \o/

Timo Aaltonen (tjaalton) wrote :

Marking older components as "won't fix", since there are no plans to update the l-r-m packages for them.

As reported, this should work just fine on gutsy.

Changed in linux-restricted-modules-2.6.17:
status: New → Won't Fix
Changed in linux-restricted-modules-2.6.15:
status: New → Won't Fix
Changed in linux-restricted-modules-2.6.20:
status: New → Fix Released
Przemek K. (azrael) on 2009-12-17
Changed in baltix:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers