sgfxi fails to install nvidea legacy 173... into latest sid
I'm getting a failed install for nvidea 173.... legacy driver install into latest sid and aptosid kernels. I have tried sgfxi which fails with error code 1 I believe and get a simular failure if I try to install with aptitude from the repos. Any ideas???
Back to top |
no ideas until you post a link to your /var/log/sgfxi/sgfxi.log file, use a paste service like: paste.debian.net and then post the url to it here.
The question are too many to try to extract from you one at a time, and the log shows me everything I need to know. Back to top |
|
try using the latest liquorix kernel and build the module again, see if that works.
There's no sgfxi error, and I haven't heard any report about 173 drivers failing on 2.6.35 kernels. this failure is in the nvidia installer, and it doesn't show that much unfortunately other than the module failed to build.. no, I take that back, it's using the mepis 2.6.32 headers, not the slh ones. If you installed this manually and didn't install the headers, install them and try again, if you did, it looks to me like a mepis kernel bug, not sure, but that's what it looks like. If you used smxi to install slh kernel, then the headers are installed. you can see clearly in the logs that the nvidia installer is using the mepis headers for 2.6.32, which of course won't work. That's neither an sgfxi nor an nvidia installer issue I believe. Back to top |
I did use smxi to install the kernel and the headers are installed for all kernels so I'll give the liquorix kernel another try as you suggest and see if it builds in it. Thanks for the help.
Back to top |
the problem in my opinion is in the mepis kernel, try using smxi's cleanup/kernel remover to remove all traces of it, something in it is breaking the path the nvidia installer is getting when querying your system.
Mepis needs to get more debian compliant in my opinion, Warren has been putting that off now for almost 2 years. Back to top |
Sgfxi is likely failing with the Mepis kernel because the version of linux-kbuild-2.6.32 which is installed is the sid package instead of the mepis package. (linux-kbuild-2.6.32 is a dependency for the linux-headers-2.6.32-1-mepis-smp package)
Both the sid and Mepis linux-kbuild-2.6.32 packages carry the same version number, 2.6.32-1. The linux-kbuild package was upgraded to the sid version either during the upgrade of Mepis to sid or by sgfxi itself (when it ran the m-a prepare command) in preparing for installation of the nvidia driver. I was able to fix this on my sid upgraded Mepis 8.5 install by enabling the Mepis 8.0 repo (the Mepis 8.0 repo is the repo which has the linux-kbuild-2.6.32 package), reload repo lists (apt-get update), force install of the mepis version of linux-kbuild-2.6.32 (apt-get install linux-kbuild-2.6.32/mepis), disable 8.0 repo, reload repo lists (apt-get update), and then run sgfxi again. If you intend to keep using the Mepis kernel you should probably pin the linux-kbuild-2.6.32 package so it won't get upgraded to the sid version with future updates. On my install I eventually moved to Liquorix and other kernels and removed the original Mepis kernel. Back to top |
This issue is unrelated to sgfxi, sgfxi doesn't test for or use directly kbuild, just the headers.
I assume however that the mepis kbuild package points to the mepis headers no matter what headers you have actually installed as real live ones. this is the type of debian non compatibility that is making me lean towards not offering support for Mepis issues in the future. This doesn't mean you can't use sgfxi/smxi, you can, but it just means I won't support the failures encountered. Back to top |
All times are GMT - 8 Hours |