recent update breaks Mesa?

Hello,

I have recently updated my OpenSUSE 13.1 installation with the new OpenSUSE kernel 3.16 and everything. After software updates were installed I rebooted the system and many things look broken.

  1. I have a Radeon HD 5430 video card and had the proprietory fglrx drivers installed. Now Xorg server hangs on startup and the system looses the mouse and keyboard.

  2. I switched to the open source **radeon **drivers. Now GNOME Desktop fails to load with the following message
    in the /var/log/gdm/:0.log

(EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r6
00_dri.so: undefined symbol: _glapi_tls_Dispatch)
(EE) AIGLX: reverting to software rendering
(EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/
swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
(EE) GLX: could not load software renderer

Since I do not have a reference working system at hand, I can’t tell if this is a bug or I have something broken in the configuration.

Please post if this is happenning to you also.

Well, it’s not really a good idea to mess around with the latest Xorg and kernel versions when using a proprietary driver, unless you really know what you are doing.
It happens e.g., that the proprietary driver(s) do not support the latest Xorg or kernel immediately when it is released, but only some time later.
And depending on how you installed the driver in the first place, you might have to re-install it after any Xorg, Mesa, or Kernel update.

  1. I switched to the open source **radeon **drivers. Now GNOME Desktop fails to load with the following message
    in the /var/log/gdm/:0.log
(EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r6
00_dri.so: undefined symbol: _glapi_tls_Dispatch)
(EE) AIGLX: reverting to software rendering
(EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/
swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
(EE) GLX: could not load software renderer

Since I do not have a reference working system at hand, I can’t tell if this is a bug or I have something broken in the configuration.

According to that error message, you seem to have at least parts of the fglrx driver (libglx probably) still installed. This breaks the Mesa drivers, in your case r600g and the software renderer swrast.
So how did you install fglrx in the first place? How did you uninstall it?

Unfortunately GNOME (and GDM) will not work at all (not even in recovery mode) in the state your system is at the moment.
You could switch to a different login manager (/etc/sysconfig/displaymanager->DISPLAYMANAGER, xdm should be installed by default) and window manager (/etc/sysconfig/windowmanager->DEFAULT_WM, icewm shoul be installed) to get a graphical interface at least.
The try ro remove all remnants of fglrx, and/or maybe re-install xorg-x11-server and Mesa-libGL1.

Thank you for your reply!

Just realized that the update occurred because I recently enabled the Factory repository. This should have messed up my installation. Will try to roll back to original 13.1.

According to that error message, you seem to have at least parts of the fglrx driver (libglx probably) still installed. This breaks the Mesa drivers, in your case r600g and the software renderer swrast.
So how did you install fglrx in the first place? How did you uninstall it?

I had it installed from RPMs that came from the unofficial FGLRX repository by Bruno Friedmann at Ioda-Net (http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_13.1/)

Unfortunately GNOME (and GDM) will not work at all (not even in recovery mode) in the state your system is at the moment.
You could switch to a different login manager (/etc/sysconfig/displaymanager->DISPLAYMANAGER, xdm should be installed by default) and window manager (/etc/sysconfig/windowmanager->DEFAULT_WM, icewm shoul be installed) to get a graphical interface at least.
The try ro remove all remnants of fglrx, and/or maybe re-install xorg-x11-server and Mesa-libGL1.

Great advice! I used to boot into runlevel 3 and run Xorg with twm from the command line.

Well, enabling the Factory repo on a released openSUSE version is not a good idea either. :wink:

If you want to switch to Factory, you should disable all 13.1 repos and use “zypper dup” to switch all packages to Factory.
Otherwise you will likely end up with an incompatible mix of packages.

To completely switch back to 13.1 you could disable/remove the Factory repo again, and run “zypper dup”.

Btw, I think you added/enabled the Factory for installing/trying the latest Kernel/Xorg?
There are repos for 13.1 that contain those built for 13.1 as well. You should rather use those if you want the latest.

I had it installed from RPMs that came from the unofficial FGLRX repository by Bruno Friedmann at Ioda-Net (http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_13.1/)

Ok, then uninstalling the fglrx package with YaST, zypper or rpm should remove all traces of the driver.
I suppose you did that?

Then probably you have some packages from Factory mixed with some from 13.1 causing your problem.

Indeed. Went for a shiny new application package and did not realize what I got into by keeping the Factory repo enabled. My bad.

If you want to switch to Factory, you should disable all 13.1 repos and use “zypper dup” to switch all packages to Factory.
Otherwise you will likely end up with an incompatible mix of packages.

To completely switch back to 13.1 you could disable/remove the Factory repo again, and run “zypper dup”.

Actually this almost worked. Initially I was thinking of downgrading the 4000+ packages one by one. So that saved me hours of struggling with dependencies.

There were a few issues.

  1. One issue was due to the new kmod-compat
    that obsoletes module-init-tools. Had to downgrade kmod-compat first and then replace it with the module-init-tools from the distribution. Otherwise the system will get no modules in the initrd file and won’t boot. 1. Another was with one unidentified package that removed the /etc/alternatives/awk
    link early in the process of distribution upgrade. This caused many a %pre and %post script to fail in a nasty way.

So far the system works but I could not get the graphical interface back to normal yet. The system fails to show any Xorg font characters in Gnome-session or XFCE4, I am getting boxes instead. I understand that this might have different causes: missing fonts, misconfigured font server, language configuration, etc. Will keep trying…

Btw, I think you added/enabled the Factory for installing/trying the latest Kernel/Xorg?
There are repos for 13.1 that contain those built for 13.1 as well. You should rather use those if you want the latest.

Went for an application package without realizing what Factory is really about.

Ok, then uninstalling the fglrx package with YaST, zypper or rpm should remove all traces of the driver.
I suppose you did that?

Then probably you have some packages from Factory mixed with some from 13.1 causing your problem.

Yes, that’s the correct diagnosis.

Ah yes. I noticed that when helping somebody else with downgrading from Factory some time ago.
Sorry, I forgot about that.

So far the system works but I could not get the graphical interface back to normal yet. The system fails to show any Xorg font characters in Gnome-session or XFCE4, I am getting boxes instead. I understand that this might have different causes: missing fonts, misconfigured font server, language configuration, etc. Will keep trying…

That’s another issue of the downgrade.
The pango modules cache is still from the newer pango version I suppose.
Recreating it should fix the problem:
for 32bit:

/usr/bin/pango-querymodules --update-cache

for 64bit:

/usr/bin/pango-querymodules-64 --update-cache

Great! I just reinstalled pango altogether to resolve the issue with the fonts,
but updating the font cache would’ve been much much nicer.

That’s another issue of the downgrade.
The pango modules cache is still from the newer pango version I suppose.
Recreating it should fix the problem:
for 32bit:

/usr/bin/pango-querymodules --update-cache

for 64bit:

/usr/bin/pango-querymodules-64 --update-cache

Thank you for your help!

Yes, this works as well, as installing the packages does re-create the cache.
AFAICT it’s a problem in the order the packages are installed. That’s why this happens when downgrading only, this is not really tested.

Thank you for your help!

No problem. :wink:

If you still have problems, feel free to ask.
But better open a new thread if it’s not related to Mesa… :wink: