57

I have problems when compile SFML-project(don't see any graphic):

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

This error can be solved by simple reinstalling nvidia-drivers through this tutorial: https://askubuntu.com/a/451248/341889

..but when i get new updates - this error is returning ;( What should I do? It's not the solution - not use system's update...

P.S. and yes, i saved all changes after installing nvidia-drivers

XavierStuvw
  • 1,451
  • 3
  • 16
  • 45
pushandpop
  • 1,028
  • 1
    This happens to me if I try to launch an OpenGL executable dynamically loading the mesa libGL.so: LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/mesa ./glprogram. By default, my Ubuntu 16.04 uses /usr/lib/nvidia-361/libGL.so because of /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf and it all works fine. – Ciro Santilli OurBigBook.com Sep 04 '16 at 16:29
  • 1
    What if my machine does not have nvida hardware and I get that same errors? – KcFnMi Feb 20 '20 at 05:09

17 Answers17

36

The swrast thing is the software renderer. That means it's not finding the hardware driver for your graphics card. There are a bunch of libGL libraries installed and a bunch of of symbolic links to those libraries. To see these run this from the shell:

find /usr -iname "*libGL.so*" -exec ls -l -- {} + 

Now the probable cause of your problem is that installing graphics drivers sometimes break these symbolic links. (Specifically /usr/local/lib/libGL.so.1.2.0 is likely to be either the wrong lib or a sym link to the wrong link) (N.B. I wrote this a while ago. libGL.so.1.2.0 was the current gl version it may be something else now).

To work out what library the OpenGL programs are trying to run you can turn on a bit of verbosity and run a simple OpenGL program. You can verify this using the standard OpenGL test program:

LIBGL_DEBUG=verbose glxgears

Hopefully that will fail in the same way as SFML. With LIBGL_DEBUG it should tell you what OpenGL library it's trying to load. Furthermore the lib it will be trying to load will almost certainly be /usr/local/lib/libGL.so.1.2.0 (Edit: This was the standard OpenGL library on my machine at the time I answered this. It may well be some other version on your machine now).

So the solution (in this case) is to make sure that /usr/local/lib/libGL.so.1.2.0 is a symbolic link pointing at the right OpenGL library. In my case I have the Nvidia 3.40 driver so I ran:

ln -s /usr/lib/nvidia-340/libGL.so.1 /usr/local/lib/libGL.so.1.2.0

But you'll want to point it at the OpenGL lib that is appropriate for you (listed in the first find command).

In summary: installing (proprietary) graphics drivers can break the symbolic links used for OpenGL libs. To solve this problem manually fix the symbolic links (fix /usr/local/lib/libGL.so.1.2.0 first).

  • This issue helped me understand the error message, but not fixing it. The "re-install nvidia drivers" answer helped was a good complement as it actually fixed the problem for me. – henko Sep 29 '15 at 07:00
  • @henko yes reinstalling nvidia drivers is probably the fastest and easiest way to sort this out. Fall back to this approach if for whatever reason reinstalling the drivers doesn't fix your problem and you need to get your hands dirty. – demented hedgehog Sep 30 '15 at 00:57
  • 7
    I understood every part, except "almost certainly be /usr/local/lib/libGL.so.1.2.0". Mine shows "libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so" and all these file exist in my system... – Samuel Li Oct 19 '15 at 23:21
  • I'm just saying that that was the problem on my machine (with an up-to-date ubuntu derived os). So at that time that was likely to be the current opengl lib version. These days it may well have some other version though mine is still pointing at 1.2.0 on a new machine. – demented hedgehog Jan 01 '16 at 09:43
  • 1
    Thanks again for your explanation; I do understand better about the problem. I also want to point out that in my case, there's a confirmed bug in the ubuntu swrast.so, and people have been discussing it. – Samuel Li Feb 19 '16 at 00:31
  • Oh that's interesting. Yeah there can be lots of potential causes for this type of problem. – demented hedgehog Feb 19 '16 at 03:21
  • 1
    Thank you @dementedhedgehog This was an excellently articulated post and helped me solve my issue (on Fedora-25, by the way). =:). Up-voted. – NYCeyes Apr 01 '17 at 21:26
  • My pleasure.... – demented hedgehog Jul 16 '19 at 12:43
9

Got same problem on ubuntu 18. This happened basically only with 32bit apps. So my idea was to install 32bit nvidia something, as my /usr/lib/i386-linux-gnu/ folder was suspiciously empty.

After very few tries, this fixed my problem with steam and wine not starting:

sudo apt install libnvidia-gl-418:i386

(and change 418 to whichever version you have)

Interesting that the applications did not complain about missing dependencies during installation.

zx485
  • 2,426
vmicho
  • 91
  • This seems to have fixed one of my problems related to the question, at least... – Andrew Apr 21 '19 at 22:40
  • It being 32 bit might be why. Other programs work fine, but those are probably 64 bit. Nonetheless, this works fine (I had to bump the version though) – Zoe is on strike Sep 10 '19 at 11:17
  • it works! I think you can use the latest libnvidia-gl-* – Danil Aug 24 '20 at 13:24
  • The problem seems to be solved with this, BUT after a couple of hours my computer freezes and the programs are now SLOW ... Please, take a look at this thread: https://askubuntu.com/questions/1298036/how-can-i-install-steam-without-having-to-uninstall-64-bit-libraries – Wilem2 Oct 12 '21 at 22:51
5

I was having problems getting the correct symlink to point at the nVidia driver and I found another way that works for me.

It is outlined here.

And it lists on how to install the nVidia driver via PPA which is avaliable for 349.16, the latest version.

First uninstall any nVidia drivers currently installed by opening a terminal window (Ctrl + ALT + T) and typing

sudo apt-get remove nvidia*

Reboot your system

Then open another terminal and type the following

sudo add-apt-repository ppa:xorg-edgers/ppa
sudo apt-get update
sudo apt-get install nvidia-349 nvidia-settings
sudo add-apt-repository -r ppa:xorg-edgers/ppa

Then reboot again

I tried it after getting lost with the symlinks and steam worked fine immediately after the installing the driver and again it was still working after I had 400+ megs of system updates.

Adrian
  • 73
  • 2
    I would not suggest to leave xorg-edgers ppa after the driver is installed. A lot of unstable packages will come in updates. – Pilot6 May 21 '15 at 13:54
  • just removing the nvidia* already solved this problem for me! – xtofl Jun 09 '17 at 16:33
5

I had the same issue on Ubuntu 16.10 with the nvidia-340 drivers and none of the solutions here worked for me.

Turns out the 32-bit libraries were not on the library path.

This one liner worked for me:

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib32/nvidia-340"
alexg
  • 764
  • 7
  • 16
4

I just use this line:

 sudo rm /usr/lib/i386-linux-gnu/libGL.so.1

and it works.

Because I see such input when I execute sudo ldconfig -p | grep -i gl.so:

libwayland-egl.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1
libcogl.so.20 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcogl.so.20
libOpenGL.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libOpenGL.so.0
libOpenGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libOpenGL.so
libGL.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so.1
libGL.so.1 (libc6) => /usr/lib/i386-linux-gnu/libGL.so.1
libGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libGL.so
libEGL.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libEGL.so.1
libEGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libEGL.so
3

To provide an alternative to Adrian's answer: if you prefer to use proprietary drivers sourced directly from NVIDIA instead of those found in a PPA, installing (or in my case, re-installing) the latest proprietary driver can help eliminate the swrast error.

If you don't have the NVIDIA driver yet, download the driver from NVIDIA's website. Next, switch to tty (ctrl+alt+F1) and turn off your login manager:

If using lightdm, $ sudo service lightdm stop

If using gdm, $ sudo service gdm stop

Navigate to the install script and run it, and follow the prompts. Don't worry if the pre-install script fails. I always accept registering DKMS and the 32-bit compatibility libraries. After the driver is installed, restart your machine:

$ sudo reboot

If you already have an install script from an older NVIDIA driver, simply run the NVIDIA driver install script as oulined above, but with the "--update" option:

$ sudo ./NVIDIA-Linux-x86_64-***.**.run --update

This will get you the most up-to-date version of the driver.

Doing this fixed my libGL error: failed to load driver: swrast error.

2

Just run this:

sudo apt-get install libnvidia-gl-(the version of your driver):i386

The version of your driver is showed in nvidia-settings.

2

I have to admit, I'm not sure why this works for me, but it did. In this particularly case "fixing" the ld.so.conf.d entries by adding a new entry like this works:

sudo ln -s /usr/lib/nvidia-381/ld.so.conf /etc/ld.so.conf.d/nvidia64.conf
sudo ldconfig 

This makes sense, until you run the following find:

$ find -L /etc/ld.so.conf.d -type f | xargs grep -i nvidia
/etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf:/usr/lib/nvidia-381
/etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf:/usr/lib32/nvidia-381
/etc/ld.so.conf.d/x86_64-linux-gnu_EGL.conf:/usr/lib/nvidia-381
/etc/ld.so.conf.d/x86_64-linux-gnu_EGL.conf:/usr/lib32/nvidia-381
/etc/ld.so.conf.d/nvidia64.conf:/usr/lib/nvidia-381
/etc/ld.so.conf.d/nvidia64.conf:/usr/lib32/nvidia-381

Why having the same entries in triplicate works, but not in duplicate, I have no idea!

bbarker
  • 121
  • 5
  • Works for me on Ubunu 17.04. Just a note - the path is /usr/lib/nvidia-xxx where xxx is the driver number so adapt the command to that. – user2082382 Oct 08 '17 at 18:06
2

Here's an apt-only solution that worked for me, no symlinking or mucking around with ld.so.conf.d:

apt install --reinstall libgl1-mesa-glx:i386
apt install mesa-utils nvidia-driver nvidia-driver-libs-i386
Cuadue
  • 123
1

In my case the solution to this issue resided in the continuation of the error message

Paraview 5.7.0 informed me that:

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
(   0.833s) [paraview] vtkOpenGLRenderWindow.c:748 ERR| vtkXOpenGLRenderWindow (0x5588ae6a2160): GLEW could not be initialized: Missing GL version
...
Segmentation fault

The message

GLEW could not be initialized: Missing GL version

has been key. I run 'glxgears' to check that the graphics libraries were running fine -- see also man glxgears -- showing this animation:

screenshot of glxgears

Then my solution was simply setting the environment variable

LD_PRELOAD=/usr/lib/libGL.so

Take note:

  1. Although I have a Nvidia graphics card, I did not need to fiddle around with it;
  2. Launching locate libGL.so, I find another candidate /usr/lib/i386-linux-gnu/libGL.so. Setting this as LD_PRELOAD, however, did not fix the problem;
  3. No need to set any information about the GLEW library appearing above either --- see locate libGLEW.so

I am indebted to https://github.com/openai/mujoco-py/issues/44 for clues

XavierStuvw
  • 1,451
  • 3
  • 16
  • 45
  • For the difference between LD_PRELOAD and the more commonly cited LD_LIBRARY_PATH please see https://stackoverflow.com/q/14715175/5459638 – XavierStuvw Nov 18 '19 at 22:27
0

I had this issue recurrently, with every new driver destroying steam. I now use steam flatpak and have zero issues.

linhares
  • 101
0

Seems like the NVIDIA installer simply gets the locations wrong on certain distros. Ubuntu 19.10 and was having issues. 'locate' revealed the NVIDIA 32-bit libraries did exist, but not in the right place. This one-liner fixed it for me.

sudo cp /usr/lib32/*nvidia* /usr/lib/i386-linux-gnu/

P.S. this would only work for 32-bit related issues.

0

This fixed it for me: sudo apt-get install libnvidia-gl-390:i386

Source

Josh Correia
  • 135
  • 7
0

I was getting this report in the PlayOnLinux debugger. I ended up switching to the recommended Nvidia driver and then uninstalling the default graphics driver. I then reinstalled the Nvidia graphics drivers through Synaptic Package Manager and that stopped the madness. I don't know how the inner workings of the library linking is established but the Nvidia install seems to work better without the default driver in the way. It fixes the links.

0

In my case the problem was that the card was set to "on-demand mode". When I run an application with special environment variables set it runs OK:

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxgears

If you want everything to run on the nvidia gpu, use

sudo prime-select nvidia

and reboot.

0

for me, I needed to point my libGL.so to an older fglrx libGL.so.1.2 from an old archive to fix this issue, after a motherboard replacement and much messing with graphics drivers. Once I did this, glxgears ran much smoother, video in firefox with hardware acceleration was fixed, and obs would launch and display my webcam / capture card input again. Most steam games still didn't work via proton, sadly, I was hoping this would fix them but nope.

The problem stems from using a version of libGL.so that is not correct to load your swrast_dri.so lib file. If you messed with your graphics drivers, you might have touched this file, so maybe look at your backups.

ram
  • 1
-3

I was facing this weird issue when I ssh to my Ubuntu VM from my Macbook Pro, but installing the below Nvidia driver on my Ubuntu 16.04 fixed the issue. Hope this works for you.

sudo apt-get install nvidia-331

  • 1
    Why would you install Nvidia GPU drivers on a VM guest system? Ó_ò – David Foerster Oct 28 '16 at 09:31
  • The downvote is not appropriate. @DavidFoerster is right in that installing GPU drivers in a VM does not make any sense (unless you passthrough the GPU hardware to the VM). But: I am running X over SSH, and I am facing the same problem. Starting X applications on the remote machine (VM) nearly always leads to the error messages mentioned in the OP's question. I haven't found a solution to that problem yet, but if installing GPU drivers on the remote VM would be the solution, I'd do it, regardless of whether it makes sense, just to make that errors go away (I'm currently ignoring them). – Binarus May 12 '19 at 16:36