Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1366310 - undefined symbol: _glapi_get_dispatch_table_size
Summary: undefined symbol: _glapi_get_dispatch_table_size
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: 25
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-08-11 14:53 UTC by srakitnican
Modified: 2016-11-02 10:32 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-08-12 09:48:50 UTC

Attachments (Terms of Use)
Dnf transaction history before failure (deleted)
2016-08-11 14:53 UTC, srakitnican
no flags Details
Xorg.0.log after startx (deleted)
2016-08-11 14:54 UTC, srakitnican
no flags Details

System ID Priority Status Summary Last Updated 98428 None None None 2016-10-26 08:44:04 UTC

Description srakitnican 2016-08-11 14:53:29 UTC
Created attachment 1190071 [details]
Dnf transaction history before failure

I booted into a running F25 (previously rawhide) install and after a system upgrade followed by reboot I was unable to startx again. Following errors shows up in Xorg.0.log:

[    45.265] (EE) AIGLX error: dlopen of /usr/lib64/dri/ failed (/usr/lib64/dri/ undefined symbol: _glapi_get_dispatch_table_size)
[    45.265] (EE) AIGLX: reverting to software rendering
[    45.509] (EE) AIGLX error: dlopen of /usr/lib64/dri/ failed (/usr/lib64/dri/ undefined symbol: _glapi_check_multithread)
[    45.509] (EE) GLX: could not load software renderer

The strange part is that it seems upgrade did not touch any parts that failed and I don't have any third-party drivers installed that might get into mismatches like that.

# lspci -s 00:02.0 -vnn
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09) (prog-if 00 [VGA controller])
        Subsystem: ASRock Incorporation Device [1849:0152]
        Flags: bus master, fast devsel, latency 0, IRQ 28
        Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at f000 [size=64]
        [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [a4] PCI Advanced Features
        Kernel driver in use: i915
        Kernel modules: i915

Comment 1 srakitnican 2016-08-11 14:54:39 UTC
Created attachment 1190085 [details]
Xorg.0.log after startx

Comment 2 srakitnican 2016-08-12 09:46:11 UTC
I've made a new install, and that worked so I started to hunt for differences. Turned out that libglvnd package installed from UnitedRPMs repository somehow influence Intel driver. By removing /etc/ and rebuilding cache with ldconfig, X start with no problems.

Comment 3 Igor Gnatenko 2016-08-12 09:48:50 UTC
sorry, don't use libglvnd as it's not supported officially by Fedora.

Comment 4 srakitnican 2016-08-12 10:20:26 UTC

I did not "choose" to use it it was installed by upgrade as you may have seen by dnf transaction log. I have no idea what libglvnd is for.

Comment 5 Nicolas Chauvet (kwizart) 2016-10-26 08:44:05 UTC
While this issue exists with libglvnd, it's present in current mesa release.
Reported upstream.

Please consider using Fedora and RPM Fusion

Comment 6 srakitnican 2016-11-02 05:52:29 UTC
The problem for me was that when I was initially installing Fedora, command
"dnf --disablerepo=* --enablerepo=rawhide --nogpgcheck --installroot=/mnt groupinstall Fedora Workstation" [1] did not install mesa-libGLES package resulting in pulling libglvnd some day since it provides files needed as well.


If anyone cares.

Comment 7 Nicolas Chauvet (kwizart) 2016-11-02 07:32:22 UTC
(In reply to srakitnican from comment #6)
...yes sure, using not-community based repository is leading to well known issue.
It's going to be fixed by using community based repository such as RPM Fusion.

Comment 8 Nicolas Chauvet (kwizart) 2016-11-02 08:10:41 UTC
more accurately, RPM Fusion never hit this issue.

Comment 9 srakitnican 2016-11-02 08:50:12 UTC
RPM Fusion is not providing libglvnd?

At that time RPM Fusion was not providing packages for F25, so UnitedRPMs was the only option. I hope the trend of RPM Fusion providing packages for development Fedora releases continues.

Comment 10 Nicolas Chauvet (kwizart) 2016-11-02 09:38:38 UTC
libglvnd is in fedora since few weeks. but you had this issue with a version from elsewehere.

We've provided packages for f25 since the start of the f25 development 6 months ago, and we already have 26 packages since f25 was branched. Maybe you mean f24 ? In this case the project was late because of moving the new infra. but I don't understand why this kind of information isn't shared to users (we are now back to service).

Anyway, let's move on this, thx for sharing your point.
Also note that your original issue was forwarded upstream.
Thx for your report.

Comment 11 srakitnican 2016-11-02 10:32:09 UTC
Yes, sorry I meant F24. Either way, I knew that RPM Fusion was in the process of moving. What I don't understand is to why it was unavailable. Imagine that Fedora doesn't provide new releases because it is upgrading infrastructure. I am thinking, if old infrastructure was working before why it was not used until new one was ready. Or if that was not possible, just a plain handcrafted temporary repo would suffice to me at least.

Sorry everyone, for slight offtopic but I had to say that.

Thank you for your contributions, they are appreciated.

Note You need to log in before you can comment on or make changes to this bug.