Moving from catalyst/fglrx to AMDGPU
This is a post I wrote a while back, that also got cross-posted on a github issue, detailing my struggles replacing catalyst/fglrx with AMDGPU on arch linux. Thought I should leave a copy of it here, just in case Github dissappears one day. Note this post is basically a copy-pasta of the Github issue response (which is a copy pasta of what I wrote down).
Sometime in late 2016, I started having problems playing CSGO (CounterStrike: Global Offensive), and wanted to see if my graphic driver was the problem (or was for some reason convinced it was). Seeing there was a (then) relatively new open source driver for RADEON cards called AMDGPU, I was super excited to try it out. Unfortunately the process was a little crazy, see below for details, while I tried to fix CSGO, and re-install (seemingly) everything on arch.
If everything is right with the world, no one will have this problem in 2017, or any year after that, since AMDGPU is now pretty easy to install on arch (and should be good enough to be default).
Installing AMDGPU, the long winded guide
There were quite a number of steps to be taken, but here’s what I did first that worked for a day: 1. Re-install all game files for CS GO (this may not be an option depending on how your internet connection is). This fixed it for me, but only for a day, by the time I came back the next day either the files had changed or whatever was wrong had happened again.
The real answer seems to be that I was using
fglrx (which is now deprecated) instead of the newer
amdgpu drivers. I have a Radeon R7 360 (
$ lspci | grep "Radeon"), which is covered by the new driver (you can check if yours is covered here: http://xorg.freedesktop.org/wiki/RadeonFeature/), so I moved over to that.
I’m running Arch, and for me, this actually become quite a tedious process, which essentially amounted to:
fglrx – if you’re uncomfortable with life outside of a running X-server (just a console, nothing else), this might be kind of rough. You may have to spend lots of time in just a plain TTY before stuff gets up again
BEWARE: if your distro does not save your configurations for programs, you should abandon this guide (or find some other way to save your changes) – what I mean is, if you uninstall a program like thunderbird and re-install it, you shouldn’t have to put in all your configuration for all your mailboxes all over again. If you’re unsure what your distro does, you can uninstall some program that is low-impact, and see if you have to reconfigure it again when you reinstall.
Note that uninstalling these will most likely NOT go smoothly. In my case, one of the dependencies for these was
xorg-server (which absolutely makes sense), and of course, when I uninstalled that too, many other things had to be uninstalled (as they depended on
Make sure to make a note of whatever gets uninstalled as part of this process, you will have to re-install the packages later (for example, I use Clementine, and it had be to be uninstalled).
1. Ensure that
fglrx are nowhere on your system – check
systemd list-units, anywhere else you think it might be
mesa drivers - obviously, there are quite a few drivers that need to be installed here, if you run arch, a handy page is https://wiki.archlinux.org/index.php/AMDGPU. Make sure to also install the lib32 versions of these drivers, along with the other things on the wiki.
3. Install all the programs back that uninstalling
fglrx forced you to remove (ex. Clementine)
*BEFORE you restart your computer *(which is the next step), make sure that you’ll be able to confidently boot into it, without your X-server working. This might mean knowing a trick like CTRL+ALT+F2 (I believe) to get a plain TTY in Ubuntu. Xorg won’t be there, so you won’t have a GUI to look at/use/login with
1. Restart your computer, the
amdgpu kernel module should be running now,
fglrx should be gone
xorg-server, other programs that depended on it, make sure to select
mesa-libgl this time (if given a choice of which driver to use), instead of where you might have selected
fglrx related drivers before
3. At this point, you should be able to install whatever session manager you were using (for me, XFCE).
If you get errors about xserver failing when you try to start your session manager, check the logs for your the X server, usually found at ~/.local/share/xorg/Xorg.0.log or /var/log/Xorg/0.log. Near the bottom you should find some hints.
For me, most of the errors I got had to do with missing screens/messed up devices (some of the config was still telling Xorg to look for the
fglrx kernel module. I fixed this issue by just moving the configuration files/folders for xorg (
/etc/X11/xorg.conf.d) to backup versions of themselves.
$ sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.bak
1. After this, you should be able to restart your session manager. Depending on your linux distro, all your setting should still be perfectly intact for your favorite programs (arch preserves your settings… not sure if your distro will or not)
If you’ve made it here, start your session manager like normal and see that everything is OK/breathe a huge sigh of relief.
So here’s the part where we actually get to try and reinstall steam.
The tldr is simple:
1. Try to install steam normally
2. if 1) fails, try native mode *_(using the environment flag
STEAM_RUNTIME set to 0, more info @ https://wiki.archlinux.org/index.php/Steam#Steam_runtime_issues)
3. *_For native mode to work properly, you will have to download a ton of lib32 libraries, and make sure they are on your system/accessible from LD_LIBRARY_PATH at least.
4. Change steam to always start with STEAM_RUNTIME set to 0, however you launch programs
I had to take many many trips to the AUR (Arch User Repository, where community-maintained packages are kept) to install all the lib32-* shared libraries I needed, querying which ones every time to find the next thing to download.
This page was particularly useful: https://wiki.archlinux.org/index.php/Steam#Steam_runtime_issues (note the section that gives you a nice oneliner to find the still-missing shared libraries)