Keep in mind, my focus is quite narrow, it's whether sgfxi has a bug or problem that sgfxi can resolve, everything outside of that I leave alone.

Your report here however is excellent, the one you just made, and has a lot of the details needed.

Here's the deal, the ubuntu package will probably not include the uninstaller, so that answers that question in a sense. However, sgfxi is supposed to purge all fglrx packages when it runs the download driver installer, that's a pre install cleanup operation.

Now, if sgfxi runs that purge/removal of all packages, then gets an error from the actual amd installer that parts of the driver remain, that's a problem, and the problem is one of two things: removing/purging the packages from apt does not in fact remove all of the driver. This was, you may recall, my first suspicion. That is an ubuntu packaging bug if it's the case. The second option is that there is another package in the fglrx install that does not have fglrx in the package name, that is super easy to fix in sgfxi by simply adding that package to the search parameters I use to detect installed packages.

However, when you did the manual removal via apt of the packages, if I read your thing right, that should have been exactly what sgfxi should have done internally to start the process. It searches apt db for all installed packages that contain 'fglrx' and then removes them, or it should. So that's a possible place that suggests something I have long suspected, that the newer ubuntu driver packages are not in fact uninstalling as expected, maybe due to some forced dkms stuff that actually does not remove all of itself, it's very difficult to say because nobody from ubuntu has ever tracked down the problem.

Basically if you do this: dpkg -l | grep fglrx then use apt to remove those packages, that is exactly what sgfxi does. If doing that leaves cruft that blocks the ati installer from operating, and you see it exit with that error message, that means the ubuntu packaged fglrx driver is not uninstalling clean, or has one more component whose package name does not contain the term 'fglrx', or that something in ubuntu's dkms handling creates some type of loop where you simply cannot get rid of the driver unless you do some unknown procedure.

I have for a while seen this ubuntu driver problem, always caused I believe by the initial installation of the ubuntu driver package, it didn't used to be a problem, but then I started seeing it now and then, but I don't run ubuntu so I never could track it down, nor did any ubuntu user offer to do the tedious procedure of pinpointing just what is causing that issue.

Now, a 'radeon' removal error means that sgfxi was unable to blacklist radeon driver prior to installing the non free driver. Many users have reported, especially with fglrx, that they needed to run sgfxi twice, of course, it should first note, after you strip out and return to radeon xorg driver and boot into it, if it runs, the kms radeon stuff is running, if not, it's not. sgfxi is supposed to detect failure to blacklist the radeon kms stuff, then you have to reboot, and you should reboot into a system that is not running radeon kms, and you can usually see that visually because your console is not 'pretty', but of course, ubuntu makes that hard because they do the image based boot and hide the boot data showing on system start. With no boot gfx running, you can see when kms is running or not easily because of how the console fonts look.

So it may be there are two totally non related problems, or it may be that ubuntu changed something in kms blacklisting, I really don't know.
Back to top

Thanks for that. Very clear.

I've downloaded the Ubuntu driver (3 files), but I'm not sure how the Ubuntu Additional Drivers program works, can't tell if there's an uninstaller, and won't be able to track down whether there's another package that does not have fglrx in the package name. No problem.

On Xubuntu 13.04, sgfxi ran great, and I only had to run it one. But, I had manually installed the previous driver using the 3.1. Manually installing Catalyst method in their "BinaryDriverHowto/ATI", so I was working with an uninstaller, without question before.

I think what I'll do is wait for the new driver, and then install the first time their way (manually installing), giving me an uninstaller, and then move along with sgfxi as before.

For the radeon removal issue, OK. I could now purge the radeon driver, and go from there. But because the 13.9 driver is still not ready, I think I'll wait it out for now, and live with the radeon driver.

Thanks once again. Bottom line is that all is well for my main debian testing box, and I'm not too worried about this for Xubuntu.
Back to top

sgfxi runs the manual installer, there's no need to do it yourself before running sgfxi since that's what sgfxi does.

sgfxi steps:

1. determine card, system
2. determine if driver supports card/system/kernel
3. check for required dependencies, install if missing
4. download driver from amd
5. run installer
6. do any post install cleanup

Also, if it's a first time, it will check if kms / radeon / nouveau are blacklisted and blacklist them if required. If it applies blacklisting, it will stop and force a reboot, which you must do or radeon/nouveau are still running and will break the installer process.

If a patch is required, post download, and pre install, the driver package is extracted and patched.

If going the other way, to radeon, it will check to make sure blacklists are removed.

sgfxi does nothing magical in terms of running the installer step, it runs it, and the installer does whatever it does, exactly as if you'd downloaded it and run it, only more accurately of course since it's scripted.

So the question remains unsolved, what is ubuntu doing, why doesn't a standard remove fglrx packages work. this question comes up now and then and since it's never been followed up on, it remains an issue, but not one that I will personally spend my time debugging unless someone actually figures out what the difference between the ubuntu and debian packages/dkms process actually is/are, there clearly is a difference since this does not happen on debian systems, at least never that I've seen reported.
Back to top

The card fan was whining using the radeon driver on Xubuntu 13.10. That was too troublesome to leave alone.

Fortunately, AMD just posted a new 13.11 Beta (6) yesterday (10/25/13).

help.ubuntu.com/community/BinaryDriverHowto/ATI#Manually_installing_Catalyst_13.4

I used this to build:



The instructions indicate:



I could not automatically Fix Broken Packages, so when I chose to Completely Remove the fglrx 2:13.250-0ubuntu1 in Fix Broken Packages, Synaptic indicated that it was going to 1) remove the driver, and 2) install dkms.

And this lack of dkms matched the error I got when initially installing the created deb files with sudo dpkg -i fglrx*.deb .

EDIT: I forgot to mention that after removing the driver and installing dkms, I was able to install the driver the manual Ubuntu way without a problem.

As I indicated in my last post, I bet sgfxi would work without a problem next time. Now there is an AMD uninstaller present, and dkms is installed.
Back to top

Just a few points, the amd deb package constructor has been broken and unreliable for a long time, so using it is not a very good idea.

dkms is only relevant if you are using the distro driver package plus the distro kernel, any other circumstance it will almost certainly fail.

Consider a system using dkms as a closed locked loop, no second party kernels, only packages from distro repo, the official primary ones, installed.

For example, you would not run liquorix with dkms + fglrx since fglrx is always lagging seriously behind current kernels. Nvidia is better, but has also required patching for 3.10, 11, and I think 12.

sgfxi -B installs the beta driver once I add it to sgfxi, if it's not in sgfxi, it means that I haven't added it yet, for two reasons: time, I haven't gotten to it, or lack of kernel/xorg support.

You're making things hard on yourself here, not sure why. Use sgfxi -h to see the available options. Beta version detection is also dynamic, ie, if they put up a new beta driver, sgfxi should detect it and add it, as long as the version number is the same, ie, 13.11-betav1 or 13.11-beta6, sgfxi will note a new beta6 version of 13.11 and then offer that, at least it's supposed to, though amd constantly changing their file names makes it somewhat challenging to make sgfxi keep up with their randomness.

lmde is always suspect, heavily, because of clem's insistence on throwing in ubuntu mint packages into what is supposed to be a debian distro, in fact, that's why I no longer use, installs, or recommend lmde, all my lmde installs I had running for friends failed on upgrades, which means that debian's awesome ability to constantly be upgraded without reinstalls is broken by lmde, which means lmde is not debian.

Just to give an idea, my main systems run sid/testing, testing/sid (pinned to testing that is), and stable, and all upgrade fine always, with some glitch fixing. I upgrade them about every 3 to 6 months on average, and all are the original installs (2006-01, 2007). Any debian derived distribution that is not able to do this is no longer debian and should not use the term. Siduction is an example of a real debian distro that does not ever break this type of direct debian compatibility, I believe solusos is like that too. Mint is not, lmde is not, ubuntu is not, mepis is not.
Back to top

OK.

I guess the question is, for Ubuntu, is it your guess that not having dkms installed before running sgfxi created my installation error?

I'm not concerned about sgfxi not specifically coding the latest beta. I think the beta dynamic detection would have worked (I'm assuming no path issues). I only used the beta because it's advanced. I still have 13.9 installed on my debian box, and I don't plan on upgrading (until a new kernel comes out).

Keep in mind that I had problems with the Ubuntu Build way, and using sgfxi on a "virgin" installation (with no previous fglrx installed). sgfxi threw out the "radeon removal failure" error. So I stayed with the Ubuntu buildpkg to try to track down Ubuntu issues, but also to see how that might also relate to sgfxi.

IOW, I'm considering that not having dkms installed might be creating issues for both methods.

OK on lmde. I've been very tempted to try straight debian, but it's the lack of firmware and time that's held me back.
Back to top

Unless something has changed, which it could have, the run packages don't add dkms, but they could change that. Changing it would be a very very bad idea on amd's part because their drivers are often months, soon close to 1/2 year, behind the current kernel, so there's no way dkms would work.

The radeon removal error again is something specific to the way ubuntu sets up their system, and since I don't run ubuntu, i don't know what they changed. Neither fglrx nor nvidia can install if the kms thing is running, radeon or nouveau, and the install will fail, that's not related to the driver, that's related to how it works internally in gnu/linux at this point. If the kms stuff isn't getting blacklisted that means they changed something in the blacklisting syntax somewhere, already sgfxi looks for and handles a lot of possible ways to blacklist/unblacklist, but nothing stops anyone from changing those at random and making the sgfxi methods fail.

Radeon cannot be removed from a running system, it has to be blacklisted then you have to reboot. If the blacklisting/reboot step failed, then that's a fact, it failed, but I cannot tell you why it failed because it doesn't fail on debian at least not when I tested the stuff last. But then again, I no longer test amd fglrx because I bought 2 amd cards and they were obsoleted/support dropped by fglrx a few months after I got each, so now I simply won't buy any more amd cards for fglrx testing, period. I used to test the stuff now and then but amd / ati just made the entire process too unpleasant for a volunteer like me, who does not get paid (and who already knows to avoid amd fglrx like the plague on my own systems), to waste my time with anymore.

I can tell you that I have seen mepis users find that running sgfxi twice after reboot/blacklisting fixed the issue, why that is, I have no idea, since mepis is another system I won't test on anymore because it's just too different in unpredictable ways from debian. But I have seen forum posters note that running it a second time after reboot, for a total of 3, made it all work. That should logically simply not be the case, but it is, I've seen it a lot of times reported as a 'fix', it's not actually a fix, it's a fluke that happens to work for unknown reasons, but since it seems to do the trick for those users, what is there to add? Again, no real bug testing done, no debugging of the issue, so the issue remains as somewhat known as existing but that's about all.

On the bright side, we just added yet another nvidia feature to sgfxi, 64 bit ia32-libs detection/install/configuration, with narry a glitch, in a fraction of the time we've spent so far in this thread. nvidia stuff tends to work, and keep working, and when they add features, those also keep working, making supporting nvidia drivers a relative pleasure, not perfect, patches sometimes needed, but still fairly easy.

The trick here is simple: in the recent upgrade in sgfxi for nvdia 64 bit, we bounced around a few ideas, then I got a patch that basically handled the logic/code, and it went up a few hours later, live. That's an efficient use of volunteer programming time.

Debian's 'lack of firmware' is in the fully free main branch of the distribution, when you install debian it asks if you want to install non free sources, you say yes, it adds them, then you install the firmware, it's not rocket science. liquorix kernels ship with most of that too, by default.

Basically to me, the reason to run debian is specifically to exit, permanently, the 'reinstall version x y z every 6 months to keep up to date, hoping the upgrade process works. With debian you simple run upgrade or dist-upgrade and there you are, though you will often hit small glitches you have to fix, but they are almost always documented online, with easy fixes. To me it's way easier tweaking a few things every upgrade, major, than it is to reinstall my os every release or two. So anything that makes that upgrade process via apt fail should be considered as not debian, and any system, no matter what it calls itself, like lmde, that breaks that ability to upgrade fairly reliably, is not debian. I've always tried to keep all my scripts inside those parameters, even if they are not debian packages, they do not break anything in debian that will reduce the end users ability to upgrade, often quite the contrary is in fact the case, as with smxi or sgfxi.

Basically here's the deal: if say, the radeon remove failure happens on say lmde or xubuntu, but not on debian real, then it's a bug in lmde or ubuntu, period, and it's not my problem, but I will if required add fixes, if they are provided to me, to work around the bug, but I don't like doing it because particularly ubuntu tends to really change how they do stuff every year or two, and trying to track it isn't fun. So if you do two installs on the same machine, one ubuntu or lmde, the other debian testing, say, and everything works on debian, then the problem is in some ubuntu method, or an ubuntu method that clem pulled into lmde blindly, without considering future repercussions.

Just as an example, sgfxi was I believe created before jockey, the older ubuntu non free package / driver installer, I took a look at jockey's code, and laughed, because it was very poorly done and not nearly robust enough to work consistently, and then, lo and behold, it was replaced by something else, then I think something else again, not sure, what you use now, meanwhile sgfxi has just kept on working. All the original machines I developed sgfxi on are still running the same debian install, upgraded to current, one is 7 years old now, another 6. Never had to reinstall debian, never had to update/reinstall sgfxi, since it updates itself, heh. Also, to be fair, the native debian nvidia / dkms package set if you stick with debian kernels, works well for most users too, and sticks totally within the debian ecosystem, which is a big deal to some. dkms did not work so well on introduction, in fact, it was a disaster, but it got much better, now when you strip out dkms stuff in debian, the system is restored more or less to how it should be, so I no longer warn against using dkms, it works now, but only if you use the kernels/packages from the distro, and accept that reasonable limitation, since they are designed to work together. Dkms outside of that system is a very bad idea however, and basically will always lead to failures at some point if you use new kernels. But even that has improved, you can now add in patches, but I don't follow that part anymore.

So it's up to you, figure out what is causing the issue, then figure out how to fix it, in code or basic pseudo code logic, then tell me. Or don't. So far nobody from ubuntu/lmde has tracked down the issue and reported back, so it's not really anything I can do anything about without spending a lot of time on it. Not time I want to spend since I already use debian, and run nvidia, heh. Or radeon on old ati/amd cards, or intel. But never flgrx, in any case.

Figuring out what is causing the issue with ubuntu can be less than fun since it means tracking down subtle or not subtle difference between how debian does it, which should in general imo be considered 'the right way', and how ubuntu is experimenting with doing it.
Back to top

Re solving it, look up current ubuntu documentation for blacklisting radoen kms, and see if it's changed from what it was before, blacklisting has in fact changed consistently since kms radeon/nouveau was introduced, but I haven't seen or heard anyone in debian comment about something not working, so it looks like something in ubuntu, or something totally unrelated that is blocking the blacklisting, who knows.
Back to top

When I get some free time, I'll try to search within my newly installed Xubuntu, or search from a boot up of the virgin Xubuntu 13.10 from my flash drive. Or I'll search the internet based on this. But nothing recent is immediately coming up on the web.

The Ubuntu documentation only speaks about manually blacklisting.

OK on debian and the firmware issue. It's been a while since I tried installing straight debian, and the problem at the time was that there was no immediate wifi support, so I could not add/download firmware. But that was a long long time ago, and I could hammer it out now a number of ways.

I'm assuming that not having dkms initially installed (not installed on Xubuntu 13.10 by default) was not the issue - was not related to the blacklisting issue.

Thanks again. Very informative posts.
Back to top

Obviously, EVERYTHING sgfxi does is going to be the 'manual' way, it's never going to be the gui tool way, all sgfxi is in essence is a bunch of manual steps connected via a bunch of tests and conditions and escape points. That's exactly the problem, ubuntu keeps trying to hide the 'manual way' from eyes so it's always a challenge to see what their stuff is actually doing. The very first iteration of sgfxi in fact was primarily based on the debian non free driver wiki page, which itself recommended in general against using the debian packaged driver in somewhat veiled terms, that was a long time ago.

One thing I note with the ubuntu directions is there is no place where blacklists are created prior to the reboot step, which to me is highly suspect, and points to an unknown thing that ubuntu is doing now, and would certainly explain why something isn't happening.

And, unless ubuntu has done something truly horrible, everything the gui does is 'the manual way' too, only wrapped in a gui.
Back to top