Created attachment 395638 [details] emerge --info Upgraded to the latest ati-drivers-14.12-r3, eselect-opengl-1.3.1, libva-1.5.0, xorg-server-1.16.3-r1 X will no longer load completely and I am left at a blank screen which I cannot Ctrl+Alt+f# away from. Only solution is to login remotely and restart, or hard reboot. Starting X from a remote login via ssh, I get the following error: /usr/bin/X: symbol lookup error: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: GlxInitVisuals2D This error is only visible in the console, not recorded in Xorg.0.log I have verified eselect-opengl is on the ati profile
Created attachment 395640 [details] /etc/make.conf
Created attachment 395642 [details] /etc/X11/xorg.conf
Created attachment 395644 [details] /var/log/Xorg.0.log
Created attachment 395646 [details] strace X > X.strace.out 2>&1
This appears to be a duplicate of https://bugs.gentoo.org/show_bug.cgi?id=534128 and not related to the latest ati-drivers (x11-drivers/ati-drivers-14.12-r3). The newest eselect-opengl (app-admin/eselect-opengl-1.3.1-r2) seems to be causing the issue by not properly signaling to X which libglx.so file to load. Running 'eselect opengl set ati' no longer symlinks /usr/lib64/opengl/ati/extensions/libglx.so to /usr/lib64/xorg/modules/extensions/libglx.so Instead, it creates /etc/X11/xorg.conf.d/20opengl.conf with the following contents: Section "Files" ModulePath "/usr/lib32/xorg/modules" ModulePath "/usr/lib64/opengl/ati" # << this line is added ModulePath "/usr/lib64/xorg/modules" EndSection The only change to the file from eselect opengl set xorg-x11 is the middle line with the path to the ati folder. X11 is still trying to load the libglx.so from /usr/lib64/xorg/modules/extensions/libglx.so instead of the one from the ati folder. Removing 'ModulePath "/usr/lib64/xorg/modules"' causes fglrx_drv.so to not load since it resides in that folder. The following completely resolves my issue and X runs normally. However, it is not a long-term fix and I believe the behavior of eselect-opengl, xorg-server, or both need to be investigated further to correct how the proper libglx.so is loaded depending on the selected profile. FIX: cd /usr/lib64/xorg/modules/extensions mv libglx.so libglx.so.bak ln -s /usr/lib64/opengl/ati/extensions/libglx.so ./libglx.so After replacing the xorg libglx.so file with a symlink to the ati version, everything loads and performs as expected. *** This bug has been marked as a duplicate of bug 534128 ***
