Recently I've had to try and fix a borked system (something that went wrong after installing some new xorg packages,not related directly to Liquorix kernels as far as I cant tell) and observed that the latest version of the script for some reason got stuck,whilst a previous version that I also had on that computer still worked-
without digging in all the possible quirks of that (non-debian) system which could have triggered the issue,is there any disadvantage in having several versions of the script on one computer,obviously assuming that one doesn't try to use them at the same time?
Does the script auto-detect older versions,aside of the auto-update feature?
Back to top

If you use sgfxi in any directory other than the /usr/local/bin directory of the operating system running sgfxi, I will not support you, period. if you have it in /usr/local/bin you cannot have multiple versions running on your system. Oh, with one exception, right, /usr/bin for arch users, but it's the same thing, if it's not in /usr/bin for arch users, I will not support you.

I've had too much wasted time with people putting stuff here or there at random then not realizing that their path variables mess up which version is updating.

So if you want support, you are going to use one and only one version of sgfxi, in the directory /usr/local/bin

Since there is no, zero, zip reason to run sgfxi, which updates itself every time it runs if there is a newer version, with multiple copies, there is no reason for me to consider any support request that does not follow this simple rule.

smxi is so strict that if your try to do that, it will mv itself to /usr/local/bin forcefully, no matter where you put it.

Up to you. If sgfxi is not in /usr/local/bin, there is no support, and if you have more than one copy, you are I think unclear about how to use sgfxi, since there is nothing to be gained by having multiple copies beyond the confusion you found.

If in doubt, as root, run: updatedb
then do: locate sgfxi
and delete all copies not in /usr/local/bin unless of course you have several operating systems and one is mounted in another one, with its version of /usr/local/bin, which will not be in your system path so it doesn't matter.

If you are talking about different operating systems each having their own /usr/local/bin/sgfxi, obviously that doesn't matter, since only one of them per os will be in the system PATH.
Back to top

Thanks for the heads up:yes,admittedly I was indeed messing a little with different versions of sgfxi,by symlinking them from the /Downloads directory to /usr/local/bin.
To clarify,I was trying to fix one of those non-debian systems that you don't trust so much (we've discussed this before,I know-it's just that I have stuff there that I still have to move to Debian,so I try to keep these Mint/Ubuntu systems going somehow) that got a broken X server after an update:knowing that these systems (and the ATI proprietary driver as well) have their quirks, I've attempted to use different versions of the script to see if it made any difference in rescuing the OS.

I know the quirk was not in the script,more likely in the system itself and/or the not so reliable ATI drivers (about which we've talked too,and from my limited experience with them,I can only agree),I was just trying to get out of the issue:in the end I did manage to at least reinstall the old ATI driver,but the X server was still misbehaving,so I just decided to overwrite the installation from a rsync backup and then update the system after putting on hold all xorg related packages.

While we are on this: which version of the available ATI drivers will sgfxi by default try to install for a given kernel?
The most recent one,or the one available a the time that that particular kernel was installed?

Edit:the above sounds like a confused question,but the fact is,so far I've been ending up with an higher version of the ATI driver than the one listed with sgfxi -L -f .
I've just finished wrestling with my spare Mint install that I keep only for trying stuff,and whilst I was expecting a 13.x driver according to the sgfxi -L -f info,I've ended up with a 14.x driver,unless I'm not completely off track as far as version numbering goes with ATI drivers.
Back to top

I forget to update the -Lf data.

Basically sgfxi always, every time, does checks and tests when it starts up, each time I add a new driver, I try to verify that the driver/kernel/xorg versions work, i assign drivers to xorg versions, to kernel versions, then after it passes those tests, it goes to the patching function, which checks specific drivers against specific kernels then applies patches if needed.

So the answer is, I think:

sgfxi is always current when it runs, and the tests it runs are as of the last drivers added to it.

Sometimes I guess about xorg/kernel support for amd since amd does not release any meaningful information about kernel/xorg support, what they claim often has little to do with reality.

sgfxi also checks the card version id numbers, and assigns it a status of current, legacy x, or non supported.

So there's no advantage to using different versions of sgfxi, and you'd have to run them with the autoupdate flag off option in that case or it will just update itself.

The things that did change with sgfxi and mint were improved but certainly not ideal handling of their boot system, which was for a while falsely identified as systemd by inxi because for some inexplicable reason clem decided to ship systemctl binary without systemd running, which made sgfxi fail to start/restart the system. That's been corrected.

There were some other things like that with mint, the result of which was that the latest inxi now has a steadily expanding --debugger option, which now even auto uploads the gz file to my servers.

I'm adding more stuff to it each issue report to try to let me track down failures with less lost time on my end, at once, but the number of things that mint can screw up and does, is very large.

One of my favorite things I've seen for example is the broken xorg generator, which creates like, 7 copies of the same device and monitor, so of course, when those load, xorg reports failures after the first is loaded, since each one fails to load, with weird and unpredictable results. I have checked debian's xorg generator and it is NOT at fault, so that comes from either clem's mind or ubuntu's hacks.

Other issues that are not resolved is some type of jockey/dkms non regular behavior that makes nvidia / fglrx try to reinstall themselves every boot no matter what sgfxi did to try to remove anything related to video drivers, that issue has never been tracked down and debugged.

On the bright side, I have solved the amd driver issue for now, we've imposed stability on their random path/filename generator and no longer use their silly methods, now all the fglrx drivers have normal version numbers, which means all the 14.x and later fglrx will take full advantage of all the tricks etc that sgfxi can do with sane driver file numbers, ie, what it has done with nvidia since almost day one.

Whatever a live inxi shows you as latest driver when you start it is the latest it has, the -L d option also shows the latest since that's generated off the server sgfxi itself every hour. The -Lf is up to me to remember to update, i always forget, so it's the least reliable. Updated it now though.
Back to top

Thanks for the explanation,I can see how much of an effort must be for you to deal with mint,which adds another layer of weirdness on top of what ubuntu already does to debian (in order to "fix" who knows what),then AMD tops it off with their whimsical attitude towards Linux drivers-must be kinda interesting for you to figure out all this..

Nevertheless,they are very popular distribution which for most of us have been the first step in Linux,so I think it's somehow worth trying to support them.

I've just finished another experiment,updating Mint to the latest 3.13-11.dmz.3-liquorix-amd64 kernel of the past repo,and it has been kinda of an ordeal,as I've first tried 3.14 from the main repo and it definitely doesn't get along with mint and/or the current ATI driver (confirming your opinion of their laziness in updating their stuff),as a result the fglrx driver could not be removed by simply running sgfxi with no options,and the driver could not be reinstalled on 3.13-11.dmz.3-the system was actually broken as far as the X server goes,so I've resorted to some very agricultural way of cleaning up,namely purging all kernels and headers except the one I was using,removed every trace of fglrx and amdcccle by hand with find -exec rm,then reinstalled 3.13-11.dmz.3-liquorix-amd64 and run sgfxi again on it,and it finally worked.
You may be interested in knowing that MDM still respawns during the install even with the latest sgfxi version and using sudo su - ,but all that it takes is Ctrl+Alt+F1 to get back to the installation,so who cares in the end.
On the bright side,apparmor works with this kernel and so it does my CPU frequency scaling applet,which didn't with 3.10-19.dmz.1 .
Back to top

the sgfxi --debugger has been showing me some interesting data, I've been getting more from Mint, odd that, I think some of their devs or something are submitting anonymous --debugger data sets.

I've been adding more and more stuff to the debugger, including having it autoupload the gz debugger data to the server automatically, a major step for somewhat 'tech challenged' users that can be drawn to mint/ubuntu.

That is using the same xiin.py debugger engine that inxi uses to upload it, it took me a while to realize I could do that, lol, but I caught on eventually.

What it showed me was my suspicion was right about syntax / directory name changes to dkms, luckily however the changes are easy to handle.

So the latest sgfxi now should be able to remove the dkms stuff at least in one area.

As for running fglrx and any other kernel than stock distro, no you cannot do that. Same for nvidia though, the distro driver package and hte distro kernel and the distro xorg version should be considered as one single entity with 3 parts, not 3 things.

If you use something like liquorix you MUST use the latest drivers. sgfxi can now deliver the actual latest fglrx driver as well, but keep in mind their release cycle, ie, slow, so you can probably run 14.4.2 on 3.14 kernel, or 3.13, but no newer kernel.

I'm adding data stuff to the sgfxi debugger as I think of it, the list is not bad now in terms of figuring out what is actually going on with user systems.

dkms may have more pieces scattered around, I can't say, I can for sure say the apt package for those drivers is BROKEN in ubuntu and mint, because if you do a purge of a driver, or remove, dkms should not be still trying to work, it took debian a long time to fix that bug, and they finally did, I have no idea what jockey/ubuntu packages do, probably not pretty.
Back to top

It's easy to say something is 'worth' it when it's not your time that is being wasted by constant randomness and badly executed 'solutions', year after year. This is a constant misconception in free software, ignoring the actual value of the dev's time completely, it's a major problem in free software, that the recent openssl security breach showed really clearly, expecting volunteers to run for profit enterprises for free, as if that's somehow normal or practical.

The way groups like ubuntu or mint can help is by dedicating their developer resources to such problems, that means time, energy. That's what the prime developer of the real LMDE, subsequently massacred by mint and clem, did, he was in constant communication with me, and came up with tests and solutions to problems. Apparently clem feesl it's fine to waste my time and cost me a lot of money supporting his for profit system, for free. That type of expectation doesn't merit support, it merits something else, which is why I'm amazed I didn't ban mint a few months ago.

In fact, it's not actually 'worth it', since I lose my time, my life, and nobody pays for that loss. I'm just stubborn enough to not totally give up on ubuntu, but I think it's more because exposing sgfxi to poorly done operating systems makes it stronger when it comes to supporting debian, and real apt, so there is a bit of a benefit there. I thank heaven for my long ago decision however to NEVER support ubuntu on smxi.

I have no interest in for profit systems, beyond a mild technical one, if people want full support, they they can switch to a fully free distribution that follows the rules of apt religiously, Debian, that is.
Back to top

Well,I see your point-can't do nothing but agree with with what you've said above.

I probably meant "it is an useful thing for ubuntu/mint" users that you support them,rather than it is "worth trying to support them".

Thinking of it,in my opinion Mint should in theory be interested in some kind of cooperation with the Liquorix project,given that it fixes stuff that their own distribution breaks compared to the vanilla kernel.

I mean,I know for a fact that on my computer suspension to ram works with a mainline kernel,doesn't work in Ubuntu/Mint,works in Debian and with Liquorix kernels on Mint:shouldn't they interested in knowing why?
Back to top

"shouldn't they interested in knowing why?"

Shouldn't clem have investigated sgfxi to make sure that there weren't issues related to mint before telling his users to use it? Shouldn't they have contacted me and talked a bit on forums/irc before making such a claim? Shouldn't LMDE NOT be trying to run a debian frozen pool monthly or so upgraded distro plus mutated ubuntu/mint parts, thus creating a situation where NOBODY can help an lmde user with issues since it's not debian and it's not mint and it's not ubuntu at that point, but just some weird mutant that nobody could possibly support? Shouldn't LMDE actually be upgradeable instead of disposable, ie, apt works and isn't broken by random non debian methods and packages? Shouldn't LMDE remove the DE from its name, which is an insult to debian, and replace it with ME, Mutant Edition?

Remember, there is one simple test to see if a distro is actually debian: continuous upgrades from the debian package pool over years. Any distro that can do that is debian, for example, antix (testing), siduction (sid), crunchbang (not sure which)), and so on are all true debian with some helpful packages added in via their 3rd party repos.

Hopefully the internals of the cinnamon project do not suffer from such issues, since that seems like actually a good idea.

A well run distro should do lots of things, that's in fact why I use debian, it just oddly enough does those exact things, and it's why I support Debian, it's predictable and reasonable, relatively speaking.

Liquorix, run by damentz, pays attention to its users, and has always been made to scratch the itch damentz has for the best desktop user experience he can generate, that's why he tests stuff and pays attention to user feedback on these forums and irc etc, liquorix, like inxi/sgfxi, is a dynamic project that responds to user needs, doesn't break debian, and so on.

There are some small benefits to sgfxi trying to support mint/ubuntu however, as indicated, in general, the sloppier the problem set a program is faced with, the more robust its methods have to be. Before mint / lmde saying a while back to use sgfxi, for example, I never needed a debugger, though I was aware of long lingering issues, mainly with ubuntu based systems, that I was never able to figure out because users simply have no idea what their systems are doing internally so could not be helpful, with some rare, and welcome, exceptions here and there.
Back to top