CenOS 6.8 And LibGL Failures

Home » CentOS » CenOS 6.8 And LibGL Failures
CentOS 5 Comments

Ever since I upgraded to CentOS 6.8, some software has stopped working alogether. This is related to OpenGL/mesa and can be demonstrated with glxgears:

$ glxgears libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 33
Current serial number in output stream: 35

This appears to be a common problem, but I found no solutions that apply here since I believe everything is installed and set up correctly. It all worked with CentOS 6.x, x<8. https://www.CentOS.org/forums/viewtopic.php?tV273

5 thoughts on - CenOS 6.8 And LibGL Failures

  • –nI8fcGjR6jqrDs6rTSwlnwDtWBAFmPAdT
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    I am looking at this issue right now.. more to follow


  • –MjeQ2qBu77l1VlPL2QTNsUgl2xiJgJDdg Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    [johnny@localhost ~]$ glxgears
    1054 frames in 5.0 seconds = 210.750 FPS
    1064 frames in 5.0 seconds = 212.735 FPS
    1077 frames in 5.0 seconds = 215.366 FPS
    1061 frames in 5.0 seconds = 212.018 FPS

    [johnny@localhost ~]$ rpm -qa | egrep -i ‘glx|mesa’ | sort glx-utils-11.0.7-4.el6.x86_64

    [johnny@localhost ~]$ cat /etc/redhat-release CentOS release 6.8 (Final)


    I have no issues .. no 3rd party repos on this server.

    Can you provide more details .. did you upgrade all the 6.8 RPMS and not just cheery pick updates .. do you have 3rd party repos installed?

    Is this i386 or x86_64 CentOS-6.8?

    Thanks, Johnny Hughes


  • Curiously my intel 845-G has had gl applications (freecad and wine based windows games) STARTED working correctly with this update.

    I see in a latter email that you have a) found a path issue for users vs root, and b) you are using nvidia. This reminded me of an issue I was having with some GL code I use (jogamp based) and nvidia drivers a little over a month ago, this might be something else you want to be aware of.

    Nvidia is in the process of making a Vendor-Neutral GL[0], which I think is probably a good thing, but they have found that “several applications relied on behaviors or attributes of the NVIDIA OpenGL driver that fall outside of the Linux OpenGL ABI”[1]. Once I figured out it was kmod-nvidia related, this[2] post helped me figure out the mapping to the other links. for now I have had to stick our nvidia machines at 352.79 until either we get our app working with the GLVND API, or elrepo packages a non-GLVND config[1].

    [0] https://github.com/NVIDIA/libglvnd
    [1] https://devtalk.nvidia.com/default/topic/915640/unix-graphics-announcements-and-news/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/

    [2] https://www.CentOS.org/forums/viewtopic.php?f&tW047

    Even when this disclaimer is not here:
    I am not a contracting officer. I do not have authority to make or modify the terms of any contract.

  • There is yet another issue with nvidia drivers and indirect GLX, which will generate almost the same error message. Indirect GLX was disabled by default in Xorg 1.17, which was introduced in CentOS 7.2 and 6.8.

    This problem only happens if you run the GL application remotely and display on nvidia driver enabled screen. It’s not clear from the OP
    if that is the case here.

    The solution would be to add +iglx to Xorg command line, but gdm is hardcoding the Xorg parameters, so if you use gdm/gnome you are out of luck.



  • Not out of luck, but certainly in a bit of a pickle. Xorg wrapper script as suggested in the second link certainly works.

    I’m assuming given the tickets lurking that they’re planning on reverting the default behaviour in future versions, which would certainly be welcomed here.