Uninstalling Catalyst/fglrx leaves behind a broken system

[Qaridarium]

Using AMD's installer is stupid, they mutilate your system, and "when it breaks,you get to keep both pieces". Don't use them. (At least not directly) The buildpkg option might build a distribution package for you which installs in a well-behaved manner, but just using the script and installing it from that is a good way to wreck your system. It's not a matter of, but when. Even if it appears to work at first, an X server or kernel update will come along and break it. (This is another issue, separate from overwriting core system files.
Same advice typically applies to Nvidia, don't use their installer.

i don't use the catalyst installer i use the ubuntu/kubuntu package based installer.

[ChrisXY]

How my package manager should know what to do if I use ATI binary blob ?

Of course you need a proper package for this. I didn't think people still run "installers" that may or may not overwrite arbitrary files in their system.

For example, from the archlinux wiki:
https://wiki.archlinux.org/index.php...FAMD_Installer

Warning: Using the installer from ati.com/amd.com is NOT recommended for inexperienced users! It may cause file conflicts and X failures. You must be familiar with booting to the command-line if you wish to attempt this.

As has been said, recovering should work when reinstalling mesa and libgl.

But how exactly should AMD do it better? I mean, they could back up the files they overwrite, but then they would maybe restore old files to a way newer mesa/libgl release that has been happening in the meantime...

And I wonder: When you use the ati installer and then update mesa/libgl, won't the package manager overwrite files belonging to fglrx and break it?

[DaemonFC]

Of course you need a proper package for this. I didn't think people still run "installers" that may or may not overwrite arbitrary files in their system.

For example, from the archlinux wiki:
https://wiki.archlinux.org/index.php...FAMD_Installer


As has been said, recovering should work when reinstalling mesa and libgl.

But how exactly should AMD do it better? I mean, they could back up the files they overwrite, but then they would maybe restore old files to a way newer mesa/libgl release that has been happening in the meantime...

And I wonder: When you use the ati installer and then update mesa/libgl, won't the package manager overwrite files belonging to fglrx and break it?

Off the top of my head. They could put their files in a different directory and use alternatives and just switch it back to Mesa if you remove FGLRX. Most popular Linux distributions use alternatives, or can. It would be trivial to checl /etc/lsb-release first to see if they're installing to a distribution that can do this.

[ChrisXY]

It would just need LIBGL_DRIVERS_PATH for example set in /etc/profile.d/ and to check when the fglrx kernel module is loaded I think.

[grege]

Straight from the read me ...

Launch the Terminal Application/Window and navigate to the /usr/share/fglrx folder.
With super user permissions, enter the command "sh./fglrx-uninstall.sh"

The script will usually restore all the correct mesa files and symlinks.

[DaemonFC]

Straight from the read me ...

Launch the Terminal Application/Window and navigate to the /usr/share/fglrx folder.
With super user permissions, enter the command "sh./fglrx-uninstall.sh"

The script will usually restore all the correct mesa files and symlinks.

I have yet to see their uninstaller script do anything but break Mesa and possibly stop X from loading because it didn't remove part of the Catalyst bundle.

Their official installer is nasty shit, seriously. Don't use it. (OK, it is your system, but don't say nobody warned you.) If you feel comfortable poking around figuring out why X won't load, use their installer. If you want it packaged in a semi-sane manner that probably won't destroy your system* use the distribution specific packages.

(*This isn't to say that FGLRX won't randomly lock up your system forcing you to hold in the power button, but that's on a bad month, like this month's 11.9 release. Usually.)

[Kano]

Thats correct, do not use the nvidia install on ubuntu >= 10.04. that introduced the gl_conf alternatives switching and will stop working correctly then. it works fine with debian squeeze however.

[grege]

I have yet to see their uninstaller script do anything but break Mesa and possibly stop X from loading because it didn't remove part of the Catalyst bundle.

Their official installer is nasty shit, seriously. Don't use it. (OK, it is your system, but don't say nobody warned you.) If you feel comfortable poking around figuring out why X won't load, use their installer. If you want it packaged in a semi-sane manner that probably won't destroy your system* use the distribution specific packages.

(*This isn't to say that FGLRX won't randomly lock up your system forcing you to hold in the power button, but that's on a bad month, like this month's 11.9 release. Usually.)

I have used the uninstaller successfully many times over the years, more often on Debian systems. With Ubuntu just uninstalling through Synaptic is usually enough. The main thing is to get rid of the symlinks it creates. Occasionally I have had to manually remove xorg.conf and the fglrx entry in /etc/modules.d

I always run "sudo dpkg-reconfigure -phigh xserver-xorg" when I am finished to ensure the system is back to default. Then when back to a desktop open a term and run xvinfo and glxinfo to make sure the Mesa driver is working. The mesa-utils package must be installed to provide glxinfo.

I do agree that removing fglrx is often a lot more messy than removing nvidia.

[DaemonFC]

I have used the uninstaller successfully many times over the years, more often on Debian systems. With Ubuntu just uninstalling through Synaptic is usually enough. The main thing is to get rid of the symlinks it creates. Occasionally I have had to manually remove xorg.conf and the fglrx entry in /etc/modules.d

I always run "sudo dpkg-reconfigure -phigh xserver-xorg" when I am finished to ensure the system is back to default. Then when back to a desktop open a term and run xvinfo and glxinfo to make sure the Mesa driver is working. The mesa-utils package must be installed to provide glxinfo.

I do agree that removing fglrx is often a lot more messy than removing nvidia.

In all fairness, I think AMD and Nvidia should include some kind of warning that using their installer, your distribution's package management will have no way of knowing about or dealing with FGLRX/nvidia being installed and that it's very likely to break the next time you update your system.

Letting users easily install it from their official installer with no warning at all just contributes to this whole "ZOMG, I broke everything, Linux sucks" problem caused by their proprietary drivers. Not that they care. (AMD's download page = radeon_linux.aspx)

[Blacksmith]

I have used the uninstaller successfully many times over the years, more often on Debian systems. With Ubuntu just uninstalling through Synaptic is usually enough. The main thing is to get rid of the symlinks it creates. Occasionally I have had to manually remove xorg.conf and the fglrx entry in /etc/modules.d

I always run "sudo dpkg-reconfigure -phigh xserver-xorg" when I am finished to ensure the system is back to default. Then when back to a desktop open a term and run xvinfo and glxinfo to make sure the Mesa driver is working. The mesa-utils package must be installed to provide glxinfo.

I do agree that removing fglrx is often a lot more messy than removing nvidia.

I agree with grege on this, I have also used the AMD's uninstaller many times without problems. Although one thing needs to be kept in mind, when ever one is working outside the package management system one does need to be switched on.
I normaly use AMD's binary blob directly to install, I have used Kano's script and it works well but it does need a GOOD internet connection and this is something I do not (and likely never will) have. So this restricts how I can do things.

Note: I have not used FGLRX now for at least 6 months as I find the OS driver superior for the type of 3D develpment work I do.

Blacksmith