[nvidia-glx-new] Driver is missing libwfb breaking X on 8000 series cards

Bug #98641 reported by Matthew T. Russotto on 2007-03-29
Affects Status Importance Assigned to Milestone
linux-restricted-modules-2.6.20 (Ubuntu)
linux-restricted-modules-2.6.22 (Ubuntu)

Bug Description

The 9755 nvidia driver includes a new file called libnvidia-wfb.so.1.0.9755 and two symbolic links to that file, libnvidia-wfb.so.1 and libwfb.so.1. These files are not included in the linux-restricted-modules package.

I'm having this problem too.

Confirming. Another user in another bug report also reported the same.

Changed in linux-restricted-modules-2.6.20:
status: Unconfirmed → Confirmed
Niels Abspoel (aboe) wrote :

confirming this bug too...was doing some tweaking to Xorg.conf,
and read /var/log/Xorg.0.log and found wfb not found error
searched for these files and couldn't locate them

For now, this worked for me:
Download the nVidia drivers from here: http://www.nvidia.com/object/linux_display_ia32_1.0-9755.html
Extract the drivers with the -x switch: sudo sh NVIDIA-Linux-x86-1.0-9755-pkg1.run -x
Copy the module somewhere (hopefully to be removed when they start including it in the package). I used my home directory: cp NVIDIA-Linux-x86-1.0-9755-pkg1/usr/X11R6/lib/modules/libnvidia-wfb.so.1.0.9755 ~/
Now create a link to it from /usr/lib/xorg/modules/: sudo ln /home/aaroncampbell/libnvidia-wfb.so.1.0.9755 /usr/lib/xorg/modules/libwfb.so
That should do it. I also chown'd it to root:root, and chmod'd it to match all the other stuff in that directory.

Hope this helps someone. Once I did that, everything started to work fine. My dual screens, even Beryl runs smoothly (well, as smoothly as Beryl can run).

kry10 (launchpad-marklinford) wrote :

Also confirming this bug. FWIW, this bug doesn't occure when I boot from the previous kernel (2.6.20-13-generic), only from the "latest" (2.6.20-14-generic)

bacon (robert-unicraft) wrote :

I've got the exact same problem as described above. I installed the latest build from 5'th. Got a nvidia 8800 GTS 320Mb. Did just like the other fella above - extracted the drivers package from nvidia and linked it in. Now i works flawless.. Obviously a BUG.


ive got this, please fix

oddaolse (oddaolse) wrote :

The workaround did not work for me. Please let me know if I should provide more information to the persons who get to correct this bug.

heckheck (jinfo) wrote :

Just another note, I had had 9755 working on my system, with a custom built kernel, but lost it with a set of upgrades today. I was doing some cleanup and removed some old built kernels at the same time. Between that and changing from the nvidia-glx package to the nvidia-glx-new package, the needed file must have disappeared from my system.

Can someone confirm exactly which package this driver is "supposed" to live in. Does it get built as part of the nvidia-new-kernel-source package if you are building the kernel and modules, or is it in the nvidia-glx-new package or some other package? I just spent a few hours combing through the packages from my cache that got removed and couldn't find it anywhere, but it must have been on my system, since I had that exact version of the driver (9755) running this morning.

The workaround did not work for me, since I am on an AMD64 platform, and the pre-built driver from the NVIDIA website is a 32 bit version.

heckheck (jinfo) wrote :

Adding another note. I have found that for some reason, on my system, the missing wfb driver causes X to not start with my custom kernel and compiled nvidia-kernel-source module, while X will start with the generic 2.6.20-14 kernel and the nvidia module from the linux-restricted-modules package (though the Xorg.log file still complains that the wfb driver is not found).

Something definitely changed with nvidia-glx-new and/or the linux-restricted-modules package that cause a compiled version of the nvidia 9755 driver compiled from nvidia-linux-source with a custom kernel to stop working. I can tell that it is probably not the kernel module source, since I still have a compiled kernel and module that _was_ working prior to my upgrade of these modules that no longer works.

The real fix is obviously to get the wfb library included, but I wanted to point out that anyone who needs to build a custom kernel and has to use the nvidia-kernel-source package to build a module (e.g. typical Mythtv usage with LIRC support and NVIDIA card - very popular) will have a more serious problem than those using the generic kernel and the linux-restricted-module (which seems for the moment to work).

I will attach the Xorg logs showing the generic kernel boot that works and the custom kernel boot that doesn't.

heckheck (jinfo) wrote :

Log of successful X start with generic kernel and linux-restricted-modules nvidia drivers

heckheck (jinfo) wrote :

Log of failing X start with custom kernel and module compiled from nvidia-kernel-source.

Zi Gao (zimgao) wrote :


From your logs, nvidia kernel module failed at loading is not due to libwfb. If you have nvidia-glx-new installed, then "modprobe nvidia" will redirect to the nvidia_new module. Now, if you have a custom kernel, then nvidia-new-kernel-source will both give you nvidia module, not nvidia_new.

To get around that, goto /lib/modules/ and rename nvidia.ko to nvidia_new.ko. You would probably need to do a "depmod -a" afterwards.

Amazing Iceman (iceman-arenas) wrote :

Having an invalid evdev configuration in xorg.conf could also cause this error.
It did in my case, when I was struggling to get my G15 Logitech Keyboard to work under Feisty.

heckheck (jinfo) wrote :


Thanks! You were correct, the nvidia driver was not getting loaded due to its name. I am compiling a custom kernel using the nvidia-new-kernel-source package along with the linux-source-2.6.20 package. It appears as you suggest that nvidia-glx-new causes the modprobe to look for nvidia_new.ko as the module. By changing the name of my compiled kernel module in


I am able to start X properly. I guess this should be a separate bug on the nvidia-new-kernel-source package. I will look for one when I get a chance and if it doesn't exist create one.

xoco (arthur.ivanov) wrote :

same problem ...

but description for this bug - wrong

linux-restricted-modules-2.6.20 (Ubuntu) - contain 2 kernel modules : nvidia.ko and nvidia_new.ko

when you install nvidia-glx-new, nvidia_new.ko will be loaded..

kernel module successfully loaded when system is loading, but when X trying to start ... nvidia-glx Xorg driver can't find libwfb driver.

nvidia drivers have 2 part: one for Kernel and one for Xorg Server.

workaround: get file http://www.nvidia.com/object/linux_display_ia32_1.0-9755.html, extract wfb lib.

xoco (arthur.ivanov) wrote :

change description of this bug .. linux-restricted-modules-2.6.20 is not affected.
nvidia-glx-new (1.0.9755+ - affected

take a look -> http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=nvidia-glx-new&version=feisty&arch=i386
this package must contain

usr/lib/xorg/modules/libwfb.so --> sm link to libnvidia-wfb.so.1.0.9755

Nvidia 8800 GTX
fresh install of ubuntu feisty.

i386 Fix:

wget http://us.download.nvidia.com/XFree86/Linux-x86/1.0-9755/NVIDIA-Linux-x86-1.0-9755-pkg1.run
sh NVIDIA-Linux-x86-1.0-9755-pkg1 -x
sudo cp -f NVIDIA-Linux-x86-1.0-9755-pkg1/usr/X11R6/lib/modules/libnvidia-wfb.so.1.0.9755 /usr/lib/xorg/modules/libwfb.so

Daniel Llewellyn (diddledan) wrote :

Coming from Bug #103050, I can confirm that the proposed workaround here works also (for my situation) on the amd64 platform (provided you download the correct package from their site of course).

Please, try Envy 0.9.2-0ubuntu3 from this page:

This Envy Update fix all Problems with GeForce 8800 Series under Ubuntu!!! :-)))

Sitsofe Wheeler (sitsofe) wrote :

I would just like to add a note to the previous comment. Envy (and other 3rd party helper) installed packages can cause upgrades to later versions of Ubuntu to fail (see Bug #107915 ). Also any nvidia problems that occur after envy (or 3rd party helpers) is installed should not be reported here but instead reported to the envy (or 3rd party helpers) developers.

Alberto Milone (albertomilone) wrote :

Sitsofe Wheeler:
you're right.

However in this case the problem affects both Ubuntu (feisty) and Debian's (experimental) packaging scripts.

Alberto Milone (albertomilone) wrote :

I think I know how to fix the problem in Feisty's nvidia-glx-new packaging scripts.

Shall I provide you with a patch or upload the entire source package to my webspace?

Alberto Milone (albertomilone) wrote :

I have solved the problem and built nvidia-glx with pbuilder.

Can anyone try it and tell me if it solves the problem, please?

here are the instructions:

1) download this file by typing:
wget http://albertomilone.com/ubuntu/nvidia/nvidia-glx-new_1.0.9755+

2) type:
sudo apt-get --purge remove nvidia-glx-new

3) install the package you downloaded (only for Feisty 32 bit, sorry)

4) log out and press CTRL+ALT+Backspace

5) post your /var/log/Xorg.0.log

Alberto Milone (albertomilone) wrote :

Here is the solution to the bug and the source code.

First of all, the libnvidia-wfb.so.1.0.9755, available only in the latest driver 9755 (in the nvidia-glx-new package) was being not copied by the packaging scripts to /usr/lib/xorg/modules/ therefore I added the following lines at line 964 of the debian/rules :

  if [ "$$this_ver" = "$(nv_new_version)" ]; then \
   install $$this_dir/usr/X11R6/lib/modules/libnvidia-wfb.so.$$this_ver \
    $(CURDIR)/debian/nvidia-glx$${nv_flav}/usr/lib/xorg/modules/; \

If the driver is the latest version then the file is copied, otherwise nothing will happen (as other versions do not have the wfb module).

Another important step was that to make the packaging script create a symlink to modules/libnvidia-wfb.so.$$this_ver (e.g. libnvidia-wfb.so.1.0.9755) named libwfb.so in /usr/lib/xorg/modules/ . Therefore I edited both the debian/nvidia-glx.links.in and the debian/nvidia-glx.links.amd64.in adding only the following line:

usr/lib/xorg/modules/libnvidia-wfb.so.@@VERSION@@ usr/lib/xorg/modules/libwfb.so

And that's all. Now the users of Geforce 8800 will be able to use the nvdia driver.

Here you will find the entire source code made with pbuilder.

You will only have to edit the debian/changelog and bump the version of the linux-restricted-modules package.



Alberto Milone

Sitsofe Wheeler (sitsofe) wrote :

Thanks for the work Alberto.

This has also been reported (and assigned) in Bug #103050 ...

Alberto Milone (albertomilone) wrote :

Sitsofe Wheeler:
I have copied this solution to the other bugreport.

frenzie (frenzie) wrote :

I successfully follow Alberto Milone's instructions above and got my 8800 GTS running.
However, now when i try and run "desktop effects", i get the following error:

"the composite extension is not available"

Has anyone experienced the same thing?

frenzie (frenzie) wrote :

Oh and update manager wants me to update nvidia-glx-new, have to deselect.

Alberto Milone (albertomilone) wrote :

Can you attach your /etc/X11/xorg.conf ?

frenzie (frenzie) wrote :

unfortunately i cant find if i can delete opmments here....

ive updated the xorg.conf to enable composite and all is well

i still am getting the update manager pestering me, but ill live with that until the package is updated

Download full text (4.1 KiB)


I'm on Ubuntu Feisty AMD64 with a VideoCard Nvidia 7300 GS and i experiment this bug ...

My Linux Kernerl is 2.6.20-15-generic and i can't find any folder called nvidia in /lib/modules/2.6.20-15-generic but i installed via synaptic nvidia-glx and nvidia-glx-nzw ... same problem

Someone can help me ???

I've another problem ... Xorg.conf is wrong ...; can't boot ...

here's my xorg.conf:

# /etc/X11/xorg.conf (xorg X Window System server configuration file)
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
# Edit this file with caution, and see the xorg.conf(5) manual page.
# (Type "man xorg.conf" at the shell prompt.)
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

Section "Files"
 Fontpath "/usr/share/fonts/X11/misc"
 Fontpath "/usr/share/fonts/X11/cyrillic"
 Fontpath "/usr/share/fonts/X11/100dpi/:unscaled"
 Fontpath "/usr/share/fonts/X11/75dpi/:unscaled"
 Fontpath "/usr/share/fonts/X11/Type1"
 Fontpath "/usr/share/fonts/X11/100dpi"
 Fontpath "/usr/share/fonts/X11/75dpi"
 # path to defoma fonts
 Fontpath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"

Section "Module"
 Load "i2c"
 Load "bitmap"
 Load "ddc"
 Load "extmod"
 Load "freetype"
 Load "glx"
 Load "int10"
 Load "vbe"

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "CoreKeyboard"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "fr"
 Option "XkbVariant" "oss"
 Option "XkbOptions" "lv3:ralt_switch"

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
 Option "CorePointer"
 Option "Device" "/dev/input/mice"
 Option "Protocol" "ImPS/2"
 Option "ZAxisMapping" "4 5"
 Option "Emulate3Buttons" "true"

Section "InputDevice"
 Driver "wacom"
 Identifier "stylus"
 Option "Device" "/dev/input/wacom"
 Option "Type" "stylus"
 Option "ForceDevice" "ISDV4"# Tablet PC ONLY

Section "InputDevice"
 Driver "wacom"
 Identifier "eraser"
 Option "Device" "/dev/input/wacom"
 Option "Type" "eraser"
 Option "ForceDevice" "ISDV4"# Tablet PC ONLY

Section "InputDevice"
 Driver "wacom"
 Identifier "cursor"
 Option "Device" "/dev/input/wacom"
 Option "Type" "cursor"
 Option "ForceDevice" "ISDV4"# Tablet PC ONLY

Section "Device"
 Identifier "nVidia Corporation G71 [GeForce 7300 GS]"
 Driver "nvidia"
 Busid "PCI:1:0:0"
 Option "AddARGBVisuals" "True"
 Option "AddARGBGLXVisuals" "True"
 Option "NoLogo" "True"

Section "Monitor"
 Identifier "Écran générique"
 Option "DPMS"

Section "Screen"
 Identifier "Default Screen"
 Device "nVidia Corporation G71 [GeForce 7300 GS]"
 Monitor "Écran générique"
 Defaultdepth 24
 SubSection "Display"
  Depth 1
  Modes "1280x1024" "1024x768" "832x624" "800x600" "720x400" "640x480"
 SubSection "Display"
  Depth 4...


i've succesfully linked libwfb as Aaron D. Campbell said but my computer is allways crashing ....

How can i be sure this libwfb.so is loaded ?

Alberto Milone (albertomilone) wrote :

attach your /var/log/Xorg.0.log

Hello and many thx

I've a Xorg.o.log but also a Xorg.o.log.old ...

Sitsofe Wheeler (sitsofe) wrote :

I suspect it would be wise to file a new bug report and post a link to the new report within this one...

Svein Harald Soleim (sveinh) wrote :

Still no fix in amd_64 package. I just reinstalled (K)Ubuntu last night and I had to google my way to a workaround for this. Me and my 8800 GS. This should have been fixed before release.

Ben Collins (ben-collins) wrote :

Fix just uploaded to feisty-updates. Should show up in a few days.

Changed in linux-restricted-modules-2.6.20:
assignee: nobody → ben-collins
importance: Undecided → High
status: Confirmed → Fix Released


 Can you provide a test package so we could run tests over the


-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
Ben Collins
Sent: Friday, May 18, 2007 4:59 PM
To: WW Linux Engineering
Subject: [Bug 98641] Re: [nvidia-glx-new] NVidia driver missing libwfb

Fix just uploaded to feisty-updates. Should show up in a few days.

** Changed in: linux-restricted-modules-2.6.20 (Ubuntu)
   Importance: Undecided => High
     Assignee: (unassigned) => Ben Collins
       Status: Confirmed => Fix Released

[nvidia-glx-new] NVidia driver missing libwfb
You received this bug notification because you are a direct subscriber
of the bug.

Changed in linux-restricted-modules-2.6.20:
status: Fix Released → Confirmed
Changed in linux-restricted-modules-2.6.22:
status: New → Confirmed
38 comments hidden view all 118 comments

Hi Alberto, thanks for the Gutsy patch. Setting priority and milestone to make sure we get this into Gutsy.

Changed in linux-restricted-modules-2.6.22:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → High
Sitsofe Wheeler (sitsofe) wrote :

Thanks Alberto!

I'm having a similar problem in Kubuntu with nvidia=glx. The card is a nVIDIA GeForce4 MX440-SE. As long as I've not tried to use the nVIDIA drivers, it works fine. Soon as I try to install the proprietary nVIDIA ones, it won't load KDM.
However, I downloaded 7.10 "Gutsy" Ubuntu, & installed that instead. I enabled the driver in the Restricted-Drivers Manager, logged out, & it loaded GDM. I booted into the GNOME desktop without any trouble! I opened a terminal, & ran "nvidia-settings" to ensure the refresh rate & resolution were correct. It all went very smoothly, with no trouble. So it would seem to be a problem with Kubuntu "Gutsy"?

Jiří Stránský (strana87) wrote :

I installed wfb manually like you advised here, it loads, but I still can't load nvidia module itself, the X server just won't start.. The xorg.conf settings for screen should be OK, when i change the driver from "nvidia" to "nv" or "vesa", X starts normally. Before I used the drivers compiled from nvidia.com, but then suddenly OpenGL applications started to crash X server, so I wanted to try the nvidia-glx-new, since it upgraded to 100.14.11. Now I'm not able to start X with "nvidia" anyhow, even if I uninstall nvidia-glx-new and compile the drivers myself. Compilation succeeds, but then still the same error as with drivers from repository.

2.6.22-10-generic @ x86_64
Nvidia 8600M GS

Last lines of Xorg.0.log:

(II) Setting vga for screen 0.
(**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
(==) NVIDIA(0): RGB weight 888
(==) NVIDIA(0): Default visual is TrueColor
(==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
(**) NVIDIA(0): Enabling RENDER acceleration
(II) NVIDIA(0): Support for GLX with the Damage and Composite X extensions is
(II) NVIDIA(0): enabled.
(EE) NVIDIA(0): Failed to load the NVIDIA kernel module!
(EE) NVIDIA(0): *** Aborting ***
(II) UnloadModule: "nvidia"
(II) UnloadModule: "wfb"
(II) UnloadModule: "fb"
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

Sitsofe Wheeler (sitsofe) wrote :

As you have manually installed the drivers your issue is really a support one rather than a bug report. Please see https://help.ubuntu.com/community/NvidiaManual for a couple of tips and http://www.ubuntu.com/support/communitysupport for other places to go for support now your support options have changed.

Sitsofe Wheeler (sitsofe) wrote :

(I should have included the following with the previous comment, sorry for the deluge)

(Subscribing wraithmonk to this bug report so the reply is seen)

Your card is too old to be affected by this issue (you basically need a card which is an 8000 series or above for this to stop X loading). I suspect your issue is something else so I'd either check for another more suitable bug or perhaps file a new bug report if none could be found as you appear to be using a stock install with only Ubuntu provided pieces.

To new folks coming to this bug from elsewhere (wraithmonk this is *not* you!):
If you are unsure as to whether the description of this bug is your exact issue I would recommend using one of the support options mentioned on http://www.ubuntu.com/support/communitysupport before posting a comment here.

As nobody has mentioned it I will also ask that if you are posting a query in a comment to a bug report can you ensure that you subscribe yourself as it provides a means for other people to reply to you.

afonic (afonic) wrote :

I have this problem in Gutsy as well and fixed it by copying over the file from the official nVidia package.

This bug is pretty critical, it must be fixed in Feisty and make it for Gutsy. FailsafeX is nice, but working without using it is nicer. :)

Kay (noiq) wrote :

The same problem here about two weeks ago, but it's a shame to see the problem being still unsolved. I'm using Xubuntu 7.04 (amd64) with a 8800GTS.

As mmxbass already said this 'bug' is so annoying, because its just package. The problem was solved on five months ago, but the solution didn't reach the packages.

I'm saying nothing new, but what Ari Torhamo and many others said, doesn't seem reach the the package maintainer. Bugs like this one prevent any positive changes of bug #1.

StefanPotyra (sistpoty) wrote :

@Alberto: can you please update your gutsy patch to the newest version (looks like only debian/changelog entry would need an update) and then subscribe ubuntu-main-sponsors?


Alberto Milone (albertomilone) wrote :

Sure, I'll attach the new patch ASAP

Alberto Milone (albertomilone) wrote :

Here is the up-to-date patch for Gutsy.

I have used my signature in the changelog therefore the core-devs will have to replace it with their own.

The rest of the patch is ok.

Alberto Milone (albertomilone) wrote :

I have subscribed ubuntu-main-sponsors

Henrik Nilsen Omma (henrik) wrote :

Alberto, thanks for the patch. I believe this will be uploaded later today.

Changed in linux-restricted-modules-2.6.22:
status: Confirmed → In Progress
Alberto Milone (albertomilone) wrote :

I'm glad to help.

Let me know if you need a new patch for Feisty.

Ben Collins (ben-collins) wrote :

linux-restricted-modules-2.6.22 ( gutsy; urgency=low

  * ABI bump to -11
  * Add lpia architecture support
  * Install libwfb, LP: #98641

 -- Ben Collins <email address hidden> Fri, 07 Sep 2007 11:44:20 -0400

Changed in linux-restricted-modules-2.6.22:
status: In Progress → Fix Released
StefanPotyra (sistpoty) wrote :

Changing back to confirmed. The link is missing for libwfb.so.

Changed in linux-restricted-modules-2.6.22:
status: Fix Released → Confirmed
StefanPotyra (sistpoty) wrote :


please find attached the (minimal) fix against the latest version.


StefanPotyra (sistpoty) wrote :

setting status to fix committed, see last entry.

Changed in linux-restricted-modules-2.6.20:
status: Confirmed → Fix Committed
Alberto Milone (albertomilone) wrote :

why did you put this line in the debian/rules?
ln -s libnvidia-wfb.so.$$this_ver libwfb.so &&

There is already the following line in nvidia-glx-new.links.in:
usr/lib/xorg/modules/libnvidia-wfb.so.@@VERSION@@ usr/lib/xorg/modules/libwfb.so

I'll check the new source code again.

Alberto Milone (albertomilone) wrote :

Sigh, after reading the new code I don't think my patch was applied in its entirety.

StefanPotyra, thanks for reporting the problem again.

Alberto Milone (albertomilone) wrote :

as a matter of fact there is no nvidia-glx-new.links.in

Sitsofe Wheeler (sitsofe) wrote :

Additionally this bug suggests the fix was committed against the 2.6.20 package - was this really the case?

Download full text (4.2 KiB)

I apologise. I described what my patch did but not why. Here is the full explanation:

A) My changes in the debian/rules:

if [ "$$this_ver" = "$(nv_new_version)" ]; then \

   install $$this_dir/usr/X11R6/lib/modules/libnvidia-wfb.so.$$this_ver \

    $(CURDIR)/debian/nvidia-glx$${nv_flav}/usr/lib/xorg/modules/; \


I put if [ "$$this_ver" = "$(nv_new_version)" ] because the latest nvidia driver is the driver which is under development and which therefore will have new features and maybe new modules (and the wfb module is a good example). The 2 legacy drivers will only be maintained and won't have new features implemented. For this reason I think that any new module should be added here (i.e. after 'if [ "$$this_ver" = "$(nv_new_version)" ]; then ').

In my humble opinion it's more flexible than simply relying upon the existence of the wfb module (i.e. if [ -e $$this_dir/usr/X11R6/lib/modules/libnvidia-wfb.so.$$this_ver ]; ) and avoids writing another “if-line” when a new module (other than “wfb”) is added to the driver. My if-line says that if you're building the latest driver you should perform a certain operation.

I changed this part:

 for i in -dev.dirs -dev.links -dev.postinst -dev.postrm \

   -dev.preinst .dirs .docs .examples .links.amd64 \

   .links .override .postinst .postrm .preinst \

   .prerm .README.Debian .reportbug .shlibs; \

 do sed -e "s/@@VERSION@@/$(nv_new_version)/g" -e "s/@@NV_LEGACY@@/-new/g" \

  -e "s:@dirname@:$(nv_new_dirname):" -e "s/@@NV_ALT@@/new/g" \

  < debian/nvidia-glx$$i.in > debian/nvidia-glx-new$$i; \



 for i in -dev.dirs -dev.links -dev.postinst -dev.postrm \

   -dev.preinst .dirs .docs .examples .links.amd64 \

   .links .override .postinst .postrm .preinst \

   .prerm .README.Debian .reportbug .shlibs; \

 do sed -e "s/@@VERSION@@/$(nv_new_version)/g" -e "s/@@NV_LEGACY@@/-new/g" \

  -e "s:@dirname@:$(nv_new_dirname):" -e "s/@@NV_ALT@@/new/g" \

  < debian/nvidia-glx-new$$i.in > debian/nvidia-glx-new$$i; \


Ok, here I changed the “debian/nvidia-glx$$i.in > debian/nvidia-glx-new$$i; “ into “debian/nvidia-glx-new$$i.in > debian/nvidia-glx-new$$i;”

Why? Well (as I will show in the next point) I made a copy of all the nvidia-glx-*.in files and renamed them as nvidia-glx-new*.in. I had to do this for flexibility's sake. In this case the wfb module was added to the driver and I had to add a link to such module in the nvidia-glx-new.links.in and in the nvidia-glx-new.links.amd64.in .

In this way we can keep the links related to the latest driver (nvidia-glx-new) separate from the ones related to the 2 legacy drivers. Otherwise we would have to put the links in the debian/rules but it would break the current way of doing things (e.g. the links for nvidia-glx and nvdia-glx-legacy are listed in the nvidia-glx.links.in and in the nvidia-glx.links.amd64.in and not in the rules file) in the restricted-modules.

B) My changes in the debian/ folder:

1) I made a copy of all the nvidia-glx*.in files and renamed such copies as follows:



@Ben Collins:
here is the new patch for the latest release of the restricted modules for Gutsy (version

I just did a diff -urN debian.old debian > ../linux-restricted-modules-2.6.22-

NOTE: I didn't change the changelog therefore you will have to do it yourself.

the bug affects also the package in feisty

Thomas Zander (zander-kde) wrote :

After upgrading in gutsy-amd64 I now have a libnvidia-wfb.so.100.14.11, but no symlink.

So, I don't fully understand the long messages from yesterday and today, but the end effect is; its not yet working :)

Thomas Zander (zander-kde) wrote :

After upgrading today again, I can confirm that it now works.
Thanks guys!

Christoph Lechleitner (lech) wrote :

Two days ago the state (on the Austrian mirror) was a pain, but with current updates ...
I confirm it works now with gutsy-amd64 on a Thinkpad T61p with Nvidia Quadro FX 570M.

However, I had to explicitly uninstall the manual installation of NVidia's driver, I reinstalled nvidia-glx-new and restricted-modules.
And I had to dpkg-reconfigure xserver-xorg and explicitly select the nvidia driver instead of nv.

Changed in dell:
status: New → Fix Committed
Henrik Nilsen Omma (henrik) wrote :

Moving milestone to beta.

Jacob Boström (jakethecak3) wrote :

A new NVIDIA 100.14.19 Display Driver just go released. Which should fix a couple of regressions and improve peformance.

Changed in dell:
importance: Undecided → High
Sitsofe Wheeler (sitsofe) wrote :

The new driver release doesn't directly impact this bug as I believe the issue here is a deb packaging issue. It's hard to say whether there's going to be enough time to test a new release of the NVIDIA binary only drivers before Gutsy release but Bug #140956 has been filed requesting the new driver.

Works for me.

Changed in dell:
status: Fix Committed → Fix Released
Alexandre Martani (amartani) wrote :

Is this fixed in Gutsy beta?

Christoph Lechleitner (lech) wrote :

>Is this fixed in Gutsy beta?
Yes, more or less.
At least libwfb.so is in the current nvidia-glx-new 100.14.19 package.

Unfortunately there are many other unsolved problem with recent cards from all manufacturers.

Bryce Harrington (bryce) wrote :

Closing as fixed based on Jose's and Christopher's confirmations

Changed in linux-restricted-modules-2.6.22:
status: Confirmed → Fix Released
Timo Aaltonen (tjaalton) wrote :

I don't think this will be fixed for feisty anymore, closing the bug.

Changed in linux-restricted-modules-2.6.20:
status: Fix Committed → Won't Fix
Download full text (8.2 KiB)

how about fixing for Ubuntustudio? It's not just affecting GeForce 8800...I have SLI 650i....

00:00.0 Host bridge: nVidia Corporation C55 Host Bridge (rev a2)
 Flags: bus master, 66MHz, fast devsel, latency 0
 Capabilities: <access denied>

00:00.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:00.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:00.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: bus master, 66MHz, fast devsel, latency 0

00:00.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: bus master, 66MHz, fast devsel, latency 0

00:00.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a2)
 Flags: bus master, 66MHz, fast devsel, latency 0

00:00.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:00.7 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:01.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:01.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:01.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:01.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:01.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:01.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:01.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:02.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:02.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: bus master, 66MHz, fast devsel, latency 0

00:02.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)
 Flags: 66MHz, fast devsel

00:03.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1) (prog-if 00 [Normal decode])
 Flags: bus master, fast devsel, latency 0
 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
 I/O behind bridge: 0000c000-0000cfff
 Memory behind bridge: fa000000-fcffffff
 Prefetchable memory behind bridge: 00000000e0000000-00000000efffffff
 Capabilities: <access denied>

00:05.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1) (prog-if 00 [Normal decode])
 Flags: bus master, fast devsel, latency 0
 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
 I/O behind bridge: 0000a000-0000afff
 Memory behind bridge: fde00000-fdefffff
 Prefetchable memory behind bridge: 00000000fdd00000-00000000fddfffff
 Capabilities: <access denied>

00:06.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1) (prog-if 00 [Normal decode])
 Flags: bus master, fast devsel, latency 0
 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
 I/O behind bridge: 0000e000-0000efff
 Memory behind bridge: fdc00000-fdcfffff
 Prefetchable memory behind bridge: 00000000fdb00000-00000000fdbfffff
 Capabilities: <access denied>

00:07.0 PCI bridge: nVidia Corporation C55...


Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Changed in linux-restricted-modules-2.6.20 (Ubuntu):
status: Won't Fix → Fix Released
status: Fix Released → Confirmed

So will there be a fix in 2.6.20?

Changed in linux-restricted-modules-2.6.20 (Ubuntu):
status: Confirmed → Incomplete
Tim Gardner (timg-tpi) wrote :

Feisty is no longer supported.

Changed in linux-restricted-modules-2.6.20 (Ubuntu):
assignee: Ben Collins (ben-collins) → nobody
status: Incomplete → Won't Fix
Changed in somerville:
importance: Undecided → High
status: New → Fix Released
no longer affects: dell

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1306041

no longer affects: somerville
Displaying first 40 and last 40 comments. View all 118 comments or add a comment.