nVidia drivers and libgl.so.1
Mono
Status: Contributor
Joined: 21 Jun 2012
Posts: 115
Reply Quote
Hello. I wasn't sure whether to post this here but I realized it may be useful for sgfxi, though I'm not sure my problem is directly related to it.

I have had a very strange problem with the nVidia drivers. It is actually on a different computer. It's a Core 2 Quad machine with a GeForce 8400GS, running Linux Mint 13 64-bit.

Initially it had no graphics card and ran graphics through Mesa GLX. It has on-board Intel graphics. I installed the nVidia card on it. Since It was not my computer I decided to use the usual Ubuntu repo packages. This worked. We were able to install Steam and play all the linux games without problems, except that it's an old computer and the graphics card is PCI so regardless of the GPU it's terribly slow. inxi showed direct rendering enabled and the correct drivers loaded.

After some time we decided to try the newest nVidia drivers, at which point I opted to use sgfxi. The install went as planned. However on next startup, the screen was just blank until the login screen came up. inxi showed direct rendering was enabled and the correct drivers loaded. However we entered a 3D game that had previously worked with the repo packages and the screen just went blank, same as the terminal.

So I do ctrl+alt+F1, but nothing changes. It seems everything was working, just there is no display for some reason.

glxgears come up fine with 500FPS, same as with the drivers from the repos.

Steam won't work either. It worked before with the proprietary nvidia drivers from the repos, but now it says it can't find libgl.so.1. I've looked everywhere about this problem, but no one seems to have had my problem yet, except one person who posted just today and got no replies yet. The closest related problem seems to be from 5 years ago.

I've reinstalled the drivers more times and in more different ways than I can count, and even if I revert to the first driver packages, I can't get things to work again. Installing Mesa GLX gives the same functionality as before the graphics card was installed.

At one point I reinstalled the mesa-GLX:i386 packages and this allowed the Steam to run even though it disabled the currently running nVidia driver which I had to reinstall. I really am not sure if this is a architecture conflict or not. Maybe the first set of drivers I installed were in fact 32-bit? However if it were an architecture conflict I gather Steam would say so; according to all similar report Steam's error message reports a libgl architecture mismatch but in my case it's just missing. Even so I tried those fixes and they didn't work.

Some potentially useful terminal output:

:: Code ::
~ $ ls -l /usr/lib/libGL*
lrwxrwxrwx 1 root root      16 Aug  4  2011 /usr/lib/libGLEW.so.1.5 -> libGLEW.so.1.5.2
-rw-r--r-- 1 root root  337808 Aug  4  2011 /usr/lib/libGLEW.so.1.5.2
-rw-r--r-- 1 root root     654 Mar  6 07:57 /usr/lib/libGL.la
lrwxrwxrwx 1 root root      10 Mar  6 07:57 /usr/lib/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root      15 Mar  6 07:57 /usr/lib/libGL.so.1 -> libGL.so.313.26
-rwxr-xr-x 1 root root 1102096 Mar  6 07:57 /usr/lib/libGL.so.313.26


This is from the first time I reinstalled the 32-bit libgl (over the driver installed by sgfxi). The error in the middle did not occur again at subsequent reinstalls.

:: Code ::
~ $ sudo apt-get install --reinstall libgl1-mesa-glx:i386
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  ttf-umefont libboost-filesystem1.46.1 libxml++2.6-2 screen-resolution-extra
  libboost-system1.46.1 libboost-date-time1.46.1 wine-mono0.0.4 wine-gecko1.7
  wine-gecko1.7:i386 wine-gecko1.8 wine-gecko1.8:i386 gnash-common
  libboost-thread1.46.1 gnash ttf-unfonts-core
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 2 reinstalled, 0 to remove and 2 not upgraded.
Need to get 0 B/207 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
(Reading database ... 223125 files and directories currently installed.)
Preparing to replace libgl1-mesa-glx 8.0.4-0ubuntu0.4 (using .../libgl1-mesa-glx_8.0.4-0ubuntu0.4_amd64.deb) ...
Unpacking replacement libgl1-mesa-glx ...
Preparing to replace libgl1-mesa-glx:i386 8.0.4-0ubuntu0.4 (using .../libgl1-mesa-glx_8.0.4-0ubuntu0.4_i386.deb) ...
Unpacking replacement libgl1-mesa-glx:i386 ...
Setting up libgl1-mesa-glx (8.0.4-0ubuntu0.4) ...
update-alternatives: warning: forcing reinstallation of alternative /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf because link group x86_64-linux-gnu_gl_conf is broken.
Setting up libgl1-mesa-glx:i386 (8.0.4-0ubuntu0.4) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place


I guess you understand how painfully disappointing it is when you try to make something better, which doesn't work, and then you SHOULD be able to revert to the old setup but you can't! I've tried removing xorg.conf several times.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
thank you for including the key points, which most people neglect to note;

ubuntu -> install nvidia from repos -> then sgfxi real nvidia driver, then problem.

I have seen this issue many many times, and nobody from ubuntu has ever explained why their drivers do not cleanly uninstall. On the bright side, you actually got sgfxi to install the drivers after using the ubuntu repo ones, many people do not even get that far.

Since I do not run ubuntu, I have never really been interested in figuring out what the ubuntu repo drivers do that cause these issues, it looks to me like some dirty hanging remnants fail to be removed, some paths fail to get updated, some dpkg diversion fails to get reset to default, but I can't tell you what the actual issue is.

the last person to post on this issue resolved his nvidia driver issues by reinstalling mint, literally, and NEVER using the ubuntu nvidia repo driver, just installing directly from sgfxi first. Clearly this is a suboptimal solution, and of course failed to give me any information where I could add a critical ubuntu nvidia clean up step once I found the actual data paths diversions etc to reset to default clean pre repo install.

That's all I can tell you really, either the above is relevant to your case or its not, but I can confirm that something goes wrong internally with ubuntu repo nvidia drivers, they do NOT uninstall clean, they DO leave some type of cruft in some systems that then creates issues for nvidia real package install. Debian does not have this issue as far as I know.
Back to top
Mono
Status: Contributor
Joined: 21 Jun 2012
Posts: 115
Reply Quote
Yeah, Steam and everything runs fine on my LMDE distro.

I remember there was a message while uninstalling something along the lines of "vdpau directory is not empty, so not removing". Maybe if I can find these messages in the logs and remove the directories, I can fix the problem?
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
if you figure it out, let me know, if it's a scriptable cleanup fix I can add it to sgfxi.

Nobody has ever followed up on ubuntu/mint issues so if you find the actual problem and the actual fix for it post it here.
Back to top
Mono
Status: Contributor
Joined: 21 Jun 2012
Posts: 115
Reply Quote
Well, eventually we removed the card and purged everything related to nvidia we could find. We booted up and the intel driver kept failing to load. So I tried using sgfxi to load the correct intel driver. We kept purging nvidia and intel-related things and eventually sgfxi installed the driver and things worked. We just got an eVGA GT620 and put it in and installed the repo drivers with jockey-gtk, and it works, no libgl issues.

So I didn't have to reinstall linux for some reason. I seem to recall that graphics would only work if /etc/X11/xorg.conf was not present. Any time it was, X failed, and it didn't work to regenerate it. I don't know whether the nVidia drivers install an xorg.conf.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
with two graphics cards of different brands, ie, intel/nvidia, you have to assign the pci bus number explicitly in xorg.conf to the proper device item.

sgfxi should start up and ask which card you are going to use in this case before it does much else, but handling those scenarios is tricky. This is by the way the reason, among others, that inxi shows pcibus id numbers, though unfortunately, xorg.conf requires a specific syntax, or it did in the past, sgfxi translates the generic output to that syntax, who knows, maybe that has changed? Hard to say.

I find in general it's best if possible to disable the onboard graphic card so X sees only the one actual card you are going to use. Then having no xorg.conf should work fine, though with nvidia card, with a modern base install.

Thanks for reporting back, but still not enough info in general to figure out any more programmed solution, but generally, to really fix as issue like this I have to be able to reproduce the bug locally, which is hard to do in cases like this.
Back to top
Mono
Status: Contributor
Joined: 21 Jun 2012
Posts: 115
Reply Quote
I've been trying to compile stuff and got this error:

:: Code ::
dpkg-shlibdeps: error: no dependency information found for /usr/lib/libGL.so.1 (used by debian/muffin/usr/bin/muffin)


It seems to be dealt with here:

forums.linuxmint.com/viewtopic.php?f=208&t=113890

Does this apply to the drivers as installed with sgfxi and if so, what directory do I need to link to?
Back to top
Display posts from previous:   

All times are GMT - 8 Hours