modprobe nvidia fails with "FATAL: Could not open '/lib/modules/2.6.24-8-generic/volatile/nvidia.ko': No such file or directory"

[ExecutorElassus]

recent (since around 2.6.24.5, but I could be mistaken) linux-restricted-modules-generic packages are apparently providing an nvidia kernel module that cannot load, instead giving the following error:

#modprobe nvidia
FATAL: Could not open '/lib/modules/2.6.24-8-generic/volatile/nvidia.ko': No such file or directory

my guess is a broken link pointer somewhere, but 'locate nvidia.ko' returns nothing, so it's possible that the kernel module isn't being installed at all.

I'm running the latest alpha of Xubuntu Hardy. I have both linux-restricted-modules-generic and nvidia-glx-new installed.

Thanks,

EE

WORKAROUND:
1. remove "nv" from the list of DISABLED_MODULES in
/etc/default/linux-restricted-modules-common
2. Restart the computer

[JoseStefan (josestefan)]

This was happening to me until I removed "nv"
from the list of DISABLED_MODULES in

/etc/default/linux-restricted-modules-common

Then I restarted.
Please confirm.

[ExecutorElassus (n-andrew-walsh)]

confirmed, sorta. I can now modprobe nvidia, and set xorg.conf to use it. But it uses the nv driver anyway, and defaults to 1600x1200 (rather than the widescreen 1920x1200 I need) on X restart. At least now it isn't booting into "low-graphics mode" every time; why would enabling the nvidia driver suddenly make the nv driver work (of course, even that might not last through reboot; I'll report back)?

So does that count as [SOLVED], and I should open a separate bug? Or is this the root problem of this bug?

Thanks for the help. It'd make more sense if 'nv' always meant "the nv driver," and not "nv, unless it's in the restricted modules file, in which case it refers to its polar opposite, the nvidia driver."

[Matthäus Brandl (matthaeus)]

The file itself explains this: (as far as I can see)
> [..] and "nv" disables the three nvidia drivers.

[Matthäus Brandl (matthaeus)]

Well thanks JoseStefan, you helped me a lot.
I was already fed up with recompiling the NVIDIA driver every time Ubuntu installed a new kernel. Finally it will update automatically again...
Now I'd like to know why I added nv to /etc/default/linux-restricted-modules-common, I guess I red it somewhere when my driver didn't work and messed everything up.

I don't think this is a bug but misconfiguration.

[Charlie Kravetz (cjkgeek)]

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here.

I am adding the WorkAround provided to the description.

Thanks for taking the time to make Ubuntu better!

[Matthäus Brandl (matthaeus)]

Deleting the file /etc/modprobe.d/nvidia seemed to resolve my problem. I only hat to install nvidia-glx-180 and upon the next boot DKMS built a new module which was loaded without problems...
(this on a freshly jaunty upgraded from intrepid, I guess the solution would have been possible earlier, but the upgrade reminded me of this problem once more)

[Andy Whitcroft (apw)]

This is not a bug in the linux-meta package, moving to the linux package.

[penalvch (penalvch)]

ExecutorElassus, thank you for reporting this and helping make Ubuntu better. Hardy desktop reached EOL on May 12, 2011.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, could you please test for this with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested and remove the tag:
needs-upstream-testing

This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the text:
needs-upstream-testing

If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

Please let us know your results. Thank you for your understanding.

Helpful Bug Reporting Tips:
https://help.ubuntu.com/community/ReportingBugs

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]