| Author |
Message |
|
|
Post subject:
 Posted: Aug 19, 2008 - 03:39 AM
|
|
Joined: Nov 28, 2006
Posts: 4303
Status: Offline
|
|
| Last I tested this stuff it all seemed to work as expected, new kernel, driver installed to new, restart , all fine, but you never know, bugs might creep in. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
 |
|
|
|
Post subject: sgfxi doesn't work with 2.6.26-5.slh.3-sidux-686
Posted: Sep 13, 2008 - 12:01 PM
|
|
Joined: Sep 13, 2008
Posts: 2
Location: Lazi, Siquijor, Philippines
Status: Offline
|
|
|
|
|
|
|
|
|
Post subject: RE: sgfxi doesn
Posted: Sep 13, 2008 - 12:30 PM
|
|
Joined: Sep 13, 2008
Posts: 2
Location: Lazi, Siquijor, Philippines
Status: Offline
|
|
-SOLVED-
It was an error with my kernel upgrade. Fixed with:
apt-get update && apt-get install linux-image-2.6-sidux-686 linux-headers-2.6-sidux-686
Thanx alot to "etorix" from the sidux IRC. That was actually a fast response. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: sgfxi doesn
Posted: Sep 13, 2008 - 07:25 PM
|
|
Joined: Nov 28, 2006
Posts: 4303
Status: Offline
|
|
the actual file that would have showed the problem would have been the smxi log. I assume you may have been installing a kernel just at the moment kernels were changed, thus, you got one part, probably the linux-image, but between the time it downloaded and the linux-header file was requested, that file was no longer in the repos. I'm assuming that's what it was anyway. There's always going to be a person or two who gets hit with this transitional issue, at least I think there will be, unless that problem has been handled.
smxi of course always installs the required files, so if it was just a missing header package from a manual kernel upgrade, that's why. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject: usability request
Posted: Oct 25, 2008 - 10:08 PM
|
|
Joined: Jan 01, 2007
Posts: 23
Status: Offline
|
|
This is more a little usability-request then about bugs or features...
1.
When after kernel-update and DU with smxi I came to graphics driver install I forgot about the whole fglrx/siduxkernel thing. So I chose the wrong driver option - my error. Related message came up, and script exited.
New users perhaps dont know about sgfxi and start smxi to go through the whole script again towards the graphics driver section.
Perhaps you could (a) repeat the warning message that appears at the very beginning of smxi about fglrx/siduxkernels and (b) instead of exiting the script catch the error message and ask user something like "Driver wont work : 1-choose another or 2-exit script?"
2.
Similar thing in submenu misc-advanced-apttype: option 3-continue is clear, option 4-exit is explained as if I could think about it and exit only that very submenu. Instead, the whole script exits. So the explanation fits better to choice 3 and choice 4 should read "exit smxi".
Just my ¤500000000000
regards, der_bud |
_________________
Du lachst? Wieso lachst du? Das ist doch oft so, Leute lachen erst und dann sind sie tot.
|
| |
|
|
|
|
|
|
|
Post subject: RE: usability request
Posted: Oct 26, 2008 - 08:02 PM
|
|
Joined: Jul 07, 2007
Posts: 178
Location: Manorville, New York
Status: Offline
|
|
| der_bud FYI: smxi -kwidt brings you directly to the menu that has the graphics installer. No need to go through the whole script again. smxi -h brings up the help screen so you can look at options. |
_________________
sidux Gaia 64 - ECS 6100SM-M AMD64 AthlonX2
sidux Gaia 32 - Asus P4PE-X P4 Nvidia
sidux Eros 32 - Asus P4PE-X P4 Ati
sidux Gaia 32 - Thinkpad G41
sidux Eros 32 - M2N32SLI-WE AMD64 AthlonX2
|
| |
|
|
|
|
|
|
|
Post subject: RE: usability request
Posted: Oct 26, 2008 - 08:50 PM
|
|
Joined: Nov 28, 2006
Posts: 4303
Status: Offline
|
|
der_bud, one of the problems with fglrx is that its state is so inconsistent that I have ended up having to create a near labyrinth of convoluted options and conditions in the smxi graphics installer library to handle a variety of ever changing possible fglrx conditiions.
I finally reached a point where I decided I had to simply let this go. Basically, supporting fglrx beyond the methods I do now involved constantly altering and updating such warning messages and conditions and test results, to the point where it really gets kind of silly.
So I stopped it where it was. Yes, fglrx should have new warnings, but the point of finally stopping it was to stop the process of continuously updating and changing the data being handled for the user, options, messages, and so on.
I handed the sidux user community the choice of stepping up and helping in any way at all, and the fglrx users completely failed to volunteer any effort or energy on their own on even a partial, temporary basis.
This is unfortunate, and it's not how I would like things to go, but in fact, smxi / sgfxi users are actually given this information now, already:
smxi, pre dist-upgrade warnings, for now many months, have included this information:
Quote:
------------------------------------------------------------------
2. 2.6.25/26 kernels: ATI fglrx now only works with Debian sid kernels, not sidux kernels.
You can install Debian sid kernels using smxi. Check sidux.com hardware forums for details.
In a sense, I could add this warning as a separate option that fires one time for new ati card users, but again, it's exactly this type of continuous change in fglrx support that I had to finally put a stop to.
If slh kernels continue to be built using features that fglrx doesn't support, and if fglrx continues to have these bugs that make running on valid kernel configurations fail, this wont' change, but if fglrx fixes this bug, it could start working literally tomorrow, which would mean that, once again, I'd have to go in and update yet another warning / alert feature, remove old ones, etc. This is exactly what I decided I would no longer do. Likewises, if the fglrx distributed debian sid installer, which is part of the ati / amd delivered .run package, and which used to actually work quite consistently, suddenly starts to work again, likewise, any hack around that would need to be removed, and the endless games would begin again.
Also, if you try to install the fglrx driver onto an slh kernel, and ignore the alerts and warnings, sgfxi itself contains an error handler which will spit out a failure message then exit, which is quite easy to maintain by the way. Hopefully that feature is still working, I'll check that though.
Making smxi interact with sgfxi is NOT trivial, and it's basically roughly at the maintainable limit as it stands now, no further complexity will be introduced because the cases are as they now stand just at the limits of what is practical to do with bash and interactive script modules.
fglrx can and has changed at a moments notice, to track all that nonsense takes dedication I do not have, and which sadly no current sidux or debian ati/amd card user has either. I don't even own that card, though smxi/sgfxi contain fairly complicated testing options that let me emulate some parts of that process without having the hardware, but that's also as complex as I can deal with as it now stands.
The debian sid installer in the fglrx run package was until recently allegedly under new management, with a new owner, who, sadly, only in our dream worlds, was to keep up with changes and deliver working installer system for debian deb creation. This, like all other fglrx fantasies, quickly was revealed to be nonsense, the developer quickly grew bored with trying to make fglrx debs work and install month to month, and gave up. So did I.
Allegedly, the straight fglrx installer, no debs, works better, and more reliably, but given the amount of work that went into creating the solid and integrated fglrx installer in sgfxi, I wasn't willing to just dump it in favor of another method.
Also, I several times asked the fglrx users, especially the young guys who follow that junk, to come up with a fully worked out logic for using the direct installer, and, again, like clockwork, they weren't willing to spend a single minute of their time helping the sgfxi fglrx users, which was the point said, ok, this is enough, I'm stopping, unless or until I get paid serious development dollars to maintain and deal with something I already know will never work reliably in sid.
In the larger sense, here's a way you can see if fglrx stuff is going to actually start working: ATI/AMD stops their asinine monthly release cycle, which basically seems to guarantee that virtually every driver release is released before it actually works. compare this to the nvidia method, which involves public beta releases, solid, frequent patches released by the developers to let the previous drivers work on new kernels until the next release is put out, which happens once it WORKS.
But, again, note this: fglrx can start working at any moment, any time. The debian sid installer maintainer (who is not an amd employee, is a volunteer I believe) can at any moment stop pretending and either quit, letting someone else do the job right, or start tracking fglrx actively again.
My personal preference there is that AMD stop allowing non working code like the debian sid installer scripts to be distributed with their installer, ie, that they actually test all installers they get and distribute, and remove any that do not work. This is, again, totally basic good practice, ie, test your crap before you allow it to be released, don't release because it's almost the end of the month and you haven't gotten 8-10 out the door yet, which is what ati currently does.
point 2 is good, exit smxi is a good suggestion. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject: RE: usability request
Posted: Oct 27, 2008 - 06:49 PM
|
|
Joined: Dec 04, 2006
Posts: 640
Status: Offline
|
|
|
|
|
|
|
|
|
Post subject: RE: usability request
Posted: Oct 27, 2008 - 08:00 PM
|
|
Joined: Nov 28, 2006
Posts: 4303
Status: Offline
|
|
| 2.0.4 is added as default, 2.0.2 still there if you use -V option. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject: RE: usability request
Posted: Oct 27, 2008 - 10:18 PM
|
|
Joined: Dec 04, 2006
Posts: 640
Status: Offline
|
|
h2,
Thank you, as always. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: usability request
Posted: Oct 27, 2008 - 10:31 PM
|
|
Joined: Nov 28, 2006
Posts: 4303
Status: Offline
|
|
| thanks for the direct download urls, as always, the more people help the easier this stuff is to keep up to date, and little things like links to downloads means it's that much less stuff I have to worry about tracking. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject: RE: usability request
Posted: Oct 28, 2008 - 02:18 AM
|
|
Joined: Dec 04, 2006
Posts: 640
Status: Offline
|
|
| No problem. In the future, would it help you if you had the 64-bit direct download URLs as well? |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: usability request
Posted: Oct 28, 2008 - 03:15 AM
|
|
Joined: Nov 28, 2006
Posts: 4303
Status: Offline
|
|
no, that's all automated, just changes a little string, but on the other hand, it doesn't hurt, just to make sure they haven't changed the url/path/file name, which happens now and then.
thanks |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject: RE: usability request
Posted: Nov 18, 2008 - 02:49 PM
|
|
Joined: Dec 02, 2006
Posts: 1707
Location: Germany / NRW
Status: Offline
|
|
last night I noticed that smxi shows the free space of all relevant partitions. At this point it seems a good idea to add a "apt-get autoclean" command.
1. Apt-get autoclean (new)
2. continue
3. continue without dist-upgrade
4. quit
It's not a must have, but yesterday I saw my /var partition close to full and had to kill smxi to get rid off some not needed *.deb_s before I could select "2. continue". To me it seems the right place to add "apt-get autoclean" here (if possible without hassle). |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: usability request
Posted: Nov 25, 2008 - 02:22 AM
|
|
Joined: Nov 28, 2006
Posts: 4303
Status: Offline
|
|
smxi has apt-get clean and auto-clean already, in cleanup. I'm reluctant to add more options in the main dist-upgrade section, although your suggestion isn't bad, but it's a somewhat dangerous thing to start adding too many primary level options, at some point, it's ok if users actually learn the tools I think, and use them.
However, I'm glad you noticed the main partition free space output, that was put there for this very reason, to alert users about partitions that are getting dangerously full. If I was going to be really cute, I'd mark anything over 90% full in RED as well, but that would require a total rewrite of that logic. inxi by the way also has the partition tool, slightly enhanced, inxi -P shows only that data, inxi -DP shows full disk information and partition data for main partitions. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
