How to replace fglrx (AMD Catalyst) with original driver?

I have installed proprietary AMD driver - fglrx and now I would like to get back to previous driver which came with openSUSE instalation. I am little bit afraid of simply uninstalling it as I am not sure if this won’t cause problems for my openSUSE instalatian.

Will fglrx be replaced by original driver when I uninstall it or it needs to be done in other way?

You should and have to uninstall it.

How you would do that depends on how you installed it in the first place though.
If you installed it via RPMS (YaST, zypper, or the 1-click install), then just go into YaST->Software Management, search for fglrx and install the package.

Will fglrx be replaced by original driver when I uninstall it or it needs to be done in other way?

No. You should have the original driver still installed.
If you remove fglrx, the original radeon driver should be used automatically again, yes.
Unless you created a Xorg configuration file, /etc/X11/xorg.conf. If you have that you must remove it, as it will force the system to use the fglrx driver which will fail obviously.

If you should encounter problems after uninstalling fglrx, select “Recovery Mode” in the boot menu (“Advanced Options”) to get into a graphical system.

Just for information. I uninstalled fglrx but after using computer for a while Xsession started having problems (kept falling down) - isntalling fglrx back fixed it
I reinstalled the system since so it’s not an issue for me, just as an info warning (and I am not aware of creatin /etc/X11/xorg.conf

So I am a bit confused.

rsupremo, are you running 13.2?
From this NewsPost, I have been assuming that fglrx (a.k.a. AMD Catlayst Driver) was not available as yet due to a bug.
From where are you installing your fglrx?

And a related question, as I was just about to ask “How to replace fglrx (AMD Catalyst) with original driver?” when I found this thread.
A search of YAST>Software management does not find any ‘radeon’ packages, but does find a couple supporting libraries.
Am I correct that radeon is actually part of the kernel, therefore no stand alone packages?

You can download the driver from AMD’s homepage e.g.
But even the latest version does not work on 13.2 yet, as it is incompatible with the new Xorg 1.16.1 included in 13.2.

And a related question, as I was just about to ask “How to replace fglrx (AMD Catalyst) with original driver?” when I found this thread.
A search of YAST>Software management does not find any ‘radeon’ packages, but does find a couple supporting libraries.
Am I correct that radeon is actually part of the kernel, therefore no stand alone packages?

The radeon driver consists of two parts (like most other drivers, even the proprietary ones) :

  • the kernel module “radeon”, that is part of the kernel package (kernel-desktop, kernel-default, …)
  • the “radeon” X driver, this is in the package xf86-video-ati

Then there’s also the OpenGL part, that’s contained in the Mesa package, and some chips also need separate firmware, part of the kernel-firmware package.

Thanks, still makes me wonder if rsupremo is aware of this known incompatibility.

Thanks for clarification.
Running YAST>Software Management , search on radeon with RPM “Provides” and File List checked displays all the pieces.

Well, I told him in my first reply to uninstall it…
And you told him about the incompatibility as well.

If he really installed it again, he is probably using the fbdev or vesa driver now. Might explain why installing it again fixed his problem…rotfl!
But not in the way he probably thinks. Just adding “nomodeset” would be the better option and would not break OpenGL. :\

OK, attempted to move back to radeon driver.

This is a 13.1/KDE 4.14.2 desktop machine with AMD APU integrated graphics.
Kernel is 3.11.10-21-desktop

  1. Using YAST>Software Management I deleted the fglrx installed driver
    When I checked, the file /etc/X11/xorg.conf had been renamed xorg.conf.block, presumably by the uninstall script

On reboot, I can only get a graphical display using the Grub2 ‘recovery’ option.
It appears to be running the vesa driver.

I am sort of guessing I need to do a mkinitrd , but not sure.

Other recomendations?

For 13.1:
Have a look at /etc/sysconfig/kernel and check that there’s NO_KMS_IN_INITRD=“no”.
It it’s set to “yes”, change it and run mkinitrd. Otherwise the radeon driver will not work fully because a generic driver is already loaded by plymouth.

If you have the fglrx driver installed, radeon is not added to the initrd at all so the same problem can happen.
Running " sudo /sbin/mkinitrd" should fix that by re-creating the initrd and copying radeon into it.

Also check that there’s no blacklist for radeon in /etc/modprobe.conf.d/.

grep radeon /etc/modprobe.conf.d/

And check that you have “kernel-firmware” installed. That’s necessary for many AMD graphics chips/APUs.
If it’s missing, install it and run “mkinitrd” afterwards.

If that doesn’t help, please do a normal boot, reboot to “recovery mode” after it fails, and post the file /var/log/Xorg.0.log.old.

OTOH, the radeon driver from 13.1 might just be too old for your particular chip, or have problems with it.
Why don’t you just continue using fglrx?
There’s only a problem with 13.2, as the driver doesn’t work there yet (new Xorg).

Life is easy when wolfi is on the job :slight_smile:

I had to do both of these:

  • Change /etc/sysconfig/kernel and check that there’s NO_KMS_IN_INITRD=“no”, it was set to “yes”
  • Check that there’s no blacklist for radeon in /etc/modprobe.conf.d/. On my system I found radeonfb blacklisted in the file 50-blacklist.conf, I removed that.

I then executed /sbin/mkinitrd, then init 6 and was able to start up with the radeon driver.

I had two motivations for this:

  1. I have been running fglrx for at least a year now, for no particular reason. After an update to the most recent fglrx in October , I started to have issues with recovery from STR (sleep) mode. I would frequently get a garbled display, or worse nothing at all. Looking at pm.suspend logs was not yielding anything useful, so I wanted to see if radeon would work better.
  2. I am prepping the system for upgrade to 13.2 and decided to get this part out of they way first.

I’ll report later once I use radeon for a while

Thanks a bunch for the guidance

OK, I had a little cleanup to do to fully restore the appearance of my two monitor setup, nothing significant or unexpected.

I have executed one successful Sleep Cycle (Sleep, then CR to wake again).
Not a definitive test, as I found that it would fail to wake up somewhat randomly when running fglrx,
but one success is clearly better than a failure on first try.

Thanks again for the assistance.

BTW, https://en.opensuse.org/SDB:Radeon is slightly out of date, in that it does not say anything about applicability to 13.1 and now 13.2.
Is this deprecated, or just in the queue for update?

No. radeonfb is not the same as radeon.
You should not remove the blacklist radeonfb.
I do not know why it is there, but there must be a good reason that it is blacklisted by default on openSUSE…
A comment in this file says:

# list all framebuffer drivers, some of them tend to crash during boot
# they are either compiled into the kernel, or vesafb is active
# X works fine without them, rcfbset can load them if really required

So better add it back.
Or remove the file and reinstall sysconfig to re-create it with the defaults.

sudo rm /etc/modprobe.d/50-blacklist.conf
sudo zypper in -f sysconfig

The latter way makes sure that the file gets updated whenever you install updates. This won’t happen after you changed it manually (as it is a configfile).

I then executed /sbin/mkinitrd, then init 6 and was able to start up with the radeon driver.

Good, so setting NO_KMS_IN_INITRD=“no” and running mkinitrd fixed it, by adding radeon back to the initrd.

This was probably a left-over from the fglrx installation.

OK, I turned the blacklist for radeonfb back on and re-ran /sbin/mkinitrd.

After reading your discussion above, I was hoping that would correct one issue I noted.
On boot, after the Grub2 display, boot starts but it appears that graphical plymouth display is not running correctly.

I do see in /var/log/boot.log

        
....Starting Show Plymouth Boot Screen...

[32m  OK  [0m] Reached target Sound Card.
[32m  OK  [0m] Found device ST1500DL003-9VT16L.
         Starting File System Check on /dev/disk/by-id/ata-ST1500DL003-9VT16L_5YD3YAKW-part1...
systemd-fsck[636]: home_volume: clean, 129530/81977344 files, 127651039/327884287 blocks
[32m  OK  [0m] Started Show Plymouth Boot Screen.
.....

Plymouth does run to completion, I get the KDE greeter screen when X starts

Sorry, I don’t really understand what you mean.

Is plymouth working now or not?

Your log excerpt shows that it is started.

If it is “not running correctly”, what does that mean exactly?
Do you still get the text messages? Do you get a blank screen? Do you get a graphical boot splash, but not the one you expect? :wink:

I went back and followed your suggestion for editing the blacklist file, just in case the method I used to re-enable the blacklist on radeonfb was cause.

sudo rm /etc/modprobe.d/50-blacklist.conf
sudo zypper in -f sysconfig
sudo mkinitrd

The above three commands ran without obvious error .

Is plymouth running now or not?"

Well, plymouth runs after accepting the top (default) menu item in the Grub2 menu.
Normally, if I recall correctly, there is a mostly black graphical screen (gecko on branch), which I think is what is called the bootsplash.
Normally, about 2 to 3 seconds into boot a message appears with a box, requesting the password for my encrypted back-up drive that mounts during boot.
Normally, I enter the password and enter, a couple more seconds go by and the KDE Login Greeter appears.

Now, when I hit enter to select the default menu item in the Grub2 menu, I see some messaging from Grub about initial ram disk mounting, etc (Normal to here), then the display goes black briefly and the I get a message from the display saying no input, auto shutdown (of the display) will occur soon.
Watching the hdd activity light on the desktop looks normal, and 2 to 3 seconds after the screen shutdown message I hear a faint ‘thump’ from my speakers, similar to when I un-mute audio. This same thump would normally occur when the bootsplash was properly displayed. When I hear the thump, I enter my crypto disk password and enter, a couple seconds later the screen comes back to life with the KDE login Greeter displayed.

So plymouth is running, but it’s display is not.

It seems as if the plymouth graphics driver might be having an issue, or perhaps the bootsplash file is corrupt?
The contents of /etc/sysconfig/bootsplash are the defaults:

## Path:    System/Boot
## Description:    selects bootsplash graphics theme
## Type:    string
## Default:    ""
## Command:    /sbin/mkinitrd
#
# Bootsplash theme. Should be based in /etc/bootsplash/themes/.
#
THEME="openSUSE"

Suggestions obviously welcome.

Reload Plymouth?

Well, at this point, the X graphics driver is not used at all yet of course.

Maybe plymouth just selects a wrong resolution?
Try to change the resolution (for the “graphical console”) in YaST->System->Boot Loader->Boot Loader Options.
They apply for plymouth and the text mode console as well.

Or maybe even try to disable grub2’s theme. to use text mode for the boot menu.

I suppose the problem disappears when you disable plymouth by adding “plymouth.enable=0” to the boot options?

It seems as if the plymouth graphics driver might be having an issue, or perhaps the bootsplash file is corrupt?
The contents of /etc/sysconfig/bootsplash are the defaults:

## Path:    System/Boot
## Description:    selects bootsplash graphics theme
## Type:    string
## Default:    ""
## Command:    /sbin/mkinitrd
#
# Bootsplash theme. Should be based in /etc/bootsplash/themes/.
#
THEME="openSUSE"

Those are ignored by plymouth. They are from the old bootsplash used before plymouth.

plymouth’s theme is set in /etc/plymouth/, but better use the command “plymouth-set-default-theme”.
Just run “plymouth-set-default-theme” to see the currently set theme.
And to set the default openSUSE theme:

sudo plymouth-set-default-theme -R openSUSE

(the -R rebuilds the initrd as well, which is necessary as plymouth is started from there normally)

But if you get a “no input” error from the monitor, I doubt that it’s related to the plymouth theme.

Thanks for the suggestions.
I tried various combination of resolutions, but nothing good has come of it.

I have to get some other work done and am in a state I can live with for a while.

The good news is that STR (sleep) seems to work well now.

I may just wait until I decide to update to 13.2.

Sorry for confusion. At the time of writing this post I had 13.1 installed and then I changed my signature when I installed 13.2 from scratch.