Fedora 13 upgrade woes, another problem with nvidia.
I just upgraded to Fedora 13, all went smoothly.. or so I thought. When it finally became time login to my new system I got a error saying ksmserver wouldn’t start, and my session would then close and throw me back to the login screen.
Turning to a console I decided to run ‘ksmserver’ and see what errors I got, sure enough it failed. There was a mismatch between the versions of libGL.so and libGLCore.so.
The libGL.so being used was offered by the “mesa-libGL” package, the other the “kmod-nvidia” package. I thought this was odd, should it be using the mesa libGL? I dunno, what I do know is the nvidia package does install nvidia’s own libGL.so library.. maybe the package was suppose to set up the links? Maybe the mesa one is suppose to be compatible?
Anyway this is how the linking looked:
# ls -l /usr/lib64/libGL.so*
lrwxrwxrwx. 1 root root 10 May 31 16:06 /usr/lib64/libGL.so -> libGL.so.1
lrwxrwxrwx. 1 root root 15 Jun 1 10:43 /usr/lib64/libGL.so.1 -> libGL.so.190.42
-rwxr-xr-x. 1 root root 439952 May 1 10:38 /usr/lib64/libGL.so.1.2
-rwxr-xr-x. 1 root root 928808 Dec 11 09:43 /usr/lib64/libGL.so.190.42
So I linked ‘libGL.so.1 to the nvidia one:
cd /usr/lib64
unlink libGL.so.1
ln -sf /usr/lib64/nvidia/libGL.so.1 libGL.so.1
So it looks like:
# ls -l /usr/lib64/libGL.so*
lrwxrwxrwx. 1 root root 10 May 31 16:06 /usr/lib64/libGL.so -> libGL.so.1
lrwxrwxrwx. 1 root root 28 Jun 1 11:00 /usr/lib64/libGL.so.1 -> /usr/lib64/nvidia/libGL.so.1
-rwxr-xr-x. 1 root root 439952 May 1 10:38 /usr/lib64/libGL.so.1.2
-rwxr-xr-x. 1 root root 928808 Dec 11 09:43 /usr/lib64/libGL.so.190.42
I restarted X (just to be on the safe side) and logged in… problem solved!
NOTE: To restart X under fedora you just kill the kdm or gdm process as X is spawned as a part of inittab (pkill kdm). Unlike a debian based system in which it’s a init script (/etc/init.d/kdm restart).
It’s a bit of a hack, and hopefully it will be fixed properly, but here is at least a solution that works!
thanks a lot, this solved my problem as well. I’m not sure if there is a better way to do it, but it works!
OK, so on my correctly configured NVIDIA enabled machine, I also have the same output you describe.
[chris@shem ~]$ ls -l /usr/lib64/libGL.so*lrwxrwxrwx. 1 root root 10 Sep 1 18:33 /usr/lib64/libGL.so -> libGL.so.1
lrwxrwxrwx. 1 root root 12 Aug 14 20:29 /usr/lib64/libGL.so.1 -> libGL.so.1.2
-rwxr-xr-x. 1 root root 442728 Aug 5 08:57 /usr/lib64/libGL.so.1.2
Those GL libraries are not from NVIDIA, so it seems that to get NVIDIA working you don’t need to clober those libraries. Instead, I think that you just tell your xorg.conf where to look for them.
There’s a tool to do this, which creates the appropriate xorg.conf file.
nvidia-config-display enableHowever, I think the reason that it failed is because when the NVIDIA driver was installed, there was already an xorg.conf file in place. I noticed that myself, on a computer which has a basic xorg.conf in place that post installing the NVIDIA driver, the nvidia configuration startup daemon failed. It failed every time until I deleted the existing xorg.conf, then everything worked.
So, I think that you shouldn’t experience this problem if you remove any xorg.conf file you have before you install the driver.
Failing that, you shouldn’t have to manually clobber the GL libraries, just run the command above, or make sure your xorg.conf file has the relevant lines.
Section "Files"ModulePath "/usr/lib64/xorg/modules/extensions/nvidia"
ModulePath "/usr/lib64/xorg/modules"
EndSection
Anyway, YMMV but I think that’s what I found!
-c