sidux.com

General Support - smxi script: information and updates: maintenance script

h2 - Nov 30, 2006 - 05:06 PM
Post subject: smxi script: information and updates: maintenance script
This thread is for letting you know the latest updates to smxi

To start: script installation
The zip download/extract method is the easiest way to get these scripts installed:
Code:
cd /usr/local/bin; wget smxi.org/smxi.zip;unzip smxi.zip;smxi

Just copy and paste that into a root terminal/console, and hit enter, and it will install all the core script components (smxi, sgfxi, and svmi), ready to go.

Note: smxi and sgfxi need to be started out of X, in console, but don't worry about that, they will let you know then exit if you do start them in X. svmi can be started in X, as root.

script home pages
smxi home page
sgfxi home page

Remember, if you forget the home page or whatever, just google the script name (smxi / sgfxi) and you should get the home page on techpatterns.com.

Here you can get various script first time installation options, including the zip method listed above, plus more information about each script. (warning: the home pages, like this post, tend to be signficantly out of date, but I do try to keep the basic features listed updated when needed)

smxi, sgfxi, and svmi documentation
Recently added, besides the information you get in the sidux manual pages, there is now are now official script documentation pages. Currently they explain some common options, some advanced hard setting of options, developer tricks and tools.

You can read about the main useful options here:
smxi options
sgfxi options
svmi options

Bug Reports - Feature Requests
Please post bug reports / and / or feature requests either here, in the bug report / feature request thread, or use the script home bug threads:
smxi / sgfxi/ svmi bug reports
smxi / sgfxi / svmi feature requests

Debian Netinstall/business card install
Here's a nice how-to on the process of running smxi on straight Debian, whatever flavor you want, building from the initial business card install, or netinstall.

smxi irc channel: irc.oftc.net #smxi
With factoids, using Amy bot. I'll put anything I can think of in the factoids. For category list, do: !categories
From beginner to advanced levels, including dev information. Most people will want to check out the !main section first. Be patient if posting bugs or questions, I'm not tracking this 24/7, and I will usually be logged in during the day, pacific usa time (about 18:00-05:00 gmt). If you don't see an h2 present, I won't see your question, so wait until an h2 is there to post, or use the factoids or ask someone. Any good questions will be made into factoids themselves.

Why Init 3? Why no GUI?
Read this thread for explanation of why sm will never be a gui app, and why dist-upgrades should never be run in x/kde/gnome.

Basic smxi / script philosophy
While responding to some user feedback, I ended up creating what is basically the core smxi mission statement and philosophy. I think my long comment in that thread explains how smxi works and is developed, the ideals that drive it, etc, quite well.

Some Option stuff...
Please check the available script options by starting the script in your console with this (depending on which script help menu you want to see):
smxi -h
sgfxi -h
svmi -h

You don't need to be root, and you don't need to be in init 3 to view the help options.

See option documentation for more complete information and explanations.

Please see the script forums homepage for up to date options list.

Code:
for smxi: The following can be run in X/kde:
-h Prints this help menu.
-v Prints version and system information, including distro version,
  . current kernel, apt update and dist-upgrade last used, and last use of smxi.
-W shows last warnings or configs. Requires arguments: -W w (show only
    warnings); -W c (show only configs), or -W wc (show first warnings, then
    configs). If you start smxi as root with -W option, it will also update the
    information, otherwise it uses the last ones downloaded, if present.

h2 - Dec 01, 2006 - 02:04 AM
Post subject: RE: du-fixes information and updates
Version 4.6.0: Added sidux support in all modules and main script. Abstracted away from Kanotix specific to more generalized, and added basic sidux version detection.

Also updated all techpatterns.com directories to reflect this more generalized schema, now instead of everything being located in techpatterns.com/downloads/kanotix/... it's in techpatterns.com/downloads/distro/....

Also updated all backend support stuff on techpatterns.com.
h2 - Dec 01, 2006 - 11:39 PM
Post subject: RE: du-fixes information and updates
Version 4.7.0: Added option to setup sidux /etc/apt/sources.list and add new sidux-keyrings.

Basically, it's just this: http://sidux.com/PNphpBB2-viewtopic-t-3.html
scripted.

Currently this option will only be offered to script users if you start the script with the -X option. Of course, remember, to get this new option, you must first update the script, then restart it. You can updated it by starting it with the -u option, then exit the script with ctrl+c, then restart it like this:
du-fixes-h2.sh -X

This will give all kanotix users the option to update system to sidux sources.

During your first dist-upgrade, you will be asked if you want to keep your 'distro' file. Answer 'y' to that, and it will update many system internals to reflect the new sidux packages and system configs.

Hope this is helpful to early adopters.

Remember, this is very early in sidux testing, so the new sidux apt repositories are fairly rough. But since slh maintained the kanotix ones, I have confidence that the new ones will be pretty solid from the beginning.

Ok, welcome to sidux kanotixers.
hubi - Dec 01, 2006 - 11:52 PM
Post subject: RE: du-fixes information and updates
h2,

just a stupid question. Do I understand it correctly, that I can upgrade your script by doing
Code:
sh du-fixes-h2.sh -u
?

I have yesterday's snapshot of your script on /root. That option would be very conveniant.

hubi
devil - Dec 02, 2006 - 12:00 AM
Post subject: RE: du-fixes information and updates
hubi,
yes, that will update it, after that kill with ctrl -c , then call the script with -X , that will promt you to change sources to sidux.

greetz
devil
hubi - Dec 02, 2006 - 12:09 AM
Post subject: RE: du-fixes information and updates
devil,

I suppose I can skip -X, the first thing I did on all boxes, was changing the sources.list (kicking kanotix and related, adding sidux). Just after that I ran h2's script. So transfer is done and -u sufficiant?

The publishable part of my sources.list looks like that:
Quote:
# See sources.list(5) for more information, especialy
# Remember that you can only use http, ftp or file URIs
# CDROMs are managed through the apt-cdrom tool.

# Unstable
deb http://ftp.hu.debian.org/debian/ sid main contrib non-free
# deb-src http://ftp.hu.debian.org/debian/ unstable main contrib non-free

# Testing
deb http://ftp.hu.debian.org/debian/ testing main contrib non-free
# deb-src http://ftp.hu.debian.org/debian/ testing main contrib non-free

# Experimental
# deb http://ftp.hu.debian.org/debian/ experimental main contrib non-free
# deb-src http://ftp.hu.debian.org/debian/ experimental main contrib non-free

# sidux
deb http://sidux.com/debian/ sid main contrib non-free fix.main fix.contrib fix.non-free vdr

# sidux temporarily
deb http://sidux.com/repo/transitional/ sid main contrib non-free
deb http://sidux.com/repo/compat/ sid main contrib non-free
hubi
phen - Dec 02, 2006 - 12:58 AM
Post subject: RE: du-fixes information and updates
what do you mean with "updating the h2-script"? after i startet it, it looked up a newer version and dl'ed it and restarted - am i wrong?
hubi - Dec 02, 2006 - 01:09 AM
Post subject: RE: du-fixes information and updates
phen,

so it works without the -u option? Even better Very Happy

Just getting customized to all the new options,
hubi
h2 - Dec 02, 2006 - 01:33 AM
Post subject: RE: du-fixes information and updates
The script always updates itself if there is a new version, but if you are trying to use a new option it won't work until you restart. -u just forces update no matter what.

The script will always move to /usr/local/bin no matter where you store it, and that's where all its modules will also be found, so unless you want to keep an older version around, there's little point in installing anywhere other than /usr/local/bin

I would recommend running it with the -X option at least one time because that will also turn off some kanotix specific updating stuff as well permanently.

If you have already updated your sources.list manually, the script will detect that and not try again, but it will set a preference to skip kanotix keyrings install etc.

phen, no you are right, that's exactly what it does, downloads latest version, checks to see if it's newer, restarts if it is.
hubi - Dec 02, 2006 - 01:42 AM
Post subject: RE: du-fixes information and updates
h2,

great info on a massive script.

thx,
hubi
acheronta.movebo - Dec 02, 2006 - 11:33 AM
Post subject: RE: du-fixes information and updates
Hey h2,

thank you for your script. Never used it in former times. Works very fine.


hubi,

our FF-Dialogue-Problem is solved. Very Happy
oduffo - Dec 02, 2006 - 02:33 PM
Post subject: RE: du-fixes information and updates
h2,

I just used your script - for the first time ever - to switch to sidux and to install a new kernel. Everything went smoothly. No problems at all.

Thank you very much for a great tool.

Gruß
oduffo
eislon - Dec 02, 2006 - 08:03 PM
Post subject:
the h2 script worked perfect for me today, all repository's have been changed to sidux.
and I got a new kernel running.
Oddball - Dec 02, 2006 - 10:30 PM
Post subject:
This is my first post here.

I also used h2:s script to transfer to sidux, I think it went all right but I can't really see any difference from before (Kanotix) and I don't really understand whats written here before, so excuse me for the following question.

How can I see that I'm running sidux and not Kanotix?
Crest - Dec 02, 2006 - 10:47 PM
Post subject:
I think actually it's more some sort of 'internal' change which is needed for future updates, not so much what you can see everywhere. And I'm probably right that the change can't be that big since also Kanotix is/was Debian Sid right now.
jbs1136 - Dec 03, 2006 - 10:36 PM
Post subject:
h2,

thanks for the script. I just did a fresh install of kanotix RC4, downloaded your new script and ran it. Said yes to everything and now have sidux up and running.

thanks!!!

john
paleoflatus - Dec 04, 2006 - 03:54 AM
Post subject:
My thanks to h2 and all of the team, too.

I'm no expert, but I've run the script, upgrading and switching to sidux - it's as smooth as silk!

Also added Prometeus to my beryl desktop and I'm still wiping up the drool off my chest!

It's a privilege to be associated with you all.
h2 - Dec 04, 2006 - 09:33 PM
Post subject:
Version: 4.7.4: added new slh 2.6.18.5-* kernels.
h2 - Dec 05, 2006 - 12:14 AM
Post subject:
Version 4.7.9: Added more robust x,kdm,gdm as well as init level test to initial check routines.

I did this mainly for Debian etch and sid users who want to use the script, since Debian defaults to starting kdm/gdm in runlevel 3 the past test would not have helped them.

Now should correctly detect and shutdown kdm, gdm, xdm if those are running in
init 3, as is the default for Debian installs.

Also explicitly tests for presence of kdm,gdm, and xdm after init 3 shutdown.

This should help resolve future kde upgrade in x issues I think.
Nishtya - Dec 05, 2006 - 02:28 PM
Post subject:
h2,

I have installed Etch from netinstall on two machines, one to track to stable and the other as a base for sidux if I screw up my Easter-to-sidux Smile - you can never have to many testbeds.

When I saw debian's run levels 3-5 all had kdm started, I used the handydandy ksysv init editor to remove kdm from level 3. Is this okay or should I put it back and let your script shut kdm down?
h2 - Dec 05, 2006 - 05:19 PM
Post subject:
Personally, I can not understand why debian chooses to start kde in runlevel 3, what then is 5 for?

However, in answer to your question, after the latest fix, it no longer should matter which you do. I always set my debian installs to start kde in init 5 first thing, otherwise it's too hard to remember if it's running or not in init 3.

By the way, I'm very happy to see some debian users testing this stuff, and will have to continue modifying the script to handle that scenario, which is fairly new for me, but welcome.

If changing runlevels for gdm/kdm, however, turn off both 3 and 4, not just 3, and leave 5.

I'll probably add an installer option for debian users to install all the sidux specific packages automatically if the user wants them, such as fix-fonts, sidux-scripts, etc.
h2 - Dec 05, 2006 - 10:34 PM
Post subject:
script module du-fixes-clean-up.sh version 1.2.0: added cleanup option to remove transitional kanotix to sidux packages. Only run this option after your next dist-upgrade, since these packages will not be installed until you do your first full dist-upgrade with sidux sources today or later.

That option is available in du-fixes-h2.sh in the misc tweaks section.
h2 - Dec 06, 2006 - 09:59 PM
Post subject:
version 4.7.14: added automatic upgrade to sidux graphics and also runs the grub updating tool so you can get graphic grub back automatically.
h2 - Dec 08, 2006 - 08:31 PM
Post subject:
Version 4.7.22: updated stop splashy to handle new splashy garbage, now that will again shut down splashy as expected.
h2 - Dec 09, 2006 - 12:03 AM
Post subject:
Version 4.8.0: Finally, had to do it: Removed support for Kanotix users, now Kanotix users must switch to sidux if they want to use du-fixes-h2.sh.

All Kanotix users will be given the option to switch to sidux sources and sidux every time they try to do a du, that question will now no longer only be asked one time, it will be very time until they stop using script or switch, the script can no longer support Kanotix since its' not clear what base kanotix will be using any longer.

Sorry Kanotix users, I was hoping to maintain support for non sidux switching for a few more weeks but it's getting too hard.
h2 - Dec 09, 2006 - 02:58 AM
Post subject:
Version 4.9.0: added basic debian support. Script will test for presence of /etc/kanotix-version or /etc/sidux-version, and if those are absent, and if /etc/debian_version is present, will give user the option to update to sidux. Note: this is experimental, and I can't guarantee anything.

Also the script will test, after the first dist-upgrade, for all sidux components, or most non-livecd ones, and install any ones that are missing.

You may not want all those packages, so read the apt stuff carefully, for example, if you don't use isdn, don't bother installing the isdn config stuff.
h2 - Dec 09, 2006 - 06:25 AM
Post subject:
<update>I did a test of the debian on an older debian 32 bit etch net install, worked fine.

Please note: to update etch, you need to comment out the etch security repositories in /etc/apt/sources.list
then add sid to sources.list like this, BEFORE you start the switch over.
deb http://ftp.debian.org/debian unstable main contrib non-free

I tweaked a few things along the way, so ideally when the script finishes, you'll have most of sidux components installed as well.

Be careful during the sidux packages installation section to read each item to make sure you want it, for example, if it's isdn and you don't want isdn, say n to apt and it will go on to the next item.

Debian users or other debian based distro users, once you have started the process, please run the script to the end, there are some fixes that require variable values set one time only, the first time you run the script, to carry out certain options, and if you stop and restart it, those fixes won't get run.

Ubuntu is not supported in any way, if you try your system will die.
h2 - Dec 09, 2006 - 11:05 PM
Post subject:
Version: 4.9.10: more robust start to x functionality. Now supports gdm/kdm/xdm, and also supports default debian of starting gdm/kdm in init 3 or 2. Now script will correctly handle that situation, and not just try a simple init 5. This should be of benefit to debian users, means they don't have to convert their init stuff to start at init 5 for gdm/kdm/xdm, even though they should Wink
The_Seeker - Dec 10, 2006 - 12:21 AM
Post subject:
Quote:

Now supports gdm/kdm/xdm, and also supports default debian of starting gdm/kdm in init 3 or 2.

That's a really good idea h2; I think this will encourage users of Etch to try out sidux.
DeepDayze - Dec 10, 2006 - 01:41 AM
Post subject:
Sounds great, h2. Perhaps after Debian Etch users ran the script and conpleted the conversion of Etch to sidux, you could then add the option to set the runlevel to 5 for gdm/kdm/xdm.
h2 - Dec 11, 2006 - 03:50 AM
Post subject:
Version 4.9.13: Added -I option. This requires one argument, an integer value between 1 and 5. This will change the runlevel the script exits to with the init command.

Although I can't see much real reason for this, I guess it can't hurt either, now users can start in init 3 if they are so inclined, or any other init level between 1 and 5. Also found a bug with the syntax for arguments of options, so now the -P option works too, which I guess it never did due to an error.
h2 - Dec 11, 2006 - 09:27 PM
Post subject:
Version 4.9.15: added back support for nvidia 8776 driver, which seems to be working better on older video cards at the moment.
Richard - Dec 15, 2006 - 01:11 AM
Post subject:
Update:
Reinstalled Kanotix-2006-01rc4.
ran du-fixes-h2.sh
several times until everything completed.
Now see the sidux login screen. Only saw it once then it disappeared.
Apparently, there are new wrinkles that could not be fixed, without redoing everything.

Reinstall, du-fixes-h2, and now apt-get OOo, bogofilter, etal.
Also kde-devel to see if the gcc/gpp tries to break everything again.

Seems much nicer than the initial conversion to sidux.
At least the login screen is sidux. Smile

Note: Trying feta: Front End To Apt-get. This along with debfoster installed gives similar results as aptitude without the dangers of aptitude. It is a nice wrapper for apt-get, and related utilities. So far, so good.
No more aptitude.

Richard.
h2 - Dec 19, 2006 - 05:59 AM
Post subject:
Version 5.0.0: added radeon/ati fglrx 8.32.5 support. This required a major change in how the graphics works, so no guarantees here, but it worked for piper, so we'll see.

Hats off to piper for the tedious testing he suffered through on this one.
piper - Dec 19, 2006 - 06:29 AM
Post subject:
Beer (bier) time !! Wink thanks h2
paleoflatus - Dec 19, 2006 - 07:29 AM
Post subject:
piper wrote:
Beer (bier) time !! Wink thanks h2
Yes, and a salute to the team.
I'm raising a glass of Furstenberg (from the Black Forest) far away in sunny Queensland.
Aussie beer is OK, but they now make it with cheap hops and sugar. They also pasteurise it while it is quite sweet, so I usually keep to pure beer from Europe.
Thanks for the hard and clever work, good people.
Aurelius - Dec 20, 2006 - 11:43 PM
Post subject:
I just did a seriously major upgrade using h2's du-fixes script, my first time, and I just wanted to share, it was a one of a kind experience. That sucker just worked, and worked as advertised.

I have no more words for it's excellence.
h2 - Dec 28, 2006 - 02:32 AM
Post subject:
Version 5.1.0: script now supports 9746 driver install. This gives you 4 driver choices now for nvidia:

8776
9631
9742
9746

and for fglrx/ati/radeon, it gives you 3:
8.30.3
8.31.5
8.32.5

I cleaned up a bunch of weird errors on the graphics installer functions, and hopefully that will fix some problems people have been having.
h2 - Dec 29, 2006 - 12:49 AM
Post subject:
Version 5.20: script now tests for all required programs that it uses, unless I missed one or two. This is the current list:

awk basename cat chmod chown cut date egrep grep ln mkdir perl pidof ps readlink sed sleep sort touch unzip wc wget whoami

Also cleared up the debian install section as well to make it clear how to add sid sources to sources.list.

Most users will never see these, but as Latino pointed out, there are cases now where some apps are missing, like unzip, so now that will be handled before they are required.
h2 - Dec 30, 2006 - 12:07 AM
Post subject:
Version 5.2.2: Debian Users: added sidux detection for sources.list for debian users. Now offers to download sidux sources.list file to replace your current one before continuing.

Also sidux sources detection for all users now before dist-upgrade begins.
h2 - Dec 30, 2006 - 05:52 PM
Post subject:
Version 5.2.3: new slh 2.6.18.6-* kernels added.
h2 - Jan 02, 2007 - 09:18 AM
Post subject:
Version 5.4.x: all changes are ideally invisible to end user, but let me know if you see any problems. Script is now much more modularized, with new updating logic and functions, better integrated now into core of script.

However, there may be fringe events that cause problems with this new method, that would include libraries or updates not loading etc, giving small to large script errors.

Let me know if you notice anything, for starters you should see significant improvement in loading times now since library files and main script only reloads itself when there is a new copy on the server, not always as before.
h2 - Jan 02, 2007 - 07:33 PM
Post subject: RE: OT: h2-script in german
Version 5.5.0: created new lib file for kernel-install to match the kernel question lib file. Everything seems to be working well now, the includes are functioning as I had hoped they would. This will simplify the script's maintainance greatly over time since creating new library files is relatively trivial now compared to the standalone module method I was using before.

This is the biggest part of the new system, so unless I get significant bug reports related to this method, this is how I will handle all script library functions in the future, including language packs.

These are the current library files:

du-fixes-lib-graphics.sh
du-fixes-lib-kernel.sh
du-fixes-lib-kernel-install.sh
du-fixes-lib-warning.sh
du-fixes-lib-2006-fixes.sh

Quote:
de_expl_check_user_level_1_1="Um dieses Script nutzen zu können, musst Du als Root angemeldet sein."


Keep in mind that modules will need to be language independent completely, and will simply echo values, so there is no need for de_ type text.

Please wait a bit before proceeding so our efforts are synchronized, otherwise you will have to redo everything anyway.

The basic idea is that each function has a name. That name is unique, so the translation will be called by that name + a number, say:

print_information-1. That will identify the translation function and the part of hte function the translation goes into, some functions are very long and would require several different values

This data will be contained in a library file that is set by using the -L de option on script start.

I could also offer users an option to automatically set that in the config file as well the first time they used it.

However, I don't really have time at the moment, maybe later this week.
h2 - Jan 03, 2007 - 04:11 AM
Post subject:
Version 5.5.1: Script now asks all kanotix and debian conversion users if they want to update their /etc/sidux-version file to the new format. The script will write some extra information after the standard string to let me know that it's an older install, including the version number for kanotix [version numbers are 1-4 for kanotix, 5 for this generation of sidux, and will be 6 for first sidux release, I think anyway.

For kanotix users, it looks like this: sidux-20070102-d:2 , or sidux64 for 64 bit, and for debian conversions via the script it will look like: sidux-20070102-d

It will delete the /etc/kanotix-version file and write to the new /etc/sidux-version with that information.
smoo - Jan 03, 2007 - 06:33 PM
Post subject: Great script, h2 -- a small kernel version problem?
Hi, h2,

Your script (as many others have said) is a lifesaver, making some confusing things very, very easy. We're all grateful!

Now, of course, I have a question: How does the script tell which kernel version to install? I've just run the script twice in a row (the script version both times is 5.5.2) and the first time, it said the "latest 32 bit up" kernel is 2.6.18.6-slh-up-1. The second time, the version was given as 2.6.17.13-slh-up-1 (this is what I'm currently running).
I had the script install the 2.6.18 version quite a while ago (where "quite a while" probably means at least a week), and it went through fine. Then, the other day, when it said that the latest stable version was the 2.6.17 one, I had it go ahead and install that (wherein the yaird problem --- posted about elsewhere --- came about).

Which version really is the latest stable version up kernel?

Thanks,

smoo
h2 - Jan 04, 2007 - 08:06 AM
Post subject: RE: du-fixes information and updates
Version 5.5.5: Added option in misc tweaks to install new sidux kmenu sidebars and taskbar icons.

This is in misc tweaks module, based on Latino's code here:
http://sidux.com/index.php?name=PNphpBB ... amp;p=6230

Gives options to install sidux kmenu icon and sidux kmenu sidebar. The kmenu icon is I believe by cathbard, and the sidemenus are by drb and raider700
The_Seeker - Jan 04, 2007 - 10:33 AM
Post subject: RE: du-fixes information and updates
Quote:

Version 5.5.5: Added option in misc tweaks to install new sidux kmenu sidebars and taskbar icons.

I did this manually a few days ago but this is an excellent feature to add. Thanks h2 and of course thanks to op4latino.
h2 - Jan 04, 2007 - 09:29 PM
Post subject: RE: du-fixes information and updates
Version 5.5.9: fixed an error in the script library import that prevented required kernel wifi module from running with no connection.

Improved overall script lib file import handling, generalized script function for that now.
h2 - Jan 07, 2007 - 04:43 AM
Post subject:
Version 5.6.1: added option for debian users to install kde, also added -W option to trigger the installation of windows manager. Currently only kde is supported.

Debian netinstall users and other debian users will be asked one time if they want to do this, that's the first time they run the script only.
Crest - Jan 07, 2007 - 03:41 PM
Post subject:
For a more future version it would be probably nice to have the option of easy installation/deinstallation of some well known window managers. With all packages which are usually needed to use these wm's in a comfortable way.
h2 - Jan 08, 2007 - 12:20 AM
Post subject:
version 5.6.4: added xfce4 install to -W windows manager/first time debian switch menu.

The xfce install was not smooth with etch installer and xorg did not correctly identify my graphics driver requirements, but once I got that fixed in xorg.conf, in this case by changing: Driver "vesa" to Driver "i810" it all worked fine.

Test install is an older intel mobo with onboard video, 2mB video ram. Display is fine at 15 bit depth and 1024x768 resolution.

No gnome or kde components at all were installed, which keeps the base install under 1 gigabyte on disk.

I can't guarantee this will work for you, but after playing with the xorg.conf file a bit it ended up working no problem.
Crest - Jan 08, 2007 - 12:47 AM
Post subject:
Nice to hear, have not really tested xfce4 so far. Maybe I'll do in the near future or someone else does it and gives some feedback here Smile
h2 - Jan 11, 2007 - 01:48 AM
Post subject:
Version 5.7.0: created new lib module, all the debian/kanotix/sidux switch stuff is now an external library module. Let me know if you have any problems with that stuff, especially new switchers.

Also added, by zulu9's good suggestion, error handling to du part of script. Now if all goes as planned, the script will show an error message when du/install -f returns an error, with some advice on what to do.

I can't really test this until I get an error myself, so let me know if you get any false alerts.
shame - Jan 11, 2007 - 05:10 AM
Post subject:
I only ever used this script once before, and that was to convert from kanotix to sidux.
It all went well and I'm still using that same install now.
Well I used the script again today. I did a netinstall of debian etch 64-bit then used this script to convert that to sidux 64.
Again, everything has gone perfectly and after several hours of trying things out I still haven't found any problems.
To say I've only used the script twice I've had no problem understanding anything, everything is very well explained and it lets you know exactly what's happening and what to do next without getting too technical.
I'll have to use it more often. Excellent.

<EDIT> And just to add, in the debian etch install, X was broken (which I was aware of before I installed, a daily build) and I went straight into the h2 sidux conversion without even trying to fix, I just thought I'd see if the script would work it out and it did.
h2 - Jan 12, 2007 - 09:57 PM
Post subject:
Version 5.7.2: redid the distro version detection function completely to make it more forward compatible.

Now should easily handle any new syntaxes, and any number of new releases without having to be redone significantly. The old way was a mess.

Let me know if you experience any version detection type issues.
h2 - Jan 13, 2007 - 05:01 AM
Post subject:
Graphic install module 1.1.6: For most users who have installed fgrlx or nvidia drivers, script should show your previously installed driver now.

Cases where it will not work: where dmesg has been flooded by output from other applications like vmware.

For most users however this should work, but it won't always work.
h2 - Jan 18, 2007 - 06:28 PM
Post subject:
Version 5.8.6: Added apt-get update error handling. This should give a meaningful error code before automatically restarting script with -p option to set no pdiffs for apt-get update, which seem to be the main cause of most update errors from what I can see so far.

I'm hoping that this will drop the percentage of failed dist-upgrades down a bit, or at least prevent some failures.
h2 - Jan 20, 2007 - 06:20 PM
Post subject: RE: du-fixes information and updates
Version 5.8.8: modified apt-get update error handling after zulu9 pointed out some potential issues with simply using a script restart. Now offers users that get apt-get update errors 4 options: do update again using no-pdiffs; do update again using user's current options; continue with no update; quit script to diagnose further the error.
h2 - Jan 20, 2007 - 10:44 PM
Post subject: RE: du-fixes information and updates
Version 6.0.0: completed conversion to new library file method from previous external modules.

Combined some features, fix-fonts is now located in the du-fixes-lib-misc-tweaks.sh, the xorg cleanup module was combined into the du-fixes-lib-clean-up.sh module, and the clean xorg option is moved from post du fixes to the clean up option, where it fits more logically.

This is a fairly major change internally, and completes the major overhaul I have been doing the last month or so. Hopefully things will work pretty much the same as they did before.

Script will also remove all old module files to remove clutter when it runs all the way through.
h2 - Jan 26, 2007 - 07:18 PM
Post subject: RE: du-fixes information and updates
Version 6.1.0: I finally got around to adding logging options. New option: -l [that's an el] - switch on logging of apt-get update and dist-upgrade/install -f
Also added tee logs for all apt update/dist-upgrade type error cases, handled by using the same global value, USE_LOGS that is set now either with -l or in case error.

Personally I don't like logging because it turns off the output of download speed and progress for dist-upgrades and updates, but it will be useful especially for cases were an error repeats, now it will always get logged once the error flag is set, so you'll be able to have a record of the error if it persists after initial dist-upgrade or initial update.

log files will look like this: /var/log/du-fixes/2007-01-25-13:24:45-dist-upgrade-du1

This should be helpful long term so you can post some meaningful output to help get issues resolved.

Script default remains the same: no logging unless -l option is used or in case of error in update or du.

New function to check and create du config file, and error log directory: /var/log/du-fixes

The logs will be named fairly clearly, from each part of the script, so it should be easy to find the one you need. Also uses a year-month-day-hour:minute:second timestamp to avoid possible error, and to make it easy to find the one you need.

<update> found problem, tee of course becomes last thing to have run, so returns 0 after logging and breaks error handler. Have to fix that.
h2 - Jan 27, 2007 - 01:02 AM
Post subject: RE: du-fixes information and updates
Version 6.1.3: fixed above issue, now can grab error output of pre tee apt-get commands AND show full output to user, at least I think it works.

I don't have great confidence in this method so let me know if you have problems.

I also changed the option to an -l, not -T [ el for logging that is]
h2 - Jan 31, 2007 - 05:27 AM
Post subject:
Version 6.1.7: added new slh 2.6.19.2-slh**-5 kernels.

Added detection of incorrect runlevels for kdm and offers to update that to start kdm in 5 as it should be. Thanks for that one kelmo
h2 - Feb 20, 2007 - 01:08 AM
Post subject:
Version 6.1.26: added quick firefox to iceweasel profile renaming

Please note: if you installed the new iceweasel that uses ~/.mozilla/iceweasel profile directory, but you started it already, this fix will not undo that unless you delete your new ~/.mozilla/iceweasel directory then rerun the script.

This fix will check all your user directories for this and update it automatically if required

Or you can just do it manually if that's the case.
Turn off iceweasel, then do this
as user:
cd ~/.mozilla/
rm -rf iceweasel
mv firefox iceweasel

and your old profile will be restored as it was.

Of course first double check, or create backup of firefox profile directory, and make sure that's the problem.
h2 - Feb 20, 2007 - 07:08 PM
Post subject:
Version 6.1.28: added 2.6.20.1-slh***-2 kernels.
h2 - Feb 21, 2007 - 06:24 PM
Post subject:
Removed iceweasel fix because iceweasel maintainer changed it back to use firefox directory.... hopefully in the future the debian iceweasel team will do some damned testing BEFORE they release their deb to sid, and catch things like this BEFORE they are let out. It's not like this issue was hard to spot, it was instantly obvious the first time you opened that new iceweasel version.
h2 - Feb 22, 2007 - 09:13 PM
Post subject:
version 6.1.31: added option, one time display, to update /etc/apt/sources.list to use non-free contrib repositories.

This uses sticky prefs, so user will only see this question one time.
The_Seeker - Feb 22, 2007 - 10:34 PM
Post subject:
h2 wrote:
version 6.1.31: added option, one time display, to update /etc/apt/sources.list to use non-free contrib repositories.

Very, very good idea.
h2 - Feb 24, 2007 - 11:26 PM
Post subject:
version 6.1.33: cleaned legacy cruft off all script components, updated, removed options that are not needed any longer.
h2 - Feb 27, 2007 - 07:54 PM
Post subject:
version 6.2.0: Reorganized the post du options. Now it's much simpler:
1 master function now controls:
1. fix fonts
2. package-install
3. package-removal
4. cleanup stuff
5. miscellaneous tweaks

All things that qualify as system or script tweaks are now in misc tweaks, which makes a lot more sense, and there's only one step between du completion and graphics install, which also makes more sense.

Coming: improved package install, more non free stuff like opera.
h2 - Feb 28, 2007 - 05:28 AM
Post subject:
The graphics module now supports the option to install the native xorg ati and nv modules. In other words, you can now try using both ati OR fglrx, or nVidia Or nv, and see which you like. Especially with ati, the free xorg driver tends to run better on older cards than the fglrx stuff, if the fglrx stuff even runs at all.

This option is also available directly through sgfxi, using the -n argument, in other words: sgfxi -n
will install the appropriate xorg driver for your ati or nvidia card.

The xorg driver also updates your xorg.conf, removing all nvidia/fglrx specific stuff, and changing the default driver to the appropriate one.

Running this cleans up your old binary stuff as much as possible, uninstalls fgrlx and nvidia if possible, updates xorg, and installs xserver-xorg-video-nv/ati if it's not present.

So have fun swapping between free and non free drivers, post any bug reports of course in the bug thread.
h2 - Mar 01, 2007 - 05:44 AM
Post subject:
version 6.2.9: Finally updated the post dist-upgrade text to react to error or no error condition dynamically, now displays appropriate action messages depending on if operation exits with success or failure.
h2 - Mar 02, 2007 - 10:51 PM
Post subject:
Version 6.2.13: Modified xorg detection to be more robust, now it will detect if xserver-xorg or xserver-xorg-core is updated during script run through, and then show a message on graphics install if either of the two version numbers changed advising nvidia or ati users to reinstall their driver.
zulu9 - Mar 02, 2007 - 11:34 PM
Post subject:
great new feature!
h2 - Mar 03, 2007 - 12:32 AM
Post subject:
Yes, this is a good one. I am starting to integrate the new gfx installer logic with the du-fixes graphics module, so I can start to fine tune stuff now, now also only users with SUPPORTED nvidia or ati cards will even see any message about updating the drivers. This makes the graphics question quite dynamic, much nicer in my opinion for normal users.
h2 - Mar 08, 2007 - 04:08 AM
Post subject:
version 6.2.15: added new slh 2.6.20.2-rc1-slh**-1 kernels.

these are only available using the -K option, for extra advanced kernel options.

Usually if a kernel is marked rc I'll put it in with the -K kernels, those only display as options in advanced kernel install when you start du-fixes with -K.
h2 - Mar 08, 2007 - 11:51 PM
Post subject:
version 6.2.17: moved the new slh 2.6.20.2-rc1-slh**-1 kernels to default new kernel install, no -K required.
h2 - Mar 09, 2007 - 09:21 PM
Post subject:
version 6.2.18: a fine tuning thing, now script detects if user placed it in the wrong directory (must be in /usr/local/bin), and moves the script to the correct script home directory, then exits and logs out root.

The last step is required because otherwise bash keeps looking for the script in the old location.

Gives a warning message to user to let them know what happened.

I'm hoping that this will cut down on those occurances where users are running an older version of the script somewhere that preceeds /usr/local/bin in the system $PATH, causing very strange issues.
h2 - Mar 10, 2007 - 02:41 AM
Post subject:
version: 6.2.19: updated kernels to 2.6.20.2-slh*-1
h2 - Mar 11, 2007 - 07:11 PM
Post subject:
version 6.2.26: Added new 2.6.20.3-rc1-slh**-1 kernels
h2 - Mar 12, 2007 - 04:59 AM
Post subject:
Modified package install section completely:

now has four subsections:

1 - office - full featured office suite installers, including language pack selection.
2 - non-free - stuff like flash, opera, etc
3 - utilties - cool collections of packages, tools, etc
4 - display manager - setup xorg, kde, xfce, and more to come

These sections are rough and just have basic stuff for now but I'll expand this over time to have more stuff, including kde full installer, language packs etc, koffice + language packs and so on.
paleoflatus - Mar 12, 2007 - 06:39 AM
Post subject:
h2,
You're amazing! The new package install section sounds great and I'll try it out soon.
To a large extent, it seems to answer the complaints and suggestions about what packages sidux should include.
As we all know, it's easy to add or subtract as we wish with debian systems, but a lot of us are either lazy, or inexperienced and it looks as though you're coping with our human frailties in a very clever way.
My thanks in advance.
h2 - Mar 12, 2007 - 05:41 PM
Post subject:
<bug reports moved to du-fixes bug thread>
h2 - Mar 13, 2007 - 05:00 AM
Post subject:
Version 6.3.0: fixed a long standing weakness in the kernel components, now detects - usually correctly - multicore systems and offers SMP kernels as expected, or UP if appropriate.

One less confusion for users. This required redoing all the core versioning stuff for kernel numbers, but it makes it a lot easier to maintain long term, and makes the latest kernel selection fully automatic.

Now default kernel install, instead of always being up single core default, defaults to best guess for users actual cpu count, SMP or UP kernels as default latest kernel to install.

Not sure if this works for hyperthreaded Pentiums or not, let me know.
h2 - Mar 13, 2007 - 11:59 PM
Post subject:
version 6.2.3: added new 2.6.20.3-slh**-1 kernels. slh continues to be on a kernel building rampage!
Glanz - Mar 14, 2007 - 11:58 AM
Post subject:
2.6.20.3-slh-up-1 installed perfectly in less than 4 minutes.

Dumped previous kernel without difficulty via the "kernel-remover"...

Incredible scripts! I am amazed! (once again)...
h2 - Mar 14, 2007 - 07:48 PM
Post subject:
version 6.3.4: Moved the section that tells you what config files to answer 'y' to during dist-upgrade to right before dist-upgrade starts. Now that section is not part of the standard warning, but just a standalone thing that runs independently of the warning section.

This should help highlight all warnings too, more than it was doing. So watch the warning section closely, anything there will be highly relevant now.

Also: currently there are no warnings!! This is a first since I created that component. And it won't last long, that's for sure, with Etch finally allegedly going stable in a few weeks.
h2 - Mar 20, 2007 - 02:20 AM
Post subject:
new kernels: 2.6.20.4-rc1-slh**-1

As always, all default kernels are considered stable and safe, so don't worry about the rc1, but on the other hand, I'd wait for the non rc release unless you have an issue a new kernel might fix.
RRowan - Mar 20, 2007 - 05:06 AM
Post subject:
Hi H2,

I tested the wifi module. It does ask to install a wifi if the wired connection is unplug.

Thanks

RR
rodneyck - Mar 22, 2007 - 06:48 PM
Post subject:
h2... I have a question. Forgive me if this has already been posted as I did not read through the very long thread. I am attempting to download the du-fixes script and it says;

Quote:
You can either download the script file then put it in /usr/local/bin


I don't actually have "bin" in that location. Is this normal and do I just create it?
h2 - Mar 22, 2007 - 06:53 PM
Post subject:
If you don't have the directory /usr/local/bin something is very unusual. That is a system path. Make sure about this before you proceed.
rodneyck - Mar 22, 2007 - 06:59 PM
Post subject:
h2 wrote:
If you don't have the directory /usr/local/bin something is very unusual. That is a system path. Make sure about this before you proceed.


Well now you are sacring the hell out of me. I have usr/local/sbin..with nothing in it. (btw I am showing hidden files and still nothing) What...emmm..else should be in "bin"?

*installed sidux from the lite version*

Edit to include the following...

I got this from a Mephis forum, as some guy accidently deleted his /usr/local/bin folder...

Quote:
/usr/local/bin is empty unless you installed something outside of synaptic and things got put in there.
For me, the only thing that appears in there is gyach, which I installed from converting from rpm to deb.
Since nothing else is in there, not even hidden files, I am drawing a for me logical conclusion that it is normally empty.
(mind.. I am on a 6.0 final install)


So whether it was never there to begin with or somehow mine got accidently deleted, I don't think it is a big thing. So should I just create it and proceed?
h2 - Mar 22, 2007 - 07:16 PM
Post subject:
yes, as root create it, but I don't know how or why that directory is absent.

/usr/local/bin

should be there, it was there on my fresh sidux install, so how that got deleted is beyond me, this is what's in mine, all directories, but this is from kanotix days. But it should look roughly the same. I would try to figure out just how that got removed if I were you.
bin
games
include
lib
share
src

The poster is correct, it is normally empty, until you place files into it.
Richard - Mar 22, 2007 - 07:23 PM
Post subject:
First used the script under kanotix and I had to create the directory.
Because I had /usr/local as a separate partition at install, so it wasn't reformatted.
rodneyck - Mar 22, 2007 - 07:29 PM
Post subject:
Richard wrote:
First used the script under kanotix and I had to create the directory.
Because I had /usr/local as a separate partition at install, so it wasn't reformatted.


That's comforting at least.

I don't really know how to go about finding what deleted it, except to keep an eye on it. I bet it was foul-tempered folder pixie. Time to hang one of those sticky pestilence strips inside my computer's box, again.
h2 - Mar 22, 2007 - 07:32 PM
Post subject:
if it was the folder pixie, then you just have to live with it, she's a pain sometimes, so just make a new one. At least it wasnt' the directory demon, who tends to also eat full directories.
rodneyck - Mar 22, 2007 - 07:39 PM
Post subject:
h2 wrote:
if it was the folder pixie, then you just have to live with it, she's a pain sometimes, so just make a new one. At least it wasnt' the directory demon, who tends to also eat full directories.


ROFL... I assume you have to tent your box and fumigate for those?

I have heard of the elusive horned drive-manglers. Nasty, horrid, wretches with magnets strapped to their hindend. Wink Laughing
h2 - Mar 24, 2007 - 12:49 AM
Post subject:
6.3.9: new 2.6.20.4-slhxxx-1 kernels. Replaces the rc1 versions.
h2 - Mar 24, 2007 - 09:48 PM
Post subject:
Version 6.3.10: added new option: -E, this lets European users who experience slow kernel download time try the European kernel mirrors first. If the requested kernel is not on that mirror, or if the mirror is down, it will go back to the script default US based kernels. Only the US based kernel mirror has the older kernels, and only it will be able to access -K type advanced kernels. Usually there are no -K kernels though, but now and then there are.

But it should be fairly transparent to users, if kernel isn't on euro servers, it will just switch to US ones, with an error mesage to let the user know.

This option was in response to Dutchy's request in that thread.
h2 - Apr 07, 2007 - 07:38 AM
Post subject:
version 6.3.18: added 2.6.20.6-slh*-1 kernels.
h2 - Apr 10, 2007 - 08:11 PM
Post subject:
version 6.3.26: k3b fix is automated and runs if libk3b2 is present in system:

apt-get remove --purge k3b libk3b2
apt-get install k3b

this seems to deal with the new k3b 1.0 install fine.
h2 - Apr 13, 2007 - 09:40 PM
Post subject:
version 6.3.33: Redid no connection logic to better handle case of reboot after kernel install with du-fixes. Now checks for connection before trying to get version file, and offers a more clear path to the wifi install section.

This should make it easier on users to get their wifi stuff handled after new kernel install. Also in lib-kernel.sh redid the logic to now offer up kernel users the rt2570 kernel.

Process to get wifi modules installed:

1. install kernel with du-fixes
2. reboot
3. restart du-fixes with NO connection present.
4. you will see a failed connection notice, with option to try to restart networking. Select n.
5. This takes you to the option to do wifi install. Proceed with wifi install as normal.

Please note: the du-fixes script must have been used at least one time before for this to work (at least for kernel install, that is), and you must have installed your current kernel with du-fixes previously to be able to install the wifi module, which is in the kernel download directory.
h2 - Apr 14, 2007 - 04:14 PM
Post subject:
version 6.3.35: Added 2.6.20.7-slh*-1 kernels.
h2 - Apr 14, 2007 - 05:42 PM
Post subject:
version 6.3.37: Added fix to update libc6, libc6-dev, locales, to fix dependency issues for new 2.6.20.7-slh kernel headers before main du runs. Failure to run this before main du will result in failed du after new kernel install.
h2 - Apr 14, 2007 - 08:10 PM
Post subject:
version 6.3.39: new feature, remote admin of packages to be put on hold, no longer required to use du-fixes manual update of script to add or remove package holds. Now that sid is back in all its fun filled ways, this should be helpful long term.
h2 - Apr 21, 2007 - 10:13 PM
Post subject:
Modified lib-graphics module to handle the new fglrx failure for xorg 1.3 errors. Now if user system has the new xorg 1.3 syntax (xorg 7.2 actually) and would normally have seen the fglrx driver install option list, the module will only offer fglrx users xorg radeon or xorg ati install options, since those are the only ones that will work.
Dutchy - Apr 23, 2007 - 09:42 AM
Post subject:
Which means that a d-u is safe if you have an ATI card and use the wonderful script h2 provides. Those doing their d-u manually, beware, as it is clearly pointed out in the News module that fglrx will break X and you'll be left at a nice bash prompt after booting. Perhaps this is a good time to brush up on your CLI skills Smile
rodneyck - Apr 25, 2007 - 11:39 PM
Post subject:
New kernel just released.... 2.6.20.8. *crosses arms and waits for h2*
h2 - Apr 26, 2007 - 12:51 AM
Post subject:
Kernels weren't released and uploaded until now, so:
version 6.3.54: new 2.6.20.8-slh*-1 kernels, also new testing kernels for the adventurous.
h2 - Apr 26, 2007 - 04:53 PM
Post subject:
version 6.3.55: new 2.6.21-slh*-1 kernels.
Ironwalker - Apr 26, 2007 - 05:31 PM
Post subject:
Thanks,most appreciated.
h2 - Apr 26, 2007 - 08:00 PM
Post subject:
version 6.3.56: moved 2.6.21 kernels to advanced -K options. These kernels have some core issues which make it unwise to make them defaults at this point, several issues in fact.

I can confirm that sata hotplugging is broken, and removing the sata device from system freezes it dead. So with that in mind, and since sata hotplugging is a standard feature in modern motherboards and systems, I'll keep these as advanced tester options.
h2 - Apr 26, 2007 - 08:11 PM
Post subject:
version 6.3.57: new 2.6.20.9-slh*-1 kernels added as new default because of issues with the 2.6.21 stuff for now.
h2 - Apr 28, 2007 - 03:43 AM
Post subject:
Version 6.3.59: new kernels added: as latest stable: 2.6.20.10-slh*-1; latest advanced kernel install, -K option: 2.6.21.1-slh*-1
h2 - Apr 28, 2007 - 05:26 PM
Post subject:
version 6.3.60: besides being the highest subversion number ever reached by du-fixes, this version adds the latest testing kernels to -K option: 2.6.21.1-slh*-2
rodneyck - May 02, 2007 - 10:57 PM
Post subject:
Nvidia just released new drivers... 1.0-9762 *crosses arms, checks watch and waits for h2 to update*
h2 - May 02, 2007 - 11:28 PM
Post subject:
Post a link, that isn't posted anywhere, including on nvidia's forums.

<updated>I guess they are lazy, that's been added to sgfxi now, but I'm leaving 1.0-9746 as an advanced option, along with the real latest, 100.14.03.
rodneyck - May 03, 2007 - 12:01 AM
Post subject:
If you need a link, here it is...

nvidia 1.0-9762
h2 - May 03, 2007 - 12:26 AM
Post subject:
Found it, for some reason they didn't post this on normal places, just on download pages. Tested and working as usual.
h2 - May 03, 2007 - 06:51 PM
Post subject:
<update>: haste makes waste, that's the latest quadroplex driver, not the latest stable driver.

I've updated sgfxi to automatically detect nvidia quadroplex cards, and to use the latest quadroplex driver if it's available as install default. This should work well for all users.

Rolling back to 9755 for latest stable however for standard cards, with 100.14.03 being latest beta for nvidia.

ATI users as usual are out of luck until ATI deigns to release a working driver for the new xorg 1.x syntax.
h2 - May 08, 2007 - 01:55 AM
Post subject:
version 6.3.63: New kernels: 2.6.20.11-slh*-1; 2.6.21.1-slh*-3
2.6.20.11 kernels have no up candidate because that will no longer be offered, now kernels will soon rely on hotplugging of cores, active detection that is, by kernel.

2.6.21.1 kernels remain as advanced -K kernel install options.
Ironwalker - May 08, 2007 - 09:22 PM
Post subject:
Great,thank you again.
h2 - May 11, 2007 - 06:59 PM
Post subject:
Version 6.3.66: added 2.6.21.1-slh*-4 kernels; also now these are the new defaults, in preparation for tartaros release, we'll see how they go, should be ok for most users though, and maybe we'll catch a bug or two before final release.
h2 - May 11, 2007 - 07:23 PM
Post subject:
version 6.3.67: New 2.6.21.1-slh*-5 kernels added.
h2 - May 13, 2007 - 12:33 AM
Post subject:
version 6.3.68: New feature: users can now add their own packages to put on hold/release, using existing /etc/du-fixes.conf, user simply has to add this to file:

hold-install=package1^package2

No " or ', just the package names to be held, each name separated by a ^ character

<updated to fix bug, new separator>.
h2 - May 13, 2007 - 05:10 PM
Post subject:
Version 6.3.69: new 2.6.21.1-slh*-6 kernels added
h2 - May 13, 2007 - 05:24 PM
Post subject:
Version 6.3.70: fixed a bug with the user set hold-install feature:

Because of other processing, no spaces can be used in the user set hold/install feature.

Now to set multiple hold/install packages, use this syntax:
hold-install=package1^package2^package3

In other words, the package name separator is now ^, not a space.
h2 - May 14, 2007 - 02:23 AM
Post subject:
version 6.3.71: new 2.6.21.1-slh*-7 kernels added
h2 - May 14, 2007 - 08:44 PM
Post subject:
version 6.3.72: new mozilla-tweaks stuff, together with lib-misc-tweaks, 1.7.0, offers users different tweaks now to run alone or together. Dump gtk file handler, user prefs tweaks, or run all tweaks automatically.

More tweaks will be added over time.
h2 - May 21, 2007 - 05:17 PM
Post subject:
As with the first sidux release, this one brings a new milestone: 30,000 visits to the script home page as of today. The 20k milestone was hit right around the time of Chaos release. Script useage growth has held steady since sidux split from kanotix at roughly 2 times the numbers it had with kanotix.

As far as du-fixes and its users are concerned, whatever users saw in kanotix, they see more of, and like better, with sidux, which is to their credit, since sidux is also improved in pretty much every way itself.

Numbers of new users of du-fixes with sidux has remained fairly constant, about 250-350 new users a week, give or take a bit depending on publicity, new releases, etc.
piper - May 21, 2007 - 07:31 PM
Post subject:
Very impressive numbers
h2 - May 22, 2007 - 10:19 PM
Post subject:
version 6.3.73: 2.6.21.2-rc1-slh*-3 kernels added
h2 - May 24, 2007 - 02:12 AM
Post subject:
version 6.3.76: 2.6.21.2-slh*-1 kernels added.
h2 - May 25, 2007 - 03:04 AM
Post subject:
version 6.3.78: kernels 2.6.21.3-slh*-1 added.
uuu - May 25, 2007 - 03:42 PM
Post subject:
Is there a problem with .78 it only ever appears .77

once more and more


I only have small knowledges.
h2 - May 25, 2007 - 06:22 PM
Post subject:
version 6.3.79: New kernels: 2.6.21.3-slh*-2

I probably forgot to upload a version file last night or something.
spacepenguin - May 25, 2007 - 09:44 PM
Post subject:
apropos kernel: the script says that all further kernels will be "smp" - but now they are "up" again?
h2 - May 26, 2007 - 12:47 AM
Post subject:
version 6.4.3: New fix for icedove upgrade from 1.5 to 2.0:

fix offers users chance to first make backup copy of their ~/.mozilla-thunderbird
directories for all users, then runs this:

apt-get remove --purge icedove
apt-get install icedove

note: the icedove-locales-* packages are not in sid yet, so if users have those
installed, script lets them know they will need to reinstall them later manually.

spacepenguin: yes, slh was going to make them all smp but he changed his mind, it's been bouncing back and forth, I just updated that, now it detects if kernel is up or not, and offers different text if it's smp or up, if it's up user.
h2 - May 26, 2007 - 05:24 PM
Post subject:
version 6.4.5: after some deliberation with core team members, du-fixes will now remove a legacy package which should have been removed during transition, sysv-freeze. This package is abandoned, and is causing issues with things like hal upgrade for some conversion system users, so it needs to go.

Also tweaked icedove fix to give more information to users.
h2 - May 27, 2007 - 04:15 PM
Post subject:
version 6.4.6: Added 2.6.21.3-slh*-3 kernels.
h2 - May 28, 2007 - 04:40 PM
Post subject:
version 6.4.7: added 2.6.21.3-slh*-4 kernels.
h2 - Jun 01, 2007 - 08:02 PM
Post subject:
version 6.4.8: Updated du-fixes to show google earth package install option for package install lib.

Main change is the google earth installer in du-fixes-lib-package-install.sh version 2.1.1

This downloads the debian installer package, which then gets the google bin package, then creates a deb, and installs the deb, then cleans up.

Also, in sgfxi, a new option for free xorg radeon driver: sgfxi -eN radeon will install an experimental xorg ati package that should give noticeably better performance.

Using the experimental xorg ati driver and google earth gives me very good performance on a mobile ati 7500 with 32 mB ram.
h2 - Jun 05, 2007 - 06:30 AM
Post subject:
Version 6.4.10: Several changes, all related to up kernel handling. Now script will always offer users of up kernels the new preferred smp versions, with a brief explanation of why. up kernels now are basic, stripped down and offer no preemption, no dyntick (--> half of the possible battery capacity), no highres timer, no nothing. According to slh, this is the new default policy for kernels, so don't worry about the smp offering, it works better than up in almost all cases, for smp or up.

Added 2.6.21.3-slh*-5 kernels.

Removed legacy 2.6.16 and 2.6.17 kernels ( have to make room on server, sorry)

New kernel test, now checks for less than 2.6.21 kernels, and if detected, alerts users that they must first to a dist-upgrade before installing newer kernels. This should help solve that lingering tzdata linux-utils issue users get if they have < 2.6.21 kernels and upgrade to newer.
h2 - Jun 05, 2007 - 06:32 AM
Post subject:
Version 6.4.10: Several changes, all related to up kernel handling. Now script will always offer users of up kernels the new preferred smp versions, with a brief explanation of why. up kernels now are basic, stripped down and offer no preemption, no dyntick (--> half of the possible battery capacity), no highres timer, no nothing. According to slh, this is the new default policy for kernels, so don't worry about the smp offering, it works better than up in almost all cases, for smp or up.

Quote:
the background is simple, we're still encountering a pretty large number of seriously broken drivers for some hardware (like ISDN, proprietary modems and the like), those drivers typically don't cope well with smp and preemption, sometimes also dyntick (which is a major improvement regarding battery life) and highres timers - therefore the *obsolete* -up drivers got a second chance as failsafe, don't-use-me-unless-you-really-need kernel option - slh


Added 2.6.21.3-slh*-5 kernels.

Removed legacy 2.6.16 and 2.6.17 kernels ( have to make room on server, sorry)

New kernel test, now checks for less than 2.6.21 kernels, and if detected, alerts users that they must first do a dist-upgrade before installing newer kernels if they have not done one recently. This should help solve that lingering tzdata linux-utils issue users get if they have < 2.6.21 kernels and upgrade to newer.

I think rather than move the kernel question, I'll simply keep this warning that if your kernel version is older than one full version, you should probably dist-upgrade first, and just update the versions with each major kernel upgrade.
h2 - Jun 05, 2007 - 07:54 AM
Post subject:
Version 6.4.11: added fix for libxine1-ffmpeg issue, now detects automatically for libxine1 and forces install of the missing package. This should resolve user issues with that upgrade.
h2 - Jun 08, 2007 - 07:15 PM
Post subject:
Version 6.4.12: Added 2.6.21.5-rc1-slh*-1 kernels

Also, in sgfxi, added 2.6.22 fglrx 8.37.6 driver patch, any testers who want to try that let me know if it works.
uuu - Jun 10, 2007 - 07:12 PM
Post subject:
using sgfxi -c

in init 3

with my cards Beryl works


with h2 Skript before the driver got installed but Beryl did not work with my cards


uuu
h2 - Jun 10, 2007 - 08:04 PM
Post subject:
du-fixes when you select the default install will run: sgfxi -c
Default will vary depending on card type and age, for your 5200 and 7300 it's currently 100.14.09

Could have been a 9755 issue with your card, it's hard to say, but the scripts are the same ,no difference
h2 - Jun 11, 2007 - 10:27 PM
Post subject:
versions 6.4.15: Added 2.6.21.5-slh*-1 kernels.
h2 - Jun 13, 2007 - 02:23 AM
Post subject:
version 6.4.17: 2.9.21.5-slh*-smp-2 kernels added. These fix this cifs transfer speed bug
h2 - Jun 17, 2007 - 06:46 PM
Post subject:
version 6.4.20: upgraded number comparison and nvidia number handling to account for . or , decimal separators. Now all data sent to number comparison is standardized to use . separators, then number compare tests base system to see which it uses, and converts the compared internal numbers to use correct system method.

This should work very well I think, since it removes the randomness factor users have reported after trying setting LANG=C. Why that isn't working consistently is beyond me, but now it's tested for explicitly and handled in the correct way.
h2 - Jun 23, 2007 - 02:15 AM
Post subject:
version: 6.4.21 and cleanup lib: Due to increasingly obvious issues with the deborphan clean up option, I've removed it. The problem is that it's removing technical non-dependent libraries which are actually needed by other applications to do their work, things like libmms0, and a variety of other libs.

We talked about this issue, and I agree, this feature is causing too many problems for users, is too hard to make run safely, so for now it's being removed.
Crust - Jun 24, 2007 - 05:40 AM
Post subject:
Is there a better way to remove crud from our system without deborphan?
h2 - Jun 24, 2007 - 06:37 AM
Post subject:
We'll see, in terms of bulk, yes, there are better ways. deborphan is removing too many required but not technically dependent libraries routinely, and it's too hard to keep a safe list going of what should and should not be removed.
h2 - Jun 25, 2007 - 01:11 AM
Post subject:
version 6.5.1: Phase 1 of new du-fixes naming convention. Now script will be called sm, in phase 2, and all lib files, and other files will be named with sm instead of du-fixes.

Phase 1 switches all lib files to sm-lib-xxx format from du-fixes-lib-xxxx.sh format. It also renames /etc/du-fixes.conf to /etc/sm.conf and /var/log/du-fixes/ to /var/log/sm/

All related variables have been changed as well, and the lib files have been updated to remove all du-fixes references

Phase 2 will be the renaming of du-fixes itself to sm, changing the sidux-scripts installer stub to handle the new sm naming, and a few other details, like updating as many of the pages as possible that refer to it.
paleoflatus - Jun 25, 2007 - 01:59 AM
Post subject: Re: du-fixes script: information and updates: new name etc.
h2,

Simplification/streamlining looks like a good idea and I follow most of your post, but I'm a simple soul. Do we still run du-fixes etc., or do we have to enter another command now?

Your script is the saviour of the simple classes!
h2 - Jun 25, 2007 - 02:32 AM
Post subject: RE: Re: du-fixes script: information and updates: new name e
version 7.0.0: du-fixes-h2.sh has a new name! sm

Script will, as usual, handle it all for you. Simply run du-fixes-h2.sh and it will download and install sm, which will then replace and update all du-fixes files to the new sm naming format.

So, first time, run: du-fixes-h2.sh
that will download the sm updater, then after that, run sm instead.

du-fixes after this first conversion will be no more.

I still have to update the sidux-scripts du-fixes stub, I'll do that one tomorrow I think.
paleoflatus - Jun 25, 2007 - 04:06 AM
Post subject:
h2,

Thanks. It couldn't be easier!
h2 - Jun 25, 2007 - 04:23 AM
Post subject:
As of tomorrow, sidux-scripts will also be updated to also handle sm with the stub installer, so users will be able to type in: du-fixes-h2.sh or sm, if they use the du-fixes-h2.sh option, the installer will download the sm updater from server, which will let users know about the name change.

If they use sm directly (only after apt-get update;apt-get install sidux-scripts , to get latest, they can simply just type in sm to get the script.

sm will remove all traces of the old stuff, or rename it, depending, so after the first script run, the user's systems should have only sm stuff in it.
paleoflatus - Jun 25, 2007 - 05:52 AM
Post subject:
By the way, Sado-Masochism is an easy mnemonic!
h2 - Jun 27, 2007 - 11:21 PM
Post subject:
version 7.0.3: New -K advanced kernel install kernels: 2.6.22-rc6*-smp-1 kernels

Please give these a try, this will probably be the gaia kernel, so the faster we can find bugs in it the better.

Start sm with -K option to get these new kernels.
daldred - Jun 28, 2007 - 08:03 PM
Post subject:
Hi!

I've just finished off a kernel upgrade (following some wifi issues described elsewhere). The kernel upgrade path in sm was very simple and straightforward, thanks.

Just one suggestion: would it be possible for the script to respect the cheatcodes set under the 'old' kernel when rewriting menu.lst for the new one? It's not a big hassle to rewrite them manually - but annoying when you don't realise until after the new kernel has booted that it's not respected your screen size and you can't read the command prompt because it's ten lines off the bottom of your physical screen!

(I can't see where in the script this is handled, though - is it managed by some other script?)
h2 - Jun 28, 2007 - 08:21 PM
Post subject:
daldred: you do this yourself, add the cheatcode to the the
#kopt ......
line, in /boot/grub/menu.lst

everything in that #kopt.... line is what is used to create your new kernel boot arguments/cheat codes.
# kopt=root=UUID=71e....00 ro ramdisk_size=100000 lang=us apm=power-off nomce vga=0x317

for example, the # is required and is part of the line.
daldred - Jun 29, 2007 - 08:31 PM
Post subject:
h2 wrote:
daldred: you do this yourself, add the cheatcode to the the
#kopt ......
line, in /boot/grub/menu.lst
.


Thanks, h2 - is this in the manual / wiki somewhere and I've missed it?

...edit... yes, it's in menu.lst itself in the commented sections.
h2 - Jun 29, 2007 - 09:06 PM
Post subject:
don't worry about not knowing everything, I used to manually update my menu.lst too for resume partition until I finally realized everything has been thought of long ago and a solution was there since long ago. then I found # kopt line.
h2 - Jun 29, 2007 - 10:53 PM
Post subject:
version 7.0.6: New -K advanced kernel install kernels: 2.6.22-rc6-git3-slh*-smp-1 kernels
h2 - Jun 30, 2007 - 05:15 PM
Post subject:
version 7.0.8: New -K advanced kernel install kernels: 2.6.22-rc6-git4-slh*-smp-1 kernels
h2 - Jun 30, 2007 - 07:56 PM
Post subject:
version 7.1.0: Created a kernel version back end for sm. Now script imports sm-lib-kernels file into itself. This solves the problem of having to actually update the script physically each time some kernel thing is updated. Now kernels are added via a script control panel, which will simplify matters over time, and also avoid having to update the script each time sidux gets new kernels, or each time
I want to remove some legacy stuff.
h2 - Jul 02, 2007 - 05:36 AM
Post subject:
added 2.6.22-rc7-slh*-smp-1 kernels.

Redid sm-lib-clean-up to better handle removing kernels. Now the kernel install directory cleanup reads /boot/grub/menu.lst and only asks you if you want to remove kernels that are not present in it. This makes it easier to clear out the system, just say y to each directory removal question now and it will be safe.
h2 - Jul 07, 2007 - 04:16 PM
Post subject:
2.6.21.6-slh*-smp-1 kernels added
h2 - Jul 09, 2007 - 02:38 AM
Post subject:
2.6.22-slh*-smp-1 kernels added. I hope you have better luck with these than I've been having, if not, have fun starting to file your kernel bug reports to kernel lists. You'll have to excuse my distinct lack of enthusiasm, the rc7 version was the least stable kernel for nforce4 mobo I have ever used, multiple issues and bugs.

Here's hoping at least some of the bugs get fixed over the next few releases.

Remember, kernel bugs are not caused by sidux developers.
h2 - Jul 11, 2007 - 12:19 AM
Post subject:
2.6.22.1-slh*-smp-2 kernels added
SaberBlaze - Jul 12, 2007 - 03:23 AM
Post subject:
This script has come a long way. Excellent work h2, this script is simply amazing.

Now, I still had my main old Kanotix install that I believe the last time it was dist-upgraded was September of last year. The sidux cd does not have an upgrade option afaik so the obvious choice is to back up some stuff like themes and whatnot and to a clean install. Well, me being the crazy person that I am, thought I could give dist-upgrading a try just to see what would happen, I mean what the heck, I was going to be installing sidux in the end anyway. So, I copied the sources.list and other apt files from my other computer that I already installed sidux to the Kanotix comp and did an apt-get update and installed the sidux-scripts. Then I when init 3 and ran sm. It told that Kanotix conversion were no longer supported since March, but then it stated that if the comp had already been converted to sidux and was still displaying this message, then the script could make so that it recognized your comp as sidux. Well, I did that and fooled the script into thinking it was running on sidux. I installed the new kernel and had to make some changes to fstab because this new libata or whatever thing going on. Then I dist-upgraded, which had to download about 700+ of software. I only had one problem with a package, but I fixed it with dpkg -i --force-overwrite /var/cache/apt/archives/libpth20_2.0.7-8_i386.deb.

Surprisingly, the dist-upgrade worked Shocked . I chose the open source radeon driver and booted into init 5. For the most part, it works, but boot times are kinda slow and the comp is "less than perfect." There is obviously some funny business going on with some packages, for example Xorg states that it is at version 1.3. Anyway, I'll probably be doing a clean install of sidux shortly. The moral of this story? You still dist-upgrade after one year. j/k, the moral is don't waste your time with stupid little experiments like these Laughing .
h2 - Jul 12, 2007 - 03:34 AM
Post subject:
xorg is at version 1.3, that's normal, parts of it are 1.3, others are 7.2/1.2 if I understand it right.

I'm actually not surprised it worked, I did a box that was converted about 2006-12-15, hadn't been touched since, then was reupdated about 2007-05-15, it went fine, took a long time to do it.

The key here was the debian etch freeze, basically, there weren't that many changes until march, and the changes that did happens were relatively smooth, and sm has most of the required fixed.

That box, by the way, recently got a new cpu/motherboard, got updated again, and is running fine.

My main machine is also a conversion from kanotix, it runs fine, I keep it cleaned up from cruft and garbage as much as I can. One of the advantages of using sm is that when you wait a bit too long to do an upgrade, the script has all the required fixes waiting to be run, which after a month or two people tend to forget about.

But that's a good story, my goal was and continues to be to help people avoid the reinstallation blues, and just keep rolling along, ideally of course not waiting as long.

Just to keep in in perspective, with kanotix, I couldn't keep upgrades going much longer than about 8 months, after that sid changed too fundamentally, so that was the maximum time users last year could wait to do an upgrade. With etch freeze, that time has been extended a bit, last year, what killed it was an xorg update that I just could not find a solution for, so I cut off support at that point for kanotix 2005-4 and cebit editions that had never been upgraded (updates systems of course continue to be fully supported). But not bad I'd say.

Check with sysv-rc-conf about unneeded services running, that's often what slows boot times down, and think of removing cruft from the system, it should be fine, ALL my kanotix conversions are going fine, and some get upgraded only rarely.

thanks for the kind words, it's always nice to hear that sm is working for people, that was and continues to be my hope, to help smooth out sid a bit.
SaberBlaze - Jul 12, 2007 - 05:56 AM
Post subject:
Thanks h2. Even with removing some cruft, it's still not as fast as my other comp running sidux (not to mention that it has slower hardware than this one). It's no big deal really, I just have to backup all my themes for kde and stuff and my firefox profile and then I'm all set. I like to start fresh anyway.

One question though. In the miscellaneous tweaks of portion of your script, one of the tweaks is "mozilla-tweaks." It states that it does several mozilla product tweaks, such as dump gtk file handler and tweak_gecko_prefs. What exactly does the these two things do? I'm assuming the dumping the gtk handler will replace the save as dialog of the browser with something like the kde save as dialog? I assume the gtk file handler tweak does something as outlined here:

http://www.pclinuxos.com/forum/index.php?topic=10559.0
or the newer "ui.allow_platform_file_picker" set to false

As for the gecko prefs, I assume it does speed tweaks?
Thanks for your help.

EDIT:I read through the forum postings and I see that the gtk handler tweak does what I thought it did.
h2 - Jul 19, 2007 - 05:18 AM
Post subject:
version 7.2.0: sad news, had to rename sm to smxi due to a recently created debian package named sm. that's right, our name was stolen right from under our feet. That's the cost of being not quite debian yet though, so we have to live with it.

Nothing else changed, the change will happen automatically whether you use sm, du-fixes-h2.sh to start.

Remember, until you run the change, smxi will not be available to autostart first runs, although it will be in sidux-scripts tomorrow.
paleoflatus - Jul 19, 2007 - 06:21 AM
Post subject:
I spotted the interloper with his "sm" programme - I think it was in debian news - and almost sent you a message about it. Debian's great, but it's a shame about the lack of courtesy, as you were clearly there first and your script is popular and brilliant.

There's no justice, but we can live with the change. It's the big picture that counts and sidux users are way ahead!
h2 - Jul 19, 2007 - 06:41 AM
Post subject:
Yes, I emailed him asking him to consider changing due to the large number of real script users now, but he wasn't willing to change it. I also consider that a disinctly discourteous act, especially given the fact that sm has a vastly larger user base and active user population than his thing, which I doubt more than a few hundred people at very most will ever use.

Anyway, that's life, some people do the right thing when presented with the chance, others quote rules and such stuff. I would have changed sm had I received such a legitimate email, and I would have done it right away, but that's life.

Unfortunately slh needed the name changed fast for preview release for gaia, so that's that, I didn't have time to try to reason with the guy, but my feeling is it wouldn't have worked anyway, so that's probably fine. Now, however, I know why people do things like actually copyright/trademark their works, instead of just relying on people doing the right thing.
DeepDayze - Jul 19, 2007 - 02:24 PM
Post subject:
Some people choose to act like pricks, h2. I am sure your script used the sm name first.
SaberBlaze - Jul 19, 2007 - 09:29 PM
Post subject:
That's the crazy world we live in. The name is still pretty short and serves our purposes.
h2 - Jul 19, 2007 - 11:55 PM
Post subject:
version 7.2.2: small change, decided to also rename, for clarity, the script log and config files, to: /etc/smxi.conf and /var/log/smxi

Deepdayze, I'm not sure I'd use the word 'prick' here, it's more of a "he could have done it differently, but chose to not do so" type thing. i'd say, maybe a bit linear, inflexible, rigid, more than a negative term like prick.
h2 - Jul 20, 2007 - 06:10 PM
Post subject:
2.6.22.1-slh*-smp-5 kernels added.

Quote:
upgrading (at least from prior 2.6.22.* kernels) is recommended (not security relevant, but partly serious bugfixes), just that iwlwifi is a prominent and fragile/ time intensive piece of shi^whardware we can't test ourselves

h2 - Jul 22, 2007 - 06:23 PM
Post subject:
2.6.22.1-slh*-smp-6 kernels added
h2 - Jul 23, 2007 - 06:44 PM
Post subject:
2.6.22.1-slh*-smp-7 kernels added
h2 - Aug 01, 2007 - 08:27 PM
Post subject:
version 7.3.0: Lots of fun changes.
Added script debugger. This is of interest only to me, or people working on testing something for it.

Removed all legacy kanotix id stuff from check version

Improved version detection to use regular expressions for 64 bit or not sidux. This lets script use only one entry per sidux release instead of the two it had before.

Cleaned up all legacy pre and post du fix for < 5 distro version id. No more kanotix in other words in any way, shape or form.

Added a new function that goes along with package_removal, package installer.

package_installer takes 2 values: $1 package to install; $2 type of install:
1. force
2. optional
3. force-always
1 and 2 run the install only if package is not present in system. 3 runs it always one time, then updates /etc/smxi.conf to note the package has been forced updated to avoid repeat installs. This is working nicely now.

These changes should all be transparent to users, unless there's a new bug with them.
h2 - Aug 05, 2007 - 06:14 PM
Post subject:
2.6.22.1-slh*-smp-12 kernels added.
h2 - Aug 09, 2007 - 05:48 PM
Post subject:
2.6.22.2-rc1-slh*-smp-1 kernels added.
h2 - Aug 10, 2007 - 07:23 PM
Post subject:
2.6.22.2-slh*-smp-1 kernels added.
h2 - Aug 15, 2007 - 01:33 AM
Post subject:
2.6.22.3-rc1-slh*-2 kernels added.
h2 - Aug 22, 2007 - 04:21 AM
Post subject:
new kernels: 2.6.22.5-rc1-slh*-smp-1 added. Also removed a bunch of other kernels that are no longer needed, leaving always at least one of each major version since 2.6.18.6 in case users need them to see or test special hardware type issues.
h2 - Aug 23, 2007 - 06:22 PM
Post subject:
2.6.22.5-slh*-smp-1 kernels added.
h2 - Aug 24, 2007 - 12:29 AM
Post subject:
2.6.22.6-rc1-slh*-smp-1 - must be some quick bug fix or something, slh is once again not only on a kernel rampage, but putting out stuff days before it's announced on lwn.net
h2 - Aug 26, 2007 - 06:06 PM
Post subject:
2.6.22.6-rc1-slh*-smp-2 kernels added. Also added to kernel installer a post kernel install item that will force: update-initramfs -u -k <newly installed kernel
to run, which will hopefully fix an issue some users report on install of new kernels.
h2 - Aug 29, 2007 - 03:25 AM
Post subject:
new in package installer section, utilities: ceni networking tool. This one is by kelmo, and has a cool functionality that netcardconfig doesn't. Give it a try if you want, it's still young, but it works really well, especially for wifi stuff.

Features a scanner, shows available networks, etc. Fun stuff. Highly recommended by... me... heh heh. It's cool, try it out.
h2 - Aug 29, 2007 - 04:51 PM
Post subject:
new testing kernels, smxi -K option only: 26.23-rc4-slh*-smp-1 added. As always with testing kernels, use at your own risk, give feedback on issues if you want to do early testing, otherwise, just keep using the current latest defaults.
UncleDeadley - Aug 29, 2007 - 06:47 PM
Post subject:
h2, the last two times I used the script my sources.list file was replaced with what seems to be a default sidux one. How do I keep it from doing that?
h2 - Aug 29, 2007 - 06:51 PM
Post subject:
that should never happen. If it did, it's a bug.

I've never seen anything like that bug though, so it's hard to say what it might be.

Check your system by: updatedb
then: locate smxi
then: locate sm-*

and make sure there are no files listed anywhere other than /usr/sbin and /usr/local/bin

what you're describing can't actually happen unless you are repeatedly deleting /etc/smxi.conf and even then it really can't happen unless you are doing a sidux conversion, which you would have to actively instigate, it's not a passive process.

But top guess is extra files sitting somewhere, that's almost always the cause of weirdnesses.
UncleDeadley - Aug 29, 2007 - 08:13 PM
Post subject:
the only thing that showed up was stuff in /var/log/smxi. haven't deleted smxi.conf. Thanks for the suggestions. I'll keep an eye on it.
h2 - Aug 31, 2007 - 03:27 PM
Post subject:
2.6.22.6-slh*-smp-1 kernels added.

smxi -K option kernels added: 2.6.23-rc4-slh*-2

(as always, -K for testing, advanced users, and debugging)
Crust - Aug 31, 2007 - 06:56 PM
Post subject:
devil told me ndiswrapper is broken for the latest kernel. The latest kernel doesn't include it.
slam - Sep 01, 2007 - 07:00 AM
Post subject:
Also the commercial nvidia driver is not ready for kernel 2.6.23 yet, and needs to be patched in order to run: http://www.linuxinsight.com/nvidia-linu ... .6.23.html .
Greetings,
Chris
DeepDayze - Sep 01, 2007 - 02:45 PM
Post subject:
Think ndiswrapper needs to be recompiled and/or patched for this kernel
h2 - Sep 01, 2007 - 04:46 PM
Post subject:
slam, the patches are already in sgfxi, as of a few days ago. I just posted about this now in hardware forums. I'd forgotten to mention that publically.
h2 - Sep 01, 2007 - 09:33 PM
Post subject:
Advanced kernel install: smxi -K
new kernels added: 2.6.23-rc5-slh*-smp-1

As always, advanced kernels for testers and users who like to check out the cutting edge.
h2 - Sep 03, 2007 - 09:53 PM
Post subject:
Advanced kernels added: 2.6.23.-rc5-slh*-smp-3 added

Again, these are testing kernels, via: smxi -K

I'd say these kernels are getting pretty close to ready for the big time, so feel free to give one a try if you want.
h2 - Sep 04, 2007 - 04:25 PM
Post subject:
New kernels:
default: 2.6.22.6-slh*-smp-4
smxi -K : 2.6.23-rc5-slh*-4

Same as ever, see above for smxi -K advice.
h2 - Sep 05, 2007 - 02:52 AM
Post subject:
Version 7.4.0: new feature, integrated with svmi, the new virtual machine installer script. That script is still quite basic, but the vbox stuff works completely, and you'll have a vbox install running with no further fuss.

Also has options to download, install and run anyany stuff for vmware, and will download and install v**multimedia** and qemu.

More work needs to be done on the vmware and qemu parts, hopefully those will be basically done tomorrow for these purposes.
piper - Sep 05, 2007 - 04:09 AM
Post subject:
Alot of testing here (linux distros, reactos) and working fine Smile
sepultina - Sep 06, 2007 - 05:33 PM
Post subject:
Hello,
One very very small thing. In the smxi script on the svmi part you have a "quit" but this is "continue".

And one question:
Do i need the vbox modules? Or are this installed automatic with the first install of vbox
Do i need this after an new Kernel?

Sorry, for my english
h2 - Sep 06, 2007 - 10:56 PM
Post subject:
Yes, you need the modules on first install, although I may make that automatic like on vware, and yes you need to reinstall module for every new kernel.

The svmi script is a standalone module that is started by smxi, which is why it says 'quit', but you're right, I can make that say continue if it's started by smxi and not run alone.
h2 - Sep 13, 2007 - 04:13 AM
Post subject:
New kernels: 2.6.22.6-slh*-smp-5

New slh advanced kernels: smxi -K
2.6.23-rc6-git1-slh*-smp-3

Sorry, I was a bit late on these, things came up.
Aurelius - Sep 13, 2007 - 11:26 PM
Post subject:
h2 wrote:
New kernels: 2.6.22.6-slh*-smp-5

New slh advanced kernels: smxi -K
2.6.23-rc6-git1-slh*-smp-3

Sorry, I was a bit late on these, things came up.


It's quite OK h2, things will always come up.

Looking around, it would seem a lot of things might be coming up, like xorg, kernel changes, graphics driver changes, you name it. It should be an interesting fall/winter for sidux and linux users generally.

I am in total awe of smxi and the way you maintain it, and for all you do, this vodka martini (shaken, not stirred) is for you. Very Happy
h2 - Sep 18, 2007 - 04:17 PM
Post subject:
new kernels: 2.6.22-slh*-smp-6

For advanced, smxi -K
2.6.23-rc6-git7-slh*-smp-2
knithx - Sep 19, 2007 - 02:47 PM
Post subject:
What about NVIDIA graphics driver 100.14.19?

Here you go:

http://www.nvidia.com/object/linux_disp ... 14.19.html
h2 - Sep 19, 2007 - 04:18 PM
Post subject:
Those have been up and live now for about 12 hours. Please check before posting in the future.
op4latino - Sep 19, 2007 - 05:08 PM
Post subject:
Code:
-p Print currently supported drivers, <default>:<latest>:<legacy1>:<legacy2>
   then exit the script without doing the driver download/install.

sgfxi -p
ERROR: (250) You must be out of X/KDE to run this graphics installer.
Exiting script now.
Is it posible to have -p in X?
h2 - Sep 19, 2007 - 05:15 PM
Post subject:
no, it's not. -p is not really a user option, I should actually remove it from the -h option list, it was replaced by the listing of currently supported drivers in -h itself.

keep in mind of course that sgfxi will not have the latest to show until it is updated, and it won't update until it's run as root.

However, I think I will add a force update option, -U now that I thi nk of it, after it passes the root test, but before all other tests.

I had an issue with xorg 1.4 failure because the script could not update itself before the version detection failure, so I think I'll patch that now, then you can update the scirpt forced in x, and see the latest drivers.
h2 - Sep 19, 2007 - 05:45 PM
Post subject:
sgfxi update: added new option -U. Removed -h view of -p, which is really not a user option, and was replaced by the driver information using -h a while ago.

-U can be run as root, in x, and will run a force update on sgfxi, which will then let users see the latest drivers with sgfxi -h
DeepDayze - Sep 19, 2007 - 05:47 PM
Post subject:
Ya, had that problem, h2. Was able to install the new nvidia driver by changing the sgfxi script to allow 100.14.19 and also had to change the X server detection string as well to allow -o option and running it with the -R to keep it from trying to download an update.
h2 - Sep 19, 2007 - 05:51 PM
Post subject:
Yes, that's why I added this, it runs the update before x version detection now, the only things that make it exit are solid things that the script will never support, like ubuntu detection, no 2.6 kernel, no xorg, and so on.

The update occurs before the rest of the detections now, then just exits showing the new version information.
h2 - Sep 19, 2007 - 05:55 PM
Post subject:
New option in sgfxi: sgfxi -v
Prints sgfxi version information and exits. Useful to make sure you have latest version. Can be run as user, and in x.
DeepDayze - Sep 19, 2007 - 05:56 PM
Post subject:
That's great, h2...there must been a bug somewhere I figured. Hopefully won't need so many dirty hacks to get working Wink
op4latino - Sep 20, 2007 - 04:22 AM
Post subject:
Thank you for both -u and -v. Very appreciated.
h2 - Sep 20, 2007 - 05:32 PM
Post subject:
new kernels: 2.6.22.6-slh*-smp-8
Advanced kernels ( smxi -K ): 2.6.23-rc7-slh*-smp-1
h2 - Sep 20, 2007 - 05:33 PM
Post subject:
op4latino, that's -U and -v
H-Cl - Sep 20, 2007 - 09:58 PM
Post subject:
Hi H2

h2 wrote:
Can be run as user, and in x.
would it be very complicated to make a "download only" option, that runs (as root) in X and an "offline installation" mode, that runs in console mode. This might solve my problem of upgrading the system in my companys' network (http://sidux.com/PNphpBB2-viewtopic-t-2386.html) because there is an alternative for internet connections to the proxy: A java applet in the intranet, that manages the connections. I absolutely don't know how that works, I only know that if that applet is started, I can browse without the proxy. But to run this applet I need a browser and so I need X for downloads with wget.

H-Cl
h2 - Sep 22, 2007 - 03:42 AM
Post subject:
version 7.4.1:
Added bcm43 fix, will install l b43-fwcutter if bcm43xx-fwcutter is installed.

This will handle a coming kernel module, b43 change.
h2 - Sep 22, 2007 - 03:22 PM
Post subject:
2.6.22.7-slh*-smp-1 kernels added.
h2 - Sep 25, 2007 - 06:18 PM
Post subject:
2.6.22.8-slh*-smp-1 kernels added
2.6.23-rc8-slh*-smp-1 kernels added
h2 - Sep 26, 2007 - 11:37 PM
Post subject:
2.6.22.9-slh*-smp-1 kernels added
h2 - Sep 29, 2007 - 07:45 PM
Post subject:
advanced kernels added: 2.6.23-rc8-git3-slh*-smp-1

These are: sxmi -K
install kernels.
paleoflatus - Sep 29, 2007 - 11:45 PM
Post subject:
h2,

FYI, I think you'll be pleased to hear that I used smxi -K and smxi to load the new kernel, upgrade and run through the tweaks about half an hour ago. Everything seems to be working fine, so far.

The box:
bob@desktop:~$ infobash -v3
Host/Kernel/OS "desktop" running Linux 2.6.23-rc8-git3-slh-smp-1 i686 [ sidux 2007-03.1 - Γαια - kde-full - (200708151444) ]
CPU Info (1) Intel Core2 6300 @ 2048 KB cache flags( sse sse2 nx lm pni vmx ) clocked at [ 1596.000 MHz ]
(2) Intel Core2 6300 @ 2048 KB cache flags( sse sse2 nx lm pni vmx ) clocked at [ 1596.000 MHz ]
Videocard nVidia G70 [GeForce 7300 GT] X.Org 1.4.0 [ 1024x768 @50hz ]
Network cards Intel 82566DC Gigabit Network Connection, at port: 30e0
Processes 164 | Uptime 59min | Memory 243.1/2009.8MB | HDD ATA ST3250620AS,GENERIC USB DISK DEVICE Size 250GB (18%used) | GLX Renderer GeForce 7300 GT/PCI/SSE2 | GLX Version 2.1.1 NVIDIA 100.14.19 | Client Shell | Infobash v2.67

I'm still in awe of your work!

...Bob.
zulu9 - Sep 30, 2007 - 01:15 AM
Post subject:
@paleoflatus
so what you're saying is newest nvidia runs with 2.6.23 kernels??
nitto - Sep 30, 2007 - 01:53 AM
Post subject:
hmm... I'm not the only one running "Linux 2.6.22.9-slh-smp-1 i686" (nVidia NV43 [GeForce 6600]), am I?
paleoflatus - Sep 30, 2007 - 02:32 AM
Post subject:
zulu9,

I guess so - it's working for me, but that's just my observation. I'm no expert, but I thought it was worth a try. I kept the old kernel as an option, in case it failed.
craigevil - Sep 30, 2007 - 05:54 AM
Post subject:
zulu9 : slam(rats it was eitehr slam or slh) said in irc friday night it ;nvidia works with the 2.6.23 kernel just fine, a couple others did the infobash thing and they were running both with no issues either.
h2 - Oct 01, 2007 - 03:20 AM
Post subject:
version 7.4.2
Added xorg 7.3 updater functions, most are in sm-lib-misc-tweaks

Users get choice of updating, quitting, updating to intel syntax, or putting on
hold/install as before.

Also fixed some smaller issues with nvidia/fglrx and xorg 7.3, removed all older drivers in sgfxi for nvidia, so only 7.3 supporting drivers are now options.

Fglrx users, as usual, are out of luck, no options, they have to leave xorg 7.3 on hold/install, which is an option in the new functions.
h2 - Oct 01, 2007 - 03:42 AM
Post subject:
intel upgrade may cause some problems, we'll see how it goes.
h2 - Oct 01, 2007 - 05:57 PM
Post subject:
new advanced kernels: 2.6.23-rc8-git4-slh*-smp-2

these are: smxi -K

kernels.
h2 - Oct 05, 2007 - 03:55 PM
Post subject:
New advanced kernels added: 2.6.23-rc9-git2-slh*-smp-1

This is quite close to final release for new 2.6.23 series, so give it a try if you want.

These are: smxi -K
option installed kernels. No new standard kernels.
snvv - Oct 05, 2007 - 07:20 PM
Post subject:
I tried 2.6.23 a week ago. nvidia 7186 didn't installed with the new kernel...
h2 - Oct 06, 2007 - 01:01 AM
Post subject:
New advanced kernel: 2.6.23-rc9-git3-slh*-smp-1

same old: smxi -K
to install all advanced kernels.
RazberrieTart - Oct 07, 2007 - 06:20 AM
Post subject:
I have to share.

I ran smxi all by myself tonight Smile ALL BY MYSELF !!!!

smxi -- so simple our resident pastry can do it -- confirmed Very Happy
op4latino - Oct 08, 2007 - 03:09 AM
Post subject:
RazberrieTart wrote:
all by myself tonight Smile ALL BY MYSELF !!!!

http://www.azlyrics.com/lyrics/greenday ... yself.html Wink
DeepDayze - Oct 08, 2007 - 03:32 AM
Post subject:
Laughing
h2 - Oct 08, 2007 - 08:47 PM
Post subject:
new standard kernels: 2.6.22.10-rc1-slh*-smp-1

new smxi -K advanced kernels: 2.6.23-rc9-git6-slh*-smp-1
h2 - Oct 09, 2007 - 10:10 PM
Post subject:
new smxi -K advanced kernels: 2.6.23-rc9-git7-slh*-smp-1
h2 - Oct 10, 2007 - 12:25 AM
Post subject:
New stable kernels, after all these releases: 2.6.23-slh*-smp-1

This replaces the smxi -K kernels. As usual, you can still install older kernel versions using the advanced install options in smxi kernel install section.
h2 - Oct 10, 2007 - 09:03 PM
Post subject:
new stable kernel: 2.6.23-slh*-smp-2
h2 - Oct 12, 2007 - 08:26 PM
Post subject:
2.6.23.1-slh*-1 kernels added as default standard
h2 - Oct 16, 2007 - 01:51 AM
Post subject:
new stable kernels: 2.6.23.1-slh*-smp-3

I assume this fixes some issue, so if you are not having any issues, no need to move from -1 to -3 I would guess.
zulu9 - Oct 16, 2007 - 01:58 AM
Post subject:
quanta and quanta-data are on hold now because of version mismatch (at least on i386).
the hold can be taken back tomorrow probably. so far it seems no other problems with new kde 3.5.8 exist.

EDIT: 16.10.07
quanta back to normal
hold in smxi taken off
dacorsa - Oct 16, 2007 - 08:27 AM
Post subject:
i have always this error: why?


Code:
 After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]?
Setting up b43-fwcutter (1:008-1) ...
dpkg: error processing b43-fwcutter (--configure):
 subprocess post-installation script returned error exit status 10
Errors were encountered while processing:
 b43-fwcutter
E: Sub-process /usr/bin/dpkg returned an error code (1)

severin - Oct 16, 2007 - 09:15 AM
Post subject:
That's it? No more error messages?
dacorsa - Oct 16, 2007 - 11:36 AM
Post subject:
dacorsa wrote:
i have always this error: why?


Code:
 After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]?
Setting up b43-fwcutter (1:008-1) ...
dpkg: error processing b43-fwcutter (--configure):
 subprocess post-installation script returned error exit status 10
Errors were encountered while processing:
 b43-fwcutter
E: Sub-process /usr/bin/dpkg returned an error code (1)


when i make d-u i have always this error...how can i resolve it?? why doesn't configure b43-fwcutter??

thanks

best regards
severin - Oct 16, 2007 - 12:39 PM
Post subject:
if you don't need b43-fwcutter, the easiest way to circumvent this kind of error is to remove it:
Code:
apt-get remove b43-fwcutter
. You might need to run a
Code:
apt-get install -f
afterwards (yes, *no* arguments after the -f). You know whether you need b43-fwcutter, when you know whether you got a broadcom WLAN adapter; or put more easily: if you can still get online even though b43-fwcutter didn't install properly, you shouldn't have trouble after deleting it.

There seems to be something wrong with the package's current version, the post-installation script mustn't bail out
h2 - Oct 19, 2007 - 02:09 AM
Post subject:
new stable kernels: 2.6.23.1-slh*-smp-8
bluelupo - Oct 19, 2007 - 07:04 PM
Post subject:
h2 wrote:
new stable kernels: 2.6.23.1-slh*-smp-8

Hi h2,
I have the new kernel installed 2.6.23.1-slh-smp-8 and then my system is frozen (Twice). Kernel 2.6.23.1-slh-smp-1 running well.

Excerpt from /var/log/kern.log (error message)
Code:

Oct 19 19:41:40 bluelupo kernel: hdb: dma_intr: status=0x00 { }
Oct 19 19:41:40 bluelupo kernel: ide: failed opcode was: unknown
Oct 19 19:41:41 bluelupo kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 19 19:41:41 bluelupo kernel: hdb: dma_intr: error=0x04 { DriveStatusError }
Oct 19 19:41:41 bluelupo kernel: ide: failed opcode was: unknown
Oct 19 19:43:13 bluelupo kernel: NVRM: Xid (0001:00): 16, Head 00000000 Count 00008d89
Oct 19 19:43:21 bluelupo kernel: NVRM: Xid (0001:00): 16, Head 00000000 Count 00008d8a
Oct 19 19:43:29 bluelupo kernel: NVRM: Xid (0001:00): 16, Head 00000000 Count 00008d8b
Oct 19 19:43:31 bluelupo kernel: NVRM: Xid (0001:00): 8, Channel 00000000
Oct 19 19:43:47 bluelupo kernel: NVRM: Xid (0001:00): 8, Channel 0000001e
Oct 19 19:43:47 bluelupo kernel: NVRM: Xid (0001:00): 16, Head 00000000 Count 00008fe2
Oct 19 19:43:55 bluelupo kernel: NVRM: Xid (0001:00): 8, Channel 00000020
Oct 19 19:43:55 bluelupo kernel: NVRM: Xid (0001:00): 16, Head 00000000 Count 00008fe3
Oct 19 19:44:29 bluelupo kernel: NETDEV WATCHDOG: eth1: transmit timed out
[...]

h2 - Oct 22, 2007 - 04:57 PM
Post subject:
new stable kernels: 2.6.23.1-slh*-smp-9
Dutchy - Oct 22, 2007 - 07:52 PM
Post subject:
damn, it figures. I install 8, and 9 comes out the same day.

btw, got a request for the new ati 8.41.7 driver in sgfxi. Wirecheif said that it's the only version that will support his card, so he had to install it the "hard way". All working fine according to him, but of course I cannot test it.
h2 - Oct 22, 2007 - 08:28 PM
Post subject:
sgfxi -o 8.41.7

but I don't have any of the patches it needs, or is it working after all with xorg 7.3 and kernel 2.6.23?
h2 - Oct 26, 2007 - 07:34 PM
Post subject:
new stable kernels: 2.6.23.1-slh*-smp-16
op4latino - Oct 27, 2007 - 04:48 AM
Post subject:
holly [insert noun here], thanks for you hard work, slh
Crust - Oct 27, 2007 - 01:29 PM
Post subject:
Don't know where exactly to post this, but I was having unexplainable wireless problems that I couldn't fix. The new 2.6.23.1-slh*-smp-16 solved everything.

-Crust
h2 - Oct 27, 2007 - 06:47 PM
Post subject:
new stable kernels: 2.6.23.1-slh*-smp-18
h2 - Oct 29, 2007 - 07:23 PM
Post subject:
new stable kernels: 2.6.23.1-slh*-smp-19

For anyone using fancontrol, it's working again, I don't know which kernel fixed it, but it's finally back, which is what had kept me on 2.6.21 for so long.

You may need to reconfigure it using the pwmconfig utility to get it back running.
craigevil - Oct 29, 2007 - 07:31 PM
Post subject:
$ pwmconfig
bash: pwmconfig: command not found
What package is that command in?
h2 - Oct 29, 2007 - 07:36 PM
Post subject:
lm-sensors, first you need to do: sensors-detect, write to modules, then reboot, then do this, then create the init.d fancontrol file.

Maybe I'll post a howto now that it's working again. But fancontrol is part of sensors.
Dutchy - Oct 29, 2007 - 08:19 PM
Post subject:
h2: no, the 8.41.7 ATI driver is not working with xorg 7.3

I confirmed it with wirecheif, turns out he still uses xorg 7.1, so it's a false request. Sorry to trouble you in the first place. Damn I wish the vapor would materialize.
h2 - Nov 01, 2007 - 06:33 AM
Post subject:
Version 7.5.0

New feature: kernel download mirror selector. After going over my download limit this month on techpatterns.com, I had to implement the kernel download mirror option, that forces users to select from one of the many global sidux kernel download mirrors.

What does this mean? It means sidux is getting more and more popular, since 1 year ago, about 2 times more users of the kernel install feature on average.

Redid set_32_64 logic to handle more complex kernel lists and other variables set.

Redid main kernel installer function to handle using user set kernel mirrors.

Added -M option to let users manually reset mirror. This works just like the
debian mirror -m sources.list option except it sets /etc/smxi.conf instead.