kanotix.com

Installation - h2's Script
michael7 - 05.07.2006, 23:45 Uhr
Titel: h2's Script
h2,

Your script is excellent. I used it again today on a friend's computer. Thank you for sharing it with us.

Michael

P.S. For those of you who don't know what I'm referring to, it's a dist-upgrade script with extra features. You can find it at:
http://techpatterns.com/forums/about736.html
h2 - 06.07.2006, 02:08 Uhr
Titel: RE: h2
I don't pay this guy to post these things, I swear it...

as always, user feedback is appreciated - good, bad, indifferent, must have missing feature, whatever.

Especially of interest is ati/radeon results. Supposedly 2.6.17 is not playing well with some ati/radeon stuff. I don't use ati so i can't test this.

While the script simply uses kano's install-fglrx-debian.sh, it's good to know what kinds of results people are having with the new kernel, which you install if you use the 'upgrade kernel' option on the script. Kano reports issues with ati and 2.6.17.
michael7 - 06.07.2006, 02:35 Uhr
Titel:
Both my friend's computer and mine have NVidia cards, so I can't help with an evaluation of how it works with ATI Radeon cards. It works great with NVidia cards though. Sehr glücklich
Swynndla - 06.07.2006, 03:03 Uhr
Titel:
I think it's the just the "legacy" R200 ati cards that are having issues with the 2.6.17 kernel (that is, the closed source 3-d ati drivers that are having the issue with supporting the R200 card properly) ... I think the "modern" R300 ati cards work.
SaberBlaze - 06.07.2006, 04:16 Uhr
Titel:
So is this the thread to post feedback on the script now? I didn't want to do a dist-upgrade until later, so I updated the kernel to 2.6.17.3-slh-up-1 with the Kanotix-Update-Gui, it installed the fglrx drivers for my x800 pro and everything works fine. I guess these isn't exactly feedback on the script, but if it works with just updating the kernel, then it should work for the dist-upgrade too (unless some packages cause conflicts or something).

Also, there is work on an experimental open-source driver for the r300 and up cards made by reverse engineering something I think.
op4latino - 06.07.2006, 05:07 Uhr
Titel:
h2's script has been updated, so there shouldn't be more ATI drivers problems.

NOTE: h2's script uses install-fglrx-debian.sh, so if install-fglrx-debian.sh can't install the drivers in your PC, the first one wouldn't either
UncleDeadley - 08.08.2006, 00:46 Uhr
Titel:
I tried the script out today on a stock Easter RC4 installation and it seemed to work ok at the time. Did not choose to upgrade kernel. However, now the really cool program that Easter RC4 came with for tuning in radio stations is gone. Can somebody tell me what it was called? I am dying without it. Oh, and I have an ATI MR 9600 in my laptop (fujitsu N5010). Video worked fine after a reboot. It was flaky before that.

Edit: ahh, found it myself. Streamtuner was the name of the package. How bout that.
Ahhhh Cool
/me relaxes to groovy tunes of brasil.
jbs1136 - 08.08.2006, 07:54 Uhr
Titel:
Read the above post and thought I would share my experience. I installed (clean) the easter rc4 and then used h2's script. Read everything before hand and went right through it. So easy it made me feel good about finally installing Kanotix. I have an ATI X1600 pro and it installed perfectly. Never knew this stuff was so easy Smilie Great job h2.

John
DeepDayze - 08.08.2006, 15:37 Uhr
Titel:
Would something like what Automatix (for Ubuntu) be a good idea for kanotix? I heard that script installs the stuff Ubuntu cannot include, such as **censored** , Acrobat...etc
makke - 08.08.2006, 16:03 Uhr
Titel:
ask in irc
h2 - 08.08.2006, 20:13 Uhr
Titel:
Keep in mind that my script is primarily a glue script for the various scripts and fixes that are created by the Kanotix team members. That means your kernel installs and runs because of slh, many fixes and graphics install happens because of kano's scripts, and the sid fixes are developed and distributed as kanotix .deb packages by the kanotix team members. So give them the thanks they deserve, what they do is hard and takes a lot of skill.

DeepDayze: no, it's not a good idea, for many reasons. This is not a topic that needs to be raised in the forums however.
DeepDayze - 08.08.2006, 23:43 Uhr
Titel:
I am not knocking the Kanotix team or you, h2...its all good Smilie
feffer777 - 08.08.2006, 23:51 Uhr
Titel:
I usually d-u using the CLI steps in the kanotix manual, but when the new kde stuff started coming in, I waited for a few weeks. I was a bit worried about it, and decided to try h2's script. Worked great! Very clear steps. I have two machines so I had h2's instructions on screen on one, while I upgraded the other. If you don't have this, probably better to print them out before starting. I didn't really need to check back once the script started, but it's a comfort thing to have the instructions in hand.

h2, it's especially nice that you're continually updating the script to include the latest fixes. Thanks a bunch.

UncleDeadley, I like and use Streamtuner too. Was it actually removed during an upgrade? I noticed that mine worked strangely for a few days, but was fixed in an upgrade. Mine was never actually removed, though.

Regards,
Ron
h2 - 09.08.2006, 00:10 Uhr
Titel:
deepdayze, I just want to make sure people reading this don't fall under the mistaken assumption that it's my script doing all these magic things, when it's actually the kano team's stuff in the internals doing the heavy lifting parts. I didn't think you were knocking anyone, don't worry. What the script does is basically collect all the factoids, scripts, howtos, fixes, etc, you need to know into one place. And believe me, that's plenty for me at this point...

There was an upgrade recently that forced the removal of streamtuner, yes. It depends on a package that has been changed, so it's uninstalled during the upgrade. Always look at what is being removed, very very very closely, frequently something may be removed just because one of the libraries it depends on changed names or format, just take a note of this, and reinstall it after the upgrade is done.

feffer, it's actually not a bad idea to run that script, if there are no serious warning issues, once in a while, because sometimes there are new fixes, such as the new cdrom mount fix that overwrites the old cdrom mounting fix of last week.

If there is no red WARNING on the warning / alert section, there are no known issues that do not have a resolution. In general, if there is a red warning on that section, please do not do the upgrade, it means something broke in sid and is still not fixed, or no fix is available from the kanotix team. This condition usually will last no more than a week at most, so be patient.

For users who haven't tried it, the warning stuff comes after the kernel install option, if you skip kernel install, warning comes next. That's because kernel install is actually more or less a separate feature, but has to be slightly connected for various reasons.

The script now has an option to bypass the dist-upgrade completely, and just run some tweaks and fixes, and / or graphics driver install. In general I don't recommend this, but you have the choice to do it, this being linux Cool
DeepDayze - 09.08.2006, 04:45 Uhr
Titel:
no, h2...your script works well. its good to admit its not the magic bullet, but it does make life easier managing d-u's and their pitfalls
UncleDeadley - 10.08.2006, 04:48 Uhr
Titel:
What can I say, I only scanned the 'to be removed' list this time. It was short and I didn't see any kde so I kept running. Smilie Come to think of it, the ony problem I can ever recall with a dist-upgrade was the first one I tried from within KDE. That was a long time ago, before Kanotix. I really borked that system!
etorix - 21.08.2006, 12:09 Uhr
Titel: the kernel-zip-contents
get put under /var/local
why not use /usr/src?
even /home would do,seems a obscure place for them to wind up
h2 - 21.08.2006, 18:56 Uhr
Titel: RE: the kernel-zip-contents
wasn't sure where to put them to be honest, no real good place came to mind, to me /usr/src is for source code, and I didn't want it to get mixed up with the stuff that install kernel creates there, that would be confusing.

I could put it in /home I guess, but that doesn't make much more sense to me than any other option, as long as it's known where that location is, and that location doesn't confict too badly with the file system the way it's supposed to be [/var/local is empty here, and seems to match /usr/local/bin roughly], and it's consistent. If it wasn't such a pain to get the user /home/<username> directory location, I'd put it in /home/<username>/bin, that's my preferred location.

What I can't figure out is within the filesystem naming scheme, there doesn't appear to be any default location for normal data, I've read the filesystem stuff, but every time I can't find any single location for data that makes sense. Seems odd that there is no 'data' type directory, I thought /var was sort of that, but it's not quite it, even though it sounds like it is.

on the freebsd servers I use, stuff is put in /usr/www, /usr/home, and so on, which makes no more or less sense than any other scheme I've run across. Personally, I put my website data in /var/www/, which makes sense to me, since it's already where apache puts its stuff, I guess to me it's a default, given no other place to put it that makes real sense.... I have to admit though, this is the one thing that simply makes no sense to me, no matter how many times I read the file system hierarchy stuff.
etorix - 21.08.2006, 23:15 Uhr
Titel: var/local/kernel-current
putting it in /usr/src, as /usr/src/kernel-current, makes more sense to me
as /usr/src is where kernels would be built,normally
your naming, ie '/kernel-current', is perfectly safe
and wont interfere with
any kernel-building that might go on there
check out the Makefile thats there
kernels BUILT there wind up as .debs in /usr/src
only precisely-named patches or dirs could interfere with a build
your renaming is sensible and safe
and /usr/src was where i looked first
ie, it took me awhile to find
Swynndla - 22.08.2006, 02:51 Uhr
Titel: RE: var/local/kernel-current
Gosh h2, your du script just gets better and better ... I used to to remove a whole bunch of isdn and wireless stuff etc ... and also any unused xorg stuff too ... it's great!

(and one of my friends was saying only last week how he didn't like how xorg would install by default every graphics driver under the sun)

Edit: oh afterwards I did need to do:
# apt-cache search motif-clients
... which installs libmotif3 too, as I need this for my ICA citrix client, and h2's script couldn't pick up that I needed it as I had installed this manually.
h2 - 22.08.2006, 07:10 Uhr
Titel: RE: var/local/kernel-current
Swynndla, coming soon, script options so you can skip steps, especially useful after kernel install reboot and run script again, for example.

options are not picky, you can make it -w -i -k or -kw -i or whatever combination of options, as long as they start with a -.
-h for help, as usual.

As soon as I've tested it some more it will be ready to go, version 3.4 will have the new option start stuff.

for example, /usr/local/bin/du-fixes-h2.sh -kir will skip the kernel install, the system information, and the script check for latest version, for those who are so inclined, and start straight on du warnings, which you can skip too with -w option, which will take you straight to du.

But please don't make a practice of skipping the warning, that is up to the minute stuff and is updated frequently, for example, today, you would have seen the xorg 7.1 error warning.

The xorg module removal stuff has options to keep any module you think you might want but aren't sure about, it doesn't just delete all the ones reported as unused automaticaly, although you can do that too if you want. That uses the x-un-i script clean_xorg_modules.sh by the way, with modifications.

<updated>
version 3.4 is out now, with full option support.
kernel download location is now: /usr/src/kernel-downloads
</updated>

Bluetooth removal coming too, forgot that one. And some other stuff.
UncleDeadley - 25.08.2006, 08:17 Uhr
Titel: RE: var/local/kernel-current
I have to confess, I used your script today just for fun. It really is very nice- I enjoy the color amongst other things.

Edit: oh, I also thought I would mention that my wireless (atheros) and video card (ati) were properly detected and installed. Very cool Smilie
h2 - 25.08.2006, 23:08 Uhr
Titel: RE: var/local/kernel-current
Version 3.5 is now out, with these new features:

Detects presence of active internet connection [detection bugs in that fixed now]
If no internet, gives wireless users who have just installed a new kernel option to install either ndiswrapper or madwifi kernel module when they reboot. The script does not know which is needed, so you'll have to figure that out yourself. If you use wifi, know which module you need before installing new kernel.

Has a few more options, the most important one being -u, which lets you start the script as root without being in init 3, and download and overwrite the latest version directly, without running rest of script. Then the script restarts, and will exit if you're not in runlevel 3.

You can also view the option help menu now without being in init 3, dont' need to be logged in as root either, that's du-fixes-h2.sh -h

Also, I added a test for graphics card type, please let me know if your nvidia or ati/radeon card was not correctly detected, the script will offer an option to install from a list of ati/nvidia driver in that case however.

That is available in any version after 3.5.15

Some more remove items in remove packages option. I think that's it for latest changes, plus script is cleaned up and a bit more readable now.

Zitat:
I enjoy the color

Yes, so do I, heh heh, thank op4Latino, aka Latino, for that one, he's the one who showed me how to do it.
op4latino - 26.08.2006, 04:18 Uhr
Titel:
Sehr glücklich

As soon I remember in what script I saw them, I'll take the credits Winken but if you're an old skool programmer, you already know they're called ANSI colors
jivens - 28.08.2006, 19:39 Uhr
Titel:
I know it's been said before, but have to say it again. Awesome script, H2! Thanks so much from myself and other less experienced (and yes lazy) Sehr glücklich Kanotix users!
zulu9 - 28.08.2006, 19:58 Uhr
Titel:
big thx! this script is real great and becoming better almost every day Sehr glücklich
h2 - 02.09.2006, 08:05 Uhr
Titel:
Version 3.6 now features the -m option, which allows you to change your /etc/apt/sources.list by selecting from any of the official debian mirrors worldwide before the main parts of the script runs.

When you start the script with -m, like this:

du-fixes-h2.sh -m

you will see a list of all the currently available debian country mirrors. Select the right number, and your sources.list will be updated automatically, then the script will go on to the main upgrade.

<update>The script will now give the source selection option the first time it runs, which will let the users select their prefered debian apt mirrors. After that you'll need to use the -m option when starting the script if you want to change your source mirrors in /etc/apt/sources.list.

You can put any options you like together, like this: du-fixes-h2.sh -mek
h2 - 03.09.2006, 21:16 Uhr
Titel:
Version 3.7 is now out, this one features many many subtle fixes, semi bug fixes, scripting error and syntax fixes, flow errors, subtle to not so subtle useability issues pointed out to me by various people [thanks Swyndla], etc, and more code hacks to help in my ongoing battle to get the code into a reasonably coherent condition for long term maintainance.

But the biggest change is that now the script is redone internally to be able to handle all future kanotix releases in a much more standardized way. Currently, except for maybe changing the script's 2006-01 kanotix search strings, the script is ready and waiting for 2006-1 to be released, whenever the kanotix team decides 2006-1 is truly stable and ready.

Now all fixes etc that are version dependent are controlled by a single variable, which lets me turn off version dependent fixes very easily when they are no longer required by subsequent versions. And in fact, many of the current fix option will now not be offered at all when 2006-1 users use the script, since those fixes will of course be included in 2006-1.

I was going to implement this version testing method for easter, but because too much time passed between easter rc1 and easter rc4, it wasn't technically possible to do that safely, but now that 2006-1 is somewhere around the corner, I figured it was best to deal with this now.
rich.bradshaw - 06.09.2006, 15:20 Uhr
Titel:
That is a good script! Just installed EasterRC4 fresh today, and that sorted everything out - you are a genius!

When is the next stable coming out - it seems way overdue! Its not really Easter anymore is it....
Roughnecks - 06.09.2006, 16:29 Uhr
Titel:
kernel update problem:
i installed a box of a friend yesterday with easter rc4 and used the du-fixes-h2.sh script. he uses a rt2500 wireless card. after a kernel update with the du-script it stopped working, because the script didn't install the rt2500 modules.
the kernel update function of andreas loibl's kanotix update gui prompts for and installs all available kernel modules.
did i do something wrong or is that function missing in the du-fixes script?
devil - 06.09.2006, 16:35 Uhr
Titel:
roughnecks,
so far with h2 you have to install needed modules manualy afaik (never tested it for kernel update)

greetz
devil
h2 - 06.09.2006, 19:05 Uhr
Titel:
Yes, it's semimanual install.

If you restart the script after rebooting from kernel install, and there is no internet connection present, it will give you options to install madwifi or ndiswrapper. I have been reluctant to add features I can't test myself, and since the only wireless I have is in the kernel already, I can't really test any other modules.

I am told that currently the script restart install of madwifi / ndiswrapper works fine though.

It's not a problem to put more options in though for modules, those were just the ones that were requested. I guess I could also add the option to install all modules as well, if required, although to be honest I'd prefer not to, since I don't like cluttering things up unnecessarily, especially when only one of those modules is required.
h2 - 06.09.2006, 21:14 Uhr
Titel:
Version 3.8.0 now supports installation of the following wireless modules:

at76c503a
ipw3945
linux-wlan-ng
madwifi
ndiswrapper
rt2500
rt2570
rt61

You will only see this list when you restart the script and have no internet connection. Please be patient as the connection testing proceeds, when no connection is detected, it will try to restart networking first, then if that fails, it will offer the option to install wireless modules.

I may have missed one or two of the avialable modules in the kernel package. If I did, please give me their names and I'll add them.

Please note: this will only work if you used the script to install the kernel, otherwise it doesn't know where the kernel unpack directory is.

THE SCRIPT DOES NOT KNOW WHICH MODULE YOU NEED, SO PLEASE HAVE THAT INFORMATION AVAILABLE TO YOURSELF BEFORE YOU INSTALL A NEW KERNEL IF YOU USE WIRELESS.

Script also now has the wodim cdrom/dvdrom burning fix. This runs after the dist-upgrade stuff is finished, it's automatic, you won't really see it, it's a simple fix, and resolves the cd/dvd burning issues created by the new wodim burning application.
h2 - 08.09.2006, 19:32 Uhr
Titel:
script now has a fix for the recent udev issue.

apt-get install --reinstall udev
rich.bradshaw - 10.09.2006, 17:37 Uhr
Titel:
h2, at the end of the script, if you have already done whatever option 4 is, it doesn't show up. This is fine, except that pressing 8 to install graphic drivers then does what 9 was meant to and exits the script.

If you need more details let me know, I am not in Kanotix right now so cannot check if thats it right this moment....

Excelletn script though - should definatly be on the next CD release!
The_Seeker - 10.09.2006, 19:53 Uhr
Titel:
I can confirm this as I was going to post this very error.

When you get to the 'Miscellaneous tweaks and hacks' section, the option to continue in the green text is actually the option to quit. That aside, the script is working wonderfully and I commend you on a fantastic tool!
h2 - 11.09.2006, 21:04 Uhr
Titel:
That mistake is fixed now I think. Except for little bugs like this, glad the script is working for you.
The_Seeker - 11.09.2006, 23:49 Uhr
Titel:
Thanks h2 and again, thanks for the great script.

I've been tinkering quite a bit over the last couple of weeks (as we all do) and I've used your script around 5 times, each instance on a fresh install of rc-4; every time it's gone without a hitch. Kudos.
h2 - 15.09.2006, 07:20 Uhr
Titel:
version 3.9.x now installs the new kanotix penguin graphics, for grub [including grub fixes], default background, new ksplash the first time you run the script.

It also backs up your old grub graphic to /boot/message.old, and your old kanotix ksplash. You should be able to select which ksplash you want in the kde control center, appearances, splash screen, the new or the old. Default is now the new: KanotixClouds. The old is renamed to KanotixOriginal if you preferred that one.

This backup stuff will only work if you have not done a dist-upgrade since the new kanotix graphics packages came out a few days ago.

It also gives you the option to start/stop the new boot/shutdown splashy thing. This is not the blue penguin stuff in grub/background etc, it replaces the default text start/shutdown output with a penguin graphic and a moving progress bar.

These fixes are based on Kano's kanotix graphics fix script, by the way, though modified a bit to make some parts optional, and to backup other parts.
ironwalker - 15.09.2006, 19:19 Uhr
Titel:
Thank you sir,great work and I love the new graphics by Cart.
wh7qq - 16.09.2006, 23:59 Uhr
Titel:
Nice that it works fine in 2006-1-RC1...just used it to install nvidia and a few other chores.
dpdt1 - 20.09.2006, 17:20 Uhr
Titel:
does anyody else has this message :

"root@home01:/home/dpdt1# du-fixes-h2.sh
[: 213: ==: unexpected operator
/usr/local/bin/du-fixes-h2.sh: 444: Syntax error: "do" unexpected (expecting "fi")
"

or is it just me?

i deleted the script from /usr/local/bin and re-downloaded but still the same error...
i dont know lot about programming but when i tried to put a "fi" there (before line 444), i get another error message and another..
(running kanotix64 2005-04 lite, 2.6.16.20-slh64-smp-1)

any info?
i'm trying to use it cause i read all the nice words about it, but haven't tested it myself yet...

thanks in advance,

Dimitris.
makke - 20.09.2006, 18:30 Uhr
Titel:
re-download the script and show the md5 (md5sum du-fixes-h2.sh)

edit:
get the script with wget http://techpatterns.com/downloads/kanot ... ixes-h2.sh
correct md5: ca4aa5287f7ca5800882bda22d95124c du-fixes-h2.sh
dpdt1 - 20.09.2006, 18:54 Uhr
Titel:
thanks for the answer, but no luck..
still the same error..

root@home01:/usr/local/bin# md5sum du-fixes-h2.sh
ca4aa5287f7ca5800882bda22d95124c du-fixes-h2.sh

edit] ok i got it. when i run
bash du-fixes-h2.sh
it works.
so, i probably messed up things when i was testing some advices a while ago..
h2 - 27.09.2006, 22:48 Uhr
Titel:
Added the fontconfig fix that is found in irc under !fonts

This fix is available in the fonts fixing options you see after the du finishes.

Only use this if you get the font cache errors. The cause of this is bad /etc/fonts files, and hte fix simply removes that, reinstalls the fontconfig items, then reconfigures them.

Only, again, use this is if you accidentally said 'n', keep /etc/fonts/fonts.conf when new fontconfig stuff was installed during du, and then you get those font cache errors. Most users will not need this. Also added opera keyring install.
mdmarmer - 28.09.2006, 02:17 Uhr
Titel:
Guten Tag h2, danke schon for great script ...

will the fontconfig fix solve my problem ? I have posted it in the English forum General Topics:

ttf-opensymbol -- problem with dist-upgrade of Kanotix-64
My system is running fine, but ttf-opensymbol is not fully installed or removed
I keep getting a lot of messages ending in "failed to write cache" for all fonts when apt tries to install or remove ttf-opensymbol.

Thanks for help

Mike
h2 - 28.09.2006, 19:57 Uhr
Titel:
My guess is that it will. that's a guess though.
mdmarmer - 29.09.2006, 04:19 Uhr
Titel:
Danke schon -- this fixed it.

Mike
h2 - 29.09.2006, 21:26 Uhr
Titel:
If you did a dist-upgrade today, and your openoffice.org now does not work, the script now has a post-dist-upgrade fix option that will restore your OOo to working order by uninstalling your current version and replacing it with the testing version.

If you already did a du today and your OOo is broken, use this fix, but otherwise just wait for the OOo warning to be lifted before dist-upgrading again. Unless you don't really care about using the testing version of Ooo, then just do du as normal, and run the fix after the du.

Script now also has the option to restore your initscripts configuration file to new version if you accidentally answered 'n' instead of 'y' to that question during du.

Make sure to read the du-fixes-h2.sh warning section carefully by the way, you can avoid headaches that way.
Swynndla - 29.09.2006, 21:30 Uhr
Titel:
Note: apt-get upgrade (as opposed to apt-get dist-upgrade) didn't destroy open office.
h2 - 30.09.2006, 04:16 Uhr
Titel:
script can now be started with -p option to not use pdiffs for apt-get update. Check the -h option for full option list.
ironwalker - 03.10.2006, 04:00 Uhr
Titel:
fontconfig fix doesnt fix my ttf-opensymbol problem as mentioned above.................any suggestions?
h2 - 18.10.2006, 05:04 Uhr
Titel:
Version 3.9.29 of the script should now be able to take an older 2005-4 or cebit install through the xserver upgrade without a major problem.

I want to emphasize though, doing a du on an older install is a long process, and requires a lot of install -f to get it working.

Unless you have a very good reason to do this, I recommend using the update-install option using the latest livecd, now 2006-01 rc4.

The problems only applied to non upgraded systems using old xorg stuff, so if you've been doing fairly regular dist-upgrades, this won't affect you.

You will see one new fix appear one time, but it shouldn't make any difference to most users who have reasonably up to date installs.

This issue came up because of a du failure on a vanilla 2005-4 install, with xserver-common. That is now fixed in the script. You may also see the xorg fix question again, if you've already upgraded your xorg to version 7 or greater before, you don't need to run this fix.
h2 - 18.10.2006, 09:10 Uhr
Titel:
Version 3.10.0 has a fairly complete openoffice.org installer.

You can pick your language, then it will install the correct language pack, and thesaurus/help/dictionary if one is available.

It will also ask you what desktop integration you want, kde/gnome/none to install the correct ooo integration package.
The_Seeker - 18.10.2006, 12:59 Uhr
Titel:
Zitat:

Version 3.10.0 has a fairly complete openoffice.org installer.

You can pick your language, then it will install the correct language pack, and thesaurus/help/dictionary if one is available.

Thanks h2, that's a really good idea.
Crust - 18.10.2006, 22:14 Uhr
Titel:
h2,

Great script.
The install packages menu seems to have the exit menu mislabeled as 10 when it should be 11.
Just wanted to give you feedback.

Thanks again.

-Crust
h2 - 18.10.2006, 23:23 Uhr
Titel:
Version 3.10.3: 2 new options:
  1. removes all detected -de German language packages. This is located in Package Removal section.
  2. installs h2 favorite packages, sysv-rc-conf, nano. This is located in the Package Install section. Only use this if you understand what freeze does, and what sysv-rc-conf does.

    Freeze is what keeps new services installed from starting automatically. This is a good feature for new users, but not important to have if you manage your system more actively, in fact, it's a pain in many cases. sysv-rc-conf is a console service/daemon manager. Installing sysv-rc-conf basically disables freeze from what I can tell.


The h2-favorites over time will add more features and tweaks as I get bored of doing setup stuff manually, so it will always reflect how I want the stuff setup. This may not be how you want it setup, so use it with that in mind.

Crust, yes, I caught that mistake today, that's what happens when you do this late at night. But thanks for pointing it out anyway.
Crust - 19.10.2006, 00:54 Uhr
Titel:
Great job. Just was pointing it out in case you missed it, but you were already aware of it. Smilie

Is there a down side to removing all the -de German language packages? (I only use English, can't understand any German.)

-Crust
h2 - 19.10.2006, 02:40 Uhr
Titel:
no downside if you have no need for German. For default installs, the de stuff is necessary because Kanotix is first a German, then a global, distribution. So removing them just makes for fewer packages to upgrade. I've been meaning to do this for a long time, finally got around to it today.

h2-favorites will soon probably get the new firefox tweak I learned that finally once and for all gets rid of the gtk file handling dialogue box and replaces it with a more user friendly dialogue.
rich.bradshaw - 19.10.2006, 09:26 Uhr
Titel:
just to reiterate - this script is one of the best things to happen to dist-upgrades in Kanotix ever! Thanks a lot h2!
DeepDayze - 19.10.2006, 13:57 Uhr
Titel:
I'd bet straight Debian users can benefit from such a script like h2's...there are a lot of dist-upgrade minefields out there that can BREAK a plain Debian install.
h2 - 21.10.2006, 19:05 Uhr
Titel:
version 3.10.5 now offers option to run nvidia installer with -c option, which will force the install of latest beta nvidia driver, and enables composite rendering. This will be of interest mainly for beryl testers, but it's also useful for regular users who are happy with beta driver performance.

<update>I have found a small bug with 9626 beta driver, that keeps the flash movies on this site from correctly running: http://cbs5.com

The movies hang during the opening commercial and don't move on to the actual content.

I guess I'll post this on nvidia forums since this bug does not seem to have anything to do with which flash version you run according to others, 7 or 9 beta.

To get around this, I just change the 9626 to 9625 on this line of install-nvidia-debian.sh after the kanotix scripts have updated in du-fixes, but before I run the graphics driver install [currently line 71]:

[ "$VER" = "1.0-8776" -a "$1" = "-c" ] && VER=1.0-9625

For those of you who don't know, you can move to a different console during the du script, or anything else, by hitting ctrl+alt+f2, or f3, any f up to f6. Then login, edit the other script as root, save, and go back to du-fixes with ctrl+alt+f1
XOn - 22.10.2006, 17:10 Uhr
Titel: ..doesnt work for me
Hi there,

thank you for this good script,
but it doesn't work for me on an 2005-03 CD-upgraded AMD64..

I was looking all over the net for "pieces" of commands that could bring
any changes to the situation and finally found - after three days of searching- this hint:
Zitat:
Even when reinstalling fontconfig and fontconfig-config a rebuild of the cache fails, because the installer thought fonts.conf was modified and therefore didn't update it. After copying fonts.conf.dpkg-dist to fonts.conf everything went fine and any dependent packages could be configured.

(http://forums.debian.net/viewtopic.php?t=9303)

It's no big thing, but doing so can maybe safe a lot of time.
Therefore, i want to distributed this easy solution for Kanotix-Users with a
similar configuration and a resulting non working h2-script.


Greets,
XOn
h2 - 22.10.2006, 21:45 Uhr
Titel: RE: ..doesnt work for me
Just search the script itself for the fixes, they are all in there:

Code:
echo "${S}Removing old ${C}/etc/fonts${S} file.${N}"
            rm -rf /etc/fonts
            echo "${S}Running ${C}fontconfig${S} fix.${N}"
            apt-get install --reinstall --yes -o DPkg::Options::=--force-confmiss -o DPkg::Options::=--force-confnew fontconfig fontconfig-config


Unfortunately there's no way to actually support earlier versions, or unknown debian installs, since I have no idea what they contain, how they are configured, etc.

I'd like to support debian, but it's not possible since many kanotix fixes are actually released as debs from the kanotix repositories, and without those the fixes won't work.
XOn - 22.10.2006, 22:38 Uhr
Titel: Re: RE: ..doesnt work for me
Code:
echo "${S}Removing old ${C}/etc/fonts${S} file.${N}"
            rm -rf /etc/fonts
            echo "${S}Running ${C}fontconfig${S} fix.${N}"
            apt-get install --reinstall --yes -o DPkg::Options::=--force-confmiss -o DPkg::Options::=--force-confnew fontconfig fontconfig-config


I can't really figure out, what these lines will do, but they didn't help five times i ran your script...?
If i understand these lines just a little bit, they only "remove" anything inside the /etc/font directory ?
But "copying fonts.conf.dpkg-dist to fonts.conf " had helped for me..

Greets,
XOn
h2 - 23.10.2006, 00:50 Uhr
Titel: RE: Re: RE: ..doesnt work for me
it removes the /etc/fonts directory, then reconfigures the fonts package, which creates among other things a new fonts.conf file.

However, I can't support old installs as I said, it's simply not possible, especially not 64 bit installs, which I barely test, I use version detection all over the place, so you can't just run the script and expect anything to work even if you comment out the version detection parts. The entire fixes section relies on version detection, so nothing will run if you don't use it.

This is a kanotix 2005-4 and newer only script, sorry. Besides, I tested a dist-upgrade on 64 bit 2005-3 kanotix and it failed, so that was that for me, no point in continuing.

Currently I am just barely able to support 2005-4 as it is, I thought I'd have to give up on that last week after some test du failures, but I got it running again, barely. But that's it, nothing earlier, in any shape or form will be supported.

Also, running the script more than one time for many fixes won't do any good, since most fixes are set to run only one time, then not run again on subsequent running.

Sorry I can't help more.
XOn - 23.10.2006, 10:47 Uhr
Titel: RE: Re: RE: ..doesnt work for me
Zitat:
The entire fixes section relies on version detection,

That could it have been...
but nevertheless, good work.
I used it then for a d-u and kernel update.
For that it need to run in init 3, i guess it will work more properly than a graphical d-u.
Thanks.

XOn
h2 - 23.10.2006, 20:17 Uhr
Titel: RE: Re: RE: ..doesnt work for me
If you do a graphical du, then you should expect your system to fail.

I do a lot of testing on this script, so any attempt to bypass any built in script protections without doing heavy testing on that change on at least one, ideally several, test systems is probably going to result in failure.

All protections are there for a reason, and the script cut off point of 2005-4, and not running on any other debian type system, are also there for reasons.

So if anyone is tempted to do that, please do not ask for support if that's what you did, it's pointless.
h2 - 24.10.2006, 21:27 Uhr
Titel: RE: Re: RE: ..doesnt work for me
Version 3.11.0: added new option in Miscellaneous Tweaks to get rid of all mozilla gtk file handlers and replace them with the default one which I think is included in Mozilla, but I can't say for sure, all I know is you won't see that vile gtk thing after running this fix.

This will also run automatically if you run the h2-favorites by the way.

This function will search your system, edit all the required files for firefox/iceweasel/thunderbird/icedove. Currently no mozilla or seamonkey support, if you want that, give me the directory names in /usr/lib/<product name>/ and /home/<username>/.<product name or path>/

Speaking only for myself, there is little in linux that I dislike, possibly even despise, more than the gtk file handler dialogue box, so this tweak makes me far happier than most I've created.
wh7qq - 25.10.2006, 06:27 Uhr
Titel: Re: RE: Re: RE: ..doesnt work for me
h2 hat folgendes geschrieben::

Speaking only for myself, there is little in linux that I dislike, possibly even despise, more than the gtk file handler dialogue box, so this tweak makes me far happier than most I've created.


h2,

If you are refering to that useless box that comes up when you try to select a different place to save a download, bless you. It doesn't let you see or access hidden files or directories...it is a piece of garbage (#@$!!! deleted). I'll do a fresh du-fixes-h2.sh tonight just to get rid of that (did it yesterday).

Paul

Later: Aaahhh! What a relief it is! Nice addition to the script.
h2 - 25.10.2006, 10:21 Uhr
Titel: RE: Re: RE: Re: RE: ..doesnt work for me
Zitat:
If you are refering to that useless box that comes up when you try to select a different place to save a download


Yes, that's the one, I like your description better than mine though, it's more accurate. Calling the default gtk thing a file handler dialogue box is definitely a misuse of the terms. So from now on I'll just call it what it is, that useless box that comes up.

But craigevil is the one who dug up this method by the way, I'd been looking for months but he found the hack on some other forum and posted it here, so thanks to craigevil, forgot to mention that. Figuring out how to fully automate the fix for all mozilla products was entertaining though.

By the way, the new file name text box that appears lets you type in the path, without that ridiculously non-functional auto complete that just gets in your way with the 'other thing'. And if you want to change download mimetype handlers, you get the same new file picker box to select the program, so it seems to get rid of most of the gtk useless boxes completely.

My suspicion is that you will need to run this fix for every new mozilla product that is upgraded or installed, so I'd just run it every time you see new stuff come in during the upgrade, like iceweasel, icedove new versions, etc. Running it multiple times won't hurt anything.
goatgirl - 26.10.2006, 01:01 Uhr
Titel: RE: Re: RE: Re: RE: ..doesnt work for me
Hi h2,

Just to say thanks. Your script has helped me do my first proper dist-upgrade, and sorted out a few problems along the way Sehr glücklich

GG
slh - 26.10.2006, 10:07 Uhr
Titel: RE: Re: RE: Re: RE: ..doesnt work for me
The only problem with that approach (which is known for a long time) is that it messes around in /usr/lib/, which is under dpkg's control and must not be messed with - yes, it works - yes, it shouldn't affect anything - it gets reverted on each FireFox(TM) upgrade --> it's a hack, not a solution.
h2 - 26.10.2006, 11:01 Uhr
Titel: RE: Re: RE: Re: RE: ..doesnt work for me
Yes, but unfortunately the solution involves getting the guys who program firefox to stop forcing us to use gtk file dialogues, and to start using the user default system file handlers, like they do in windows and I assume os x. And/or getting the gnome guys to implement a modern, full featured, grown up file dialogue. Since neither appears likely to happen in the near future, I'll take the hack over having to try to use that other thing, which I simply cannot get used to because it gets in my way every time I use it. I'll happily rerun it each time mozilla stuff upgrades, anything is better than that other thing.

What's really annoying is to know that all along a fully functional, albeit sparse, file handler was sitting there, available and ready to be used.

While I have every confidence that the gtk stuff will abandon this silly approach as the guys grow up and start actually seeing what their stuff really does instead of what they would like to believe it does, I can't use that thing any more, I will never miss seeing it, to me it's downright embarrassing, the thing is childish, clunky, horrible default actions, inefficient, etc...

While this hack may have been known among some, I've never seen it, and I've looked and read more than enough on this topic for my taste, I'm glad craigevil found it and posted it. Definitely in the category of simple once you know it, but basically impossible to figure out if you don't.

As hacks go, this one is pretty pleasant, almost identical to another one I found that fixed another pretty major ff useability issue re mime type handlers.
slh - 26.10.2006, 12:33 Uhr
Titel: RE: Re: RE: Re: RE: ..doesnt work for me
The whole situation is really a pity, yes - and whoever designed/ chose that damned piece of crap should be forced to use it for all eternity.
h2 - 10.11.2006, 00:30 Uhr
Titel:
Version 4.0.0

This has no functional difference for end users, it's only to make the script more maintainable long term. The script is getting too long, in other words.

I modified du-fixes-h2.sh to make it more modular by removing the following elements and made them into standalone modules. This process is transparent to the user since the script just downloads them and runs them automatically. I don't recommend using the modules alone however unless your system if freshly upgraded. But you can do it.

1. du-fixes-package-installation.sh - Package Installation
2. du-fixes-package-removal.sh - Package Removal
3. du-fixes-clean-xorg.sh - Clean unneeded Xorg modules

[Note: Package Installation is not quite standalone because it needs the kanotix version parameter passed to it for one function, but otherwise it is ok for standalone.

Now the script will only request these modules if the user selects that option.

I may cut off one more piece, kernel installation, but that one is much more core to the script than this stuff, so I'll have to look at that for a bit before proceeding.

The script already had some modules, now it's just more systematic and standardized so each module will be easier to maintain long term.

Please let me know if you experience any problems with this system.
h2 - 11.11.2006, 00:12 Uhr
Titel:
Version 4.1.0
Moved core kernel install functions to module du-fixes-kernel-install.sh
This module is not standalone, and requires all the kernel data from du-fixes-h2.sh to run. This data is passed to it with 4 parameters.

The module exits with 1 of 3 states:
0 - exit module
1 - rerun main kernel question
2 - exit du-fixes as well as module

Again, aside from finding and correcting some small errors and oversights on the advanced kernel install function, this is also not a functional change, and should hopefully also be transparent to users.

If you find any problems with kernel install, please let me know.
h2 - 11.11.2006, 01:13 Uhr
Titel:
version 4.1.1

I was lucky enough to get the ipw3945-ucode-1.13 error on one box, so I could test the fixes, and get one that works, at least in my case. So if you run the script, it should resolve that issue before the du, and it may even fix it if you've already gotten bitten by that bug.
Richard - 11.11.2006, 01:20 Uhr
Titel:
I updated to the 2.6.18.2-slh-up-1 kernel with h2's script day before yesterday.

Yesterday, I did the dist-upgrade in a konsole. Not with the script.
I had to run
# aptitude update && aptitude dist-upgrade
a couple of times before it finished but nothing like the problems others are having. I don't have an Azuz MB. Just a clone with a P4 and 512 MB.
h2 - 11.11.2006, 05:22 Uhr
Titel:
Version 4.3.0: new module added, system clean up. This is accessed in miscellaneous tweaks, clean-up-stuff.

This will give you a list of cleanup options:

  1. apt-get clean [to remove all packages from apt cache]
  2. apt-get autoclean [to just remove non-current packages from your apt cache]
  3. remove-all-kernels-completely [to remove all BUT the current kernel. If you used the script to install your kernels, it will also remove the install directories for that kernel]

    The kernel removal script will ask you for each kernel if you want to remove it, so it's probably a good idea to keep at least the most recent one in case something goes wrong with your latest kernel.
  4. remove-kernel-completely [removes current kernel only. Usually only used for debugging reasons etc. This will also remove that kernel's install directory if you installed with du-fixes-h2]
  5. clean-old-backups [this removes all backup files created by the scripts, including xorg.conf, menu.lst, sources.list, etc, so don't run this if you need to keep those backups. If you want to keep one, rename it to something else, or move it somewhere.


And that's about it for now.
piper - 11.11.2006, 05:49 Uhr
Titel:
Very Nice !
slam - 11.11.2006, 06:26 Uhr
Titel:
Richard hat folgendes geschrieben::
I updated to the 2.6.18.2-slh-up-1 kernel with h2's script day before yesterday.

Yesterday, I did the dist-upgrade in a konsole. Not with the script.
I had to run
# aptitude update && aptitude dist-upgrade
a couple of times before it finished but nothing like the problems others are having. I don't have an Azuz MB. Just a clone with a P4 and 512 MB.


Aptitude is very much depreciated in Kanotix/Debian Sid - usage of this tool is at your own risk, and we cannot support systems which have been compromised with it.

Greetings,
Chris
bushit - 11.11.2006, 16:55 Uhr
Titel:
Great script, which I use nearly every day. However, it would be even better, if it displayed the version of the graphics driver, I'm going to install. Maybe you can realize this feature.

Thank you for your work, bushit

EDIT: Thank you for the integration of the feature!
h2 - 11.11.2006, 22:47 Uhr
Titel:
version 4.3.1
Shows the driver version for fglrx, nvidia stable, and latest nvidia
Richard - 12.11.2006, 01:52 Uhr
Titel:
Zitat:
Aptitude is very much deprecated in Kanotix/Debian Sid - usage of this tool is at your own risk, and we cannot support systems which have been compromised with it.

Greetings,
Chris


Well, I've been reading a bit and am beginning to understand why you hold this position on aptitude.

http://www.linuxquestions.org/questions ... ost1852942
"No matter which package manager you wish to use, just keep one thing in mind, do not switch back and forth. The three P.M.'s do not keep track of each other; so if you use apt for the first 6 months, and then try aptitude, it will try uninstalling all of the packages you have installed over the previous 6 months. Many a poor soul has made the mistake thinking that aptitude knew what it was doing."

This seems the biggest problem and probably causes the most trouble for users.

Thanks for your input.
Richard.
The_Seeker - 12.11.2006, 22:22 Uhr
Titel:
Zitat:

version 4.3.1
Shows the driver version for fglrx, nvidia stable, and latest nvidia

Just a heads up h2. Your script claims the beta driver to be installed is 9742 when in fact it is 9626.
h2 - 13.11.2006, 00:24 Uhr
Titel:
ah, damn it

it's hard to do this stuff because the actual nvidia installer script changes frequently, and my script is just reading some stuff from it.

thanks for the headsup, when I last installed, a few days ago, it was 9742, which meant the first instance of #VER=...

I guess I'll have to pull out the advanced stuff in a different way

It's actually very hard to duplicate kano's detection stuff because he does a lot of tests, and will install different stuff in different circumstances.

I'm not sure how much work I'll put into this to be honest because kano will be changing his logic to handle new cases all the time on nvidia install.

even the stable driver version will change if you are using older hardware, so unless I actually duplicated all of the initial testing of the script, I doubt I can give a truly accurate output that you can depend on over time.
stryder - 13.11.2006, 00:40 Uhr
Titel:
Simpler to ask kano to include driver version in his script. Should be just an additional line or two, no?.
h2 - 13.11.2006, 00:59 Uhr
Titel:
version 4.3.3: I modified the advanced/beta number detection, so it should match what is actually installed now.

I also added a note to let users know that this is just a guess, and their results may vary, since there is no way I can keep up with kano's nvidia work, but this will be fairly accurate for most users now I believe, as long as you don't have legacy hardware.

The stable driver should be correct in almost all cases, except for legacy nvidia cards, and the advanced driver option will be right as long as the nvidia installer script tests for beta stuff and the advanced install options, -c.

Again, kano does a lot of work to get the right driver isntalled on your system, about 130 lines of install-nvdia-debian.sh, so all my script will give is a most likely guess, which will be right for most nvidia users, but not all. If your nvidia card is supported currently, it will probably be right for you.

Zitat:
Simpler to ask kano to include driver version in his script. Should be just an additional line or two, no?

stryder: what was wanted here was to see the driver version that would be installed, before running the actual installer script. Since the kano script doesn't know what driver it will actually install until about line 130, it can't output that until it runs.

However, I can make good guesses that will work for most nvidia users based on the defaults that are active if nothing overrides them, so that's what I'm doing now.

I actually liked this feature request, because it is good to know before you run the script what it will install, that lets you move to a new terminal and edit the install-nvidia-debian.sh script to make it install what you want, for example, for my box, 9742 is working fine, 9626 broke some flash, 9625 worked fine, and so on. So for this beta stuff it's good to know what the script will install before it installs it.

The stable driver shouldn't vary much however, it will in most cases be what my script says, assuming reasonably new nvidia cards/chips. And the advanced driver number should also be right for most users. In other words, if 9626 installed, then 9742, assuming that was current advanced install option, would also install.
h2 - 13.11.2006, 04:33 Uhr
Titel:
version 4.4.0
I decided it was silly to try to second guess kano's installer scripts, so now I added a hack that will force them to show what they would actually install before they run fully. This seems to work fairly well, but it's a fairly significant change in the graphics installer section.

Warning: because this relies on certain readings of kano's scripts, if they change in those sections, this may break, so let me know if you suddenly get a failure on the fgrlx install, that one is not as reliable.

Now there is no longer an option to try to force the install, since if the install would theoretically fail anyway no matter what if you ran the kano graphics driver install scripts.

So now there is no guessing, the nvidia standard driver is the driver the script will install on your system, the advanced nvidia driver is the driver the nvidia install script will install with the -c option, and the fgrlx version is the actual version the fglrx script will install.

It also tests for no support, so if your card is too old or is unsuppored, the script will read that error as well, and not offer the option at all to install any graphics drivers.

This was trickier than I thought it would be, but through the wonders of sed it proved to be fairly easy to do.

I anticipate some problems with this with people with two or more different cards running, but for most users this should show exactly what would happen if you ran the real install-nvidia-debian.sh or install-fglrx-debian.sh scripts, since the du-fixes now gets the driver values as calculated by those scripts.

I would appreciate feedback on especially ati stuff, since my only ati is not a supported card, so I just get the default message now that there is no supported ati driver.
stryder - 13.11.2006, 04:37 Uhr
Titel:
Wow... sounds complicated. Smilie I wouldn't even think of editing kano's script! Seems to me for a person who is confident enough to do that, he can just do that if he finds that the version installed should be changed, and re-run the script.

Heh... just read what you did above. It's pretty fantastic what you can do... Smilie
h2 - 13.11.2006, 07:21 Uhr
Titel:
4.4.5: one more option on nvidia install, if the actual most advanced version is greater than the current advanced version given by the -c option, you can try using the very latest beta nvidia driver too. On my system that works fine, 9742, so I thought I'd save myself a step in these cases.

For example, today, the script will install 8776 for stable, and uses 9626 for -c option install, but the actual latest nvidia driver is 9742. So if the last two are different, you'll have the choice of which to install.
bushit - 13.11.2006, 18:26 Uhr
Titel:
Sorry h2, I didn't know that this is actually so difficult. However, the feature is very useful, I'm very happy with it.
Thank you for your work!
slam - 13.11.2006, 19:00 Uhr
Titel:
Let's give h2 at this point a hearty hug!
You have helped a lot of people sailing around the cliffs of upgrading - thank you very much for that.
Stay tuned with Kano's script development, you are are on your way to real mastership. Smilie
Greetings,
Chris
The_Seeker - 13.11.2006, 19:23 Uhr
Titel:
Zitat:

Let's give h2 at this point a hearty hug!

Will a firm handshake suffice? Auf den Arm nehmen

I've had cause to do a couple of fresh installs over the past few weeks and h2's script has allowed me to keep my system up to date with no hassles whatsoever (we're talking over 500 MB upgrades each time).

Thanks again h2 for your wonderful script, I (plus countless others no doubt) really appreciate the work you put in.
piper - 13.11.2006, 19:33 Uhr
Titel:
Todays Fresh Install

704 upgraded
17 new installs
3 removed
1 not upgraded

I do this once a week on one system to test h2's excellent script and to make sure it runs right so others benefit from it (someone beats me to it though finding errors). I also do it without the script. At the moment, I only do this with the latest rc because I have no time (soon to change)

h2

Thank You

h2 - 13.11.2006, 21:01 Uhr
Titel:
Version 4.5.0: created one more module, of the individual miscellaneous tweaks functions. That's about all I can practically cut out of the main script at this point, although in the future I'll be able to remove all older fixes as well I think and make them into a module or two, which should help keep the script manageable long term. But for now it feels like it's back under control.

Glad the script is useful to people, it's fun doing it still, which is a good sign.

bushit, that feature was something that had been bugging me for a while, since I had to go into install-nvidia-debian.sh each time to hack it manually before running the nvidia installer, as you note, it's a useful thing to have ready access too.

I expect some changes in that graphics logic in the future, but for now it should work ok for most people most of the time, which was my actual goal in making the initial du-fixes script.
h2 - 14.11.2006, 04:51 Uhr
Titel:
Version 4.5.9: a small change, moved debian orphan cleanup to a more logical place, the clean up module, so that's where you'll find it now, with all the other cleanup options.
jiro - 14.11.2006, 04:58 Uhr
Titel:
there appears to be a bug in the latest version (4.5.9). at the point you are asked to type "9" to "continue on to graphics driver installation", the script proceeds to install the driver without offering you a second menu dialog as before (to install stable or beta nvidia version). this crashed my system, because my system for whatever reason is not compatible with kano's install-nvidia-debian.sh script. i then had to fire up the text-based lynx browser to go download the driver version available at nvidia.com.

my system is back up, but i think the script needs to be fixed so it doesn't automatically proceed to install the driver without user confirmation
h2 - 14.11.2006, 05:36 Uhr
Titel:
I can't duplicate that, I just tried it. There's no way I know of to make the script skip reading your response on the graphics driver install, but if there is a way, I'd like to learn it.

Again, the script does not automatically proceed without user confirmation, so if anyone else can reproduce this that would be helpful.

the only thing that has really changed is how the graphics installer gives you options, and what information it uses to list those options. The install itself isn't automatic, and as far as I know, couldn't be.

See if you can reproduce it, I doubt you can. Start the script with the -f option to force it to update itself, just in case your download got corrupted or something.
jiro - 14.11.2006, 06:23 Uhr
Titel:
well, maybe the bug has to do with my system using a driver from nvidia.com rather than the alternate version installed by kano's script. this doesn't really make much sense, but it's the only thing i can think of. the graphics install option worked correctly in previous versions of your script (except that, again, my system crashes after installing the debian version of the nvidia driver due to some incompatibility issue)

[minor correction: the script version that i had used was 4.5.8, not 4.5.9]
h2 - 14.11.2006, 08:59 Uhr
Titel:
Have you recreated the bug? I made some changes, fixed some issues etc in the last few hours, but this should not have any real affect, or create that result.

See if you can get that result again, my guess is you can't, but it would be good to know for sure.

The script does no testing for nvdia version installed so that would not make any difference.

However, it does query kano's scripts, but should not start any install process, but I can check the kano scripts to make sure.

kano's scripts do not use non nvidia drivers, they are downloaded from either us.download.nvidia.com or de.download.nvidia.com directly.

they do other things, but they use nvidia drivers directly.

I went in and checked, and there is simply no place I can see in kano's script that could have forced an install either, since what I did was echo the value of the version then exit the nvidia installer script, that's it.

So I have to guess that something unusual happened somewhere in the process, assuming of course this is a standard kanotix install, but even if it weren't it shouldn't really matter. Also assuming you are using bash, by the way, not some other shell.

the other possibility is that you had the bad luck to download a version for the few minutes it was up with a bug, that's why I doubt you'll see this bug again, try it and see, but I really don't see how it could happen.
stryder - 15.11.2006, 00:20 Uhr
Titel:
I remember kano saying somewhere that you either use his script or the debian module assistant (but not both!) as they install the driver differently. Perhaps too nvidia's installer?
h2 - 15.11.2006, 01:26 Uhr
Titel:
nothing should trigger any install process, so version of installer should not matter. However, I'm filing this for now under 'one time, non duplicatable events', since there is only this one report.

But, far more important, an issue I'm fairly certain everyone has been quietly complaining to themselves about, and probably also discussing in endless hidden forum threads, but not wanting to bring up: 4.5.12 now sorts /etc/du-fixes.conf in alphabetical order every time a config item runs.
jiro - 15.11.2006, 03:39 Uhr
Titel:
h2 hat folgendes geschrieben::
Have you recreated the bug? I made some changes, fixed some issues etc in the last few hours, but this should not have any real affect, or create that result.

Yes - I just ran version 4.5.12 and got the same result. There are two different issues here.

The second issue may be "unique" to my computer - that installing the debian version of nvidia's 3d driver crashes my system (i read somewhere that nvidia puts out two versions - a proprietary, binary version and a version more compatible with debian's open source philosophy - and i am not referring to the generic "nv" driver, but the 3D driver installed by kano's script and yours, too, i think) Maybe I once did something that messed up my directory structure or something like that, I don't know, but I can install the v9629 driver directly from nvidia.com but not using kano's script (or yours).

The first issue seems to indicate a bug in your script rather than anything strange in my computer - and this is that, once entering "8" at the dialog menu to "continue on to graphics installation" the script proceeds immediately to attempt installation instead of offering, as it once did, choices for installing the stable or beta version of the driver. Edit: to be precise, first it attempts installation, then it crashes my graphics system (as seen by clicking [Ctrl]+[Alt]+[F7], then it offers me a choice of graphics driver options, and then - if I try to install again - it again fails to install the driver] [/b]
h2 - 15.11.2006, 03:59 Uhr
Titel:
You'll have to give some details in this case:

Which kanotix version are you using?
32 bit or 64 bit?
Are you using some other shell than bash?

The fact that your system also fails on kano's installer scripts is suggestive.

My script only runs kano's installer's scripts, that's all. It does not install anything.

So whatever is happening is due to something very specific in your system. You can read the stuff yourself and see that theoretically this can't happen, so the interesting question is just what is it in your specific setup that is making it happen.

On the bright side, it is always nice to be able to reproduce a bug.

I've reread kano's installer script, and unless you have some extremely unusual configuration, there's simply no place for this to happen. I'd have to double check on 64 bit to make sure that nothing unusual happens there either, but it's the same script in either case.

There is only one place I can see this happening, by the way, it's right at the beginning of my graphics script, where sed writes some stuff to the kano script, then a few lines later runs the installer script to get some information from it. If sed failed to write, the kano script would then theoretically start running. The old version just grepped the script, now it runs it to see what will actually be installed.

This is the only place I can see where it could bypass the actual question. Needless to say, if you're running a heavily hacked system, sorry, no support.

If you for some weird reason don't have sed, or don't have a version that supports all the bash sed syntax, then it could theoretically not work. But that would mean you've significantly modified your system, and shouldn't be trying to run any scripts like this at all.

However, please post ALL your relevant system information, otherwise I can't figure out anything more.

I'm also assuming you're not doing anything particularly silly like trying to run this script in x or anything like that.

You can test the main logic here yourself by, as root, running this:
sed -i "s%PKG=0%echo \$VER;exit;PKG=0%g" /usr/local/bin/install-nvidia-debian.sh

then open up install-nvidia-debian.sh and go to line 137 and make sure that you see this: echo $VER;exit;PKG=0
If you don't, your sed is broken, or you have done some other hacks, that I'm not going to worry about.

By the way, I'd guess that once you figure this out, you'll also know why kano's nvidia installer script doesn't work on your system.
jiro - 15.11.2006, 04:20 Uhr
Titel:
Here's my system:
Zitat:
Host/Kernel/OS "Dell" running Linux 2.6.18-slh-up-2 i686 [ KANOTIX 2006 Easter ]
CPU Info Intel Pentium 4 1024 KB cache flags( nx ) clocked at [ 3192.065 MHz ]
Videocard nVidia NV41.1 [GeForce 6800] X.Org 7.1.1 [ 1024x768 @50hz ]
Network cards Atheros AR5005G 802.11abg NIC
Broadcom NetXtreme BCM5751 Gigabit Ethernet PCI Express
Processes 100 | Uptime 52min | Memory 564.906/1009.14MB | HDD ATA ST3160023AS Size 160GB (14%used) | GLX Renderer GeForce 6800/PCI/SSE2 | GLX Version 2.1.0 NVIDIA 96.29 | Client Shell wrapper | Infobash v2.50


I'm running a fully updated 32-bit system originally installed from 2006 Easter edition. sed is installed. I didn't intentionally hack my system, but apparently something happened along the way. Maybe it's a permissions problem with wherever sed is trying to write to. Who knows? Life is too short to lose sleep over this.

Anyway, since I seem to be the only one experiencing this problem, it is probably not worth fixing. My system runs just fine. Your script is great and very useful for everything (except, for me, for installing the graphics driver). I will just continue downloading the latest driver manually whenever i need it. No big deal.

Thanks for all your work on this script.
h2 - 15.11.2006, 04:29 Uhr
Titel:
I think it must be a permissions problem, but if you do the above test, and sed did not write, unfortunately some other fixes also have not gotten done, but most don't depend on sed too much, just for tweaks etc.

My guess is that if you try the above sed line, and it doesn't write to /usr/local/bin/install-nvidia-debian.sh, you have also discovered why kano's nvidia installer script didn't work.

Try it, might be useful information for you long term.

If you do the test and the line did not get modified, you have your answer, sed is not working correctly, somehow or other. Check your permissions, maybe somewhere root does not have write permissions in a directory where it should, it's hard to say.

ls -l /usr/local
should show something like
drwxrwsr-x 2 root staff 864 Nov 13 21:31 bin
and
ls -l /usr/local/bin
should show
-rwxr-xr-x 1 root root 17547 Nov 13 21:31 install-nvidia-debian.sh

[except for the dates, of course]
jiro - 15.11.2006, 04:34 Uhr
Titel:
h2 hat folgendes geschrieben::
There is only one place I can see this happening, by the way, it's right at the beginning of my graphics script, where sed writes some stuff to the kano script, then a few lines later runs the installer script to get some information from it. If sed failed to write, the kano script would then theoretically start running.


It seems that I have TWO versions of install-nvidia-debian.sh - one in /usr/local/bin and another in /sbin. The first is up-to-date, the second is from 5/21/06.

Would this be the problem? Sehr glücklich
h2 - 15.11.2006, 04:44 Uhr
Titel:
jiro, yes, absolutely, that would be the problem.

However, it's also a reminder to me to use full paths, like /usr/local/bin, or explicitly local, like ./ just to avoid any possible error, such as something this obscure.

It's worth tracking this stuff down I think, what has been happening all along is that your system looks
/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin:/usr/games
for the full path, and since you had an old nvidia script in /sbin, the first item listed in $PATH, it runs that first, and exits

So what's been happening all along is that when you've typed in install-nvidia-debian.sh, you've been running your old script, which of course will fail since it's totally out of date.

And if you look in the /usr/local/bin version, you'll see it there, nicely upto date.

Lol... to me it's worth tracking down hard to explain oddities, it usually pays off.

However, you were right in one thing, usually I have used a full path for my commands, but on this particular function, I got lazy and just did the command for the graphics installers with no path at all, since the script is already in /usr/local/bin, but of course, when a command runs, it looks through the $PATH variable first to decide where the command runs from.

So my guess is,delete the old one on /sbin, and the script will work again, and kano's nvidia installer, which is by the way really nice now, will also work fine, at least it will if you install a new kernel.

I'll change the script execution stuff to use the local path just to be on the safe side, and I will consider this a very subtle bug, which would only affect someone who put install-nvidia-debian.sh in some other location that gets tested before /usr/local/bin. Thanks for persisting in this and not giving up, by the way.
h2 - 15.11.2006, 04:51 Uhr
Titel:
4.5.13: fixes the legendary jiro bug, by making sure that all graphics scripts run with ./, to make sure they are running the correct version, in /usr/local/bin

Note to users: if you think something is a bug, it often is, no matter how subtle or odd or unusual or unlikely its occurance is or might be.
jiro - 15.11.2006, 04:59 Uhr
Titel:
i just deleted the old install-nvidia-debian.sh script in /sbin, ran your script and can now...

*** CONFIRM THAT ALL IS WELL ***

lots of fun tracking this down - thanks for your patience and your help - and for naming the bug after me!!! Winken
h2 - 15.11.2006, 05:06 Uhr
Titel:
glad it got figured out, I think it's usually worth figuring out stuff that doesn't work, since there is usually a reason. I think your nvidia installs should go well from now on, but since apparently you're not supposed to mix installers, maybe wait for the next new kernel install to test that. My guess is you will have no more driver install problems either now.

However, I'm very glad that you realized that you had TWO version installed in different locations, I can safely say I would never have thought of that possibility, and would have continued hunting down increasingly arcane and obscure possibilities, when it was all along very simple.
jiro - 15.11.2006, 05:20 Uhr
Titel:
i already used your script (v4.5.12) to install the stable nvidia driver (v8776) successfully. so everything is OK.

btw: this whole story is an example for how someone can screw up their system by doing stuff as "root" without really knowing what they're doing. clearly it was me, not any evil elves, who installed kano's script to the wrong directory.
h2 - 15.11.2006, 05:31 Uhr
Titel:
Great, and good to hear the nvidia install now works as expected as well. But personally, I'd blame it on the evil elves, or possibly some gremlins playing practical jokes on you. After all, are you SURE it wasn't them?
jiro - 15.11.2006, 05:35 Uhr
Titel:
Lachen Lachen Lachen
chris_b - 16.11.2006, 19:52 Uhr
Titel: Small wrinkle and a question
I'm an infrequent dist-upgrader. I've du'd 2 of my 3 systems in the last couple of days, using h2's great script and a 700Meg download. The first went fine Sehr glücklich as is usually the case. The second has a small glitch, though the system works. I think I see what's happened, but can't see how to repair entirely.

During the du, an updated wvdial was installed. I don't use this (and used the script option to remove it later), so I answered its config questions with blank ip addresses (this might seem a strange detail to dwell upon, but bear with me). The du finished fine - no need for a -f and h2's recommended rerunning showed no packages had been left out. Then the later part where the script does the Kanotix graphics fix gave a string of errors "temporary failure resolving ..." for both kanotix.com and ftp.uk.debian.org, but it then said the graphics fix was completed.

The next section could not get an internet connection, and letting it restart the interface didn't get a connection either. I carried on with the off-line tidying that could be done and exited the script using one of the options. I could ping my firewall, so it looked like dns wasn't working. A bit of poking around showed that the /etc/resolv.conf link had been changed, and pointed to /etc/ppp/resolv.conf which was a new, empty, file. A check on system no 3 which runs original Easter showed the link pointing to /etc/dhcpc/resolv.conf which had the plausible line "nameserver 192.168.0.1" in it. So I changed the link /etc/resolv.conf to point to the dhcpc version and the internet returned Auf den Arm nehmen . I suspect my null wvdial config during the du was the culprit, though I don't see why (and I did the same on system 1 which is fine).

Thinking that the incomplete graphics fix might stop things on the first reboot, I tried to get h2's script to do the fix again, but it looked like it has stored away the idea that graphics fix really was done ok and skipped the section. So I crosssed my fingers (I had done a full system backup before the du) and rebooted. Grub complains that it can't find hd(0,0) boot/message and gives its default screen, from which I can boot ok, and the system apprears to work at the kde level.

So there might be some more belt and braces that could be done in the script, and perhaps another way to test the graphics fix really worked.

My question is how to get the graphics fix to run, which I guess will reinstate the splash screen? I'm more concerned there might be other stuff left un-done apart from the splash screen.

Chris
h2 - 16.11.2006, 20:15 Uhr
Titel: RE: Small wrinkle and a question
If in doubt, just remove this file: /etc/du-fixes.conf

and run the script again. That will force all the fixes to run again. Or you can just edit /etc/du-fixes.conf

and remove these items, if present:
kano-penguin-theme
kanotix-graphics-1
kanotix-graphics-2
save it, and run du-fixes-h2.sh again.

The script does remember, but if you change your connection, or if the connection drops, it will consider the procedure done and not run it again.

Since this was more or less user error, and wouldn't happen unless you did what you did, I won't worry too much about it, although it would be nice I guess to double check that fixes actually run, but that's not particularly easy to do.

What happened was that you told your system to use a non-existent connection type, and it dutifully did what you told it to do.

Of all the fixes in that script however, the graphics update is by far the nastiest in my opinion, although it does usually work fine if your connection does not drop.

<added>I may test for apt-get failures I think, since connection drops will cause issues from time to time, not just when the wrong option is selected.
h2 - 16.11.2006, 20:18 Uhr
Titel: RE: Small wrinkle and a question
Version 4.5.14: added 3 new information items in System Information section:

1. Last time apt-get update was run
2. Last time system was upgraded, or a package installed
3. Last time the du-fixes script was run
chris_b - 16.11.2006, 20:48 Uhr
Titel: RE: Small wrinkle and a question
Thanks h2

Edited the .conf file and removed kano-penguin-theme and kanotix-graphics-2 which I found there. Reran script and all looks fine now. I appreciate that checking if the fixes ran could be fun.

In my defence as user I was not expecting wvdial to go and take over like that - I've never used a modem and had set up my network card through the Kanotix menu and assumed (assume = makes an ass of u and me) that wvdial would be rendered dormant by a null config.

As a final thought, how about testing for access to the kanotix site by name as well as testing for connection to the (local) network?

Chris
h2 - 16.11.2006, 21:09 Uhr
Titel: RE: Small wrinkle and a question
I agree, sometimes the way debian words this stuff is just not intuitive, and the answers are not particularly obvious. wvdial is definitely in that category, as is mdadm raid, by the way. Considering that most users would not be using either, the defaults on those, in other words, hitting enter, should be no, don't configure. But that's life in debian world. If you accept default on mdadm raid, you will also be setting up raid support for all your non existent raid arrays.

However, your problem does remind me that having an exit if connection drops would not be a bad idea. Plus reconnection, which wouldn't have helped in your case since the connection didn't exist.

glad to see that rerunning it fixed the graphics, there are some things I can't really test, since once something is in, it's in, and I can't redo it easily, so it's good to see that what should happen does happen.
h2 - 16.11.2006, 21:29 Uhr
Titel: RE: Small wrinkle and a question
version 4.5.15: one more information item, last use of script to do a dist-upgrade.

These 4 new informatiion items should help users, like me, who tend to not remember stuff like this.
jiro - 23.11.2006, 01:20 Uhr
Titel: kernel upgrade problem
i'm having trouble upgrading the kernel using the script. the initial upgrade goes o.k., but i can't install madwifi after rebooting. i get an error message to the effect that the source file is not available.

i read thru your script and then had a look at the kernel source directory "/usr/src/kernel-downloads/2.6.18.3-slh-up-1". turns out that this directory is missing madwifi-modules-2.6.18.3-slh-up-1 file. since this directory was created by your script each time you run a kernel update, something has gone wrong.

how can i fix this?
slh - 23.11.2006, 01:40 Uhr
Titel: RE: kernel upgrade problem
If you have a wired connection available for upgrading, boot the new kernel and:
Code:
apt-get update
m-a a-i madwifi
if you only have a wireless connection for upgrading, please boot an old/ working kernel and:
Code:
apt-get update
m-a --kvers-list 2.6.18.3-slh-up-1 --kernel-dir /usr/src/linux-headers-2.6.18.3-slh-up-1 a-i
jiro - 23.11.2006, 01:59 Uhr
Titel: RE: kernel upgrade problem
thanks, i tried your [second] suggestion, but got the following error:
Code:
/tmp/pkg/modules is not a directory!
slh - 23.11.2006, 02:16 Uhr
Titel: RE: kernel upgrade problem
I corrected the howto immediately after posting it, you were just a bit too quick Winken

--
creating the missing directory would help as well, but the new proposal is a bit better to understand.
jiro - 23.11.2006, 04:21 Uhr
Titel:
slh,

thanks for the fix. i am up and running the latest kernel again. your fix seems to install (or at least TRY to install) all possible modules - but generated a lot of error messages when i ran it. is there a way to only make the madwifi module? also, why has h2's kernel update work fine without the fix until v2.6.18-slh-up-1, but broke after that? will i need to continue using this fix?
devil - 23.11.2006, 07:26 Uhr
Titel:
jiro,
the madwifi module had to be taken from the kernel.zip due to not being completely free. so, for the time being, you will have to build the module.

greetz
devil
jiro - 23.11.2006, 07:53 Uhr
Titel:
devil,

thanks for the explanation. is there a way to build just the module i need (i.e. madwifi)? the fix slh posted was a bit rough: a lot of error messages, a lot of text flying by that i could not understand, and a lot of time. it works, but it is not a real confidence-builder.

jiro
slh - 23.11.2006, 08:43 Uhr
Titel:
It just builds the madwifi module, nothing else but module-assistant might be a bit confusing in its text graphic mode therefore the "--text-mode" parameter might be a bit more obvious. For testing I use a slight variant of yesterday's command, because I don't want to have the madwifi module itself installed on my system):
Code:
$ mkdir /tmp/pkg
$ time m-a --kvers-list 2.6.19-rc6-git4-slh64-smp-1 --kernel-dir /usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1 --userdir /tmp/pkg/ --text-mode build madwifi
Extracting the package tarball, /usr/src/madwifi.tar.bz2, please wait...
dh_testdir
dh_testroot
dh_clean
/usr/bin/make -C /tmp/pkg/usr_src/modules/madwifi clean \
        KERNELPATH=/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1 KERNELRELEASE=2.6.19-rc6-git4-slh64-smp-1 KERNELCONF=/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1/.config ATH_RATE=ath_rate/sample
make[1]: Entering directory `/tmp/pkg/usr_src/modules/madwifi'
for i in ./ath ./ath_hal ath_rate/sample ./net80211; do \
                /usr/bin/make -C $i clean; \
        done
make[2]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath'
rm -f *~ *.o *.ko *.mod.c .*.cmd
rm -f .depend .version .*.o.flags .*.o.d
rm -rf .tmp_versions
make[2]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath'
make[2]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath_hal'
rm -f *~ *.o *.ko *.mod.c uudecode .*.cmd
rm -f .depend .version .*.o.flags .*.o.d
rm -rf .tmp_versions
make[2]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath_hal'
make[2]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath_rate/sample'
rm -f *~ *.o *.ko *.mod.c
rm -f .depend .version .*.o.flags .*.o.d .*.o.cmd .*.ko.cmd
rm -rf .tmp_versions
make[2]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath_rate/sample'
make[2]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/net80211'
rm -f *~ *.o *.ko *.mod.c
rm -f .depend .version .*.o.flags .*.o.d .*.o.cmd .*.ko.cmd
rm -rf .tmp_versions
make[2]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/net80211'
/usr/bin/make -C ./tools  clean
make[2]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/tools'
rm -f athstats 80211stats athkey athchans athctrl athdebug 80211debug wlanconfig core a.out
make[2]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/tools'
rm -rf .tmp_versions
rm -f *.symvers svnversion.h
make[1]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi'
/usr/bin/make  -f debian/rules kdist_clean kdist_config binary-modules
make[1]: Entering directory `/tmp/pkg/usr_src/modules/madwifi'
dh_testdir
dh_testroot
dh_clean
/usr/bin/make -C /tmp/pkg/usr_src/modules/madwifi clean \
        KERNELPATH=/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1 KERNELRELEASE=2.6.19-rc6-git4-slh64-smp-1 KERNELCONF=/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1/.config ATH_RATE=ath_rate/sample
make[2]: Entering directory `/tmp/pkg/usr_src/modules/madwifi'
for i in ./ath ./ath_hal ath_rate/sample ./net80211; do \
                /usr/bin/make -C $i clean; \
        done
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath'
rm -f *~ *.o *.ko *.mod.c .*.cmd
rm -f .depend .version .*.o.flags .*.o.d
rm -rf .tmp_versions
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath'
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath_hal'
rm -f *~ *.o *.ko *.mod.c uudecode .*.cmd
rm -f .depend .version .*.o.flags .*.o.d
rm -rf .tmp_versions
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath_hal'
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath_rate/sample'
rm -f *~ *.o *.ko *.mod.c
rm -f .depend .version .*.o.flags .*.o.d .*.o.cmd .*.ko.cmd
rm -rf .tmp_versions
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath_rate/sample'
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/net80211'
rm -f *~ *.o *.ko *.mod.c
rm -f .depend .version .*.o.flags .*.o.d .*.o.cmd .*.ko.cmd
rm -rf .tmp_versions
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/net80211'
/usr/bin/make -C ./tools  clean
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/tools'
rm -f athstats 80211stats athkey athchans athctrl athdebug 80211debug wlanconfig core a.out
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/tools'
rm -rf .tmp_versions
rm -f *.symvers svnversion.h
make[2]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi'
for templ in ; do \
    cp $templ `echo $templ | sed -e 's/_KVERS_/2.6.19-rc6-git4-slh64-smp-1/g'` ; \
  done
for templ in `ls debian/*.modules.in` ; do \
    test -e ${templ%.modules.in}.backup || cp ${templ%.modules.in} ${templ%.modules.in}.backup 2>/dev/null || true; \
    sed -e 's/##KVERS##/2.6.19-rc6-git4-slh64-smp-1/g ;s/#KVERS#/2.6.19-rc6-git4-slh64-smp-1/g ; s/_KVERS_/2.6.19-rc6-git4-slh64-smp-1/g ; s/##KDREV##/1/g ; s/#KDREV#/1/g ; s/_KDREV_/1/g  ' < $templ > ${templ%.modules.in}; \
  done
dh_testdir
dh_testroot
dh_clean -k
# Build modules
/usr/bin/make -C /tmp/pkg/usr_src/modules/madwifi modules \
        KERNELPATH=/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1 KERNELRELEASE=2.6.19-rc6-git4-slh64-smp-1 KERNELCONF=/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1/.config ATH_RATE=ath_rate/sample
make[2]: Entering directory `/tmp/pkg/usr_src/modules/madwifi'
Checking requirements... ok.
Checking kernel configuration... ok.
/usr/bin/make -C /usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1 SUBDIRS=/tmp/pkg/usr_src/modules/madwifi modules
make[3]: Entering directory `/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1'
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/ath/if_ath.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/ath/if_ath_pci.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/ath/ath_pci.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/ath_hal/ah_os.o
  HOSTCC  /tmp/pkg/usr_src/modules/madwifi/ath_hal/uudecode
  UUDECODE /tmp/pkg/usr_src/modules/madwifi/ath_hal/x86_64-elf.hal.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/ath_hal/ath_hal.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/ath_rate/sample/sample.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/ath_rate/sample/ath_rate_sample.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/if_media.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_beacon.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_crypto.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_crypto_none.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_input.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_node.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_output.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_power.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_proto.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_scan.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_wireless.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_linux.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_monitor.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_acl.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_crypto_ccmp.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_scan_ap.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_scan_sta.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_crypto_tkip.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_crypto_wep.o
  CC [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/ieee80211_xauth.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_wep.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_tkip.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_ccmp.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_acl.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_xauth.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_scan_sta.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_scan_ap.o
  Building modules, stage 2.
  MODPOST 11 modules
  CC      /tmp/pkg/usr_src/modules/madwifi/ath/ath_pci.mod.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/ath/ath_pci.ko
  CC      /tmp/pkg/usr_src/modules/madwifi/ath_hal/ath_hal.mod.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/ath_hal/ath_hal.ko
  CC      /tmp/pkg/usr_src/modules/madwifi/ath_rate/sample/ath_rate_sample.mod.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/ath_rate/sample/ath_rate_sample.ko
  CC      /tmp/pkg/usr_src/modules/madwifi/net80211/wlan.mod.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan.ko
  CC      /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_acl.mod.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_acl.ko
  CC      /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_ccmp.mod.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_ccmp.ko
  CC      /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_scan_ap.mod.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_scan_ap.ko
  CC      /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_scan_sta.mod.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_scan_sta.ko
  CC      /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_tkip.mod.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_tkip.ko
  CC      /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_wep.mod.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_wep.ko
  CC      /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_xauth.mod.o
  LD [M]  /tmp/pkg/usr_src/modules/madwifi/net80211/wlan_xauth.ko
make[3]: Leaving directory `/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1'
make[2]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi'
# Install modules
/usr/bin/make -C /tmp/pkg/usr_src/modules/madwifi install-modules \
        KERNELPATH=/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1 KERNELRELEASE=2.6.19-rc6-git4-slh64-smp-1 KERNELCONF=/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1/.config ATH_RATE=ath_rate/sample \
        DESTDIR=/tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1 KMODPATH=/lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net
make[2]: Entering directory `/tmp/pkg/usr_src/modules/madwifi'
sh scripts/find-madwifi-modules.sh 2.6.19-rc6-git4-slh64-smp-1 /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1
for i in ./ath ./ath_hal ath_rate/sample ./net80211; do \
                /usr/bin/make -C $i install || exit 1; \
        done
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath'
test -d /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net || mkdir -p /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net
cp ath_pci.ko /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath'
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath_hal'
test -d /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net || mkdir -p /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net
cp ath_hal.ko /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath_hal'
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath_rate/sample'
test -d /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net || mkdir -p /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net
cp ath_rate_sample.ko /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath_rate/sample'
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/net80211'
test -d /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net || mkdir -p /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net
for i in wlan.o wlan_wep.o wlan_tkip.o wlan_ccmp.o wlan_acl.o wlan_xauth.o wlan_scan_sta.o wlan_scan_ap.o; do \
                f=`basename $i .o`; \
                cp $f.ko /tmp/pkg/usr_src/modules/madwifi/debian/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1//lib/modules/2.6.19-rc6-git4-slh64-smp-1/kernel/drivers/net; \
        done
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/net80211'
make[2]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi'
dh_installdocs
dh_installchangelogs
dh_compress
dh_fixperms
dh_installmodules
dh_installdeb
dh_gencontrol -- -v1:0.9.2+r1809.20061115-1+1
dh_md5sums
dh_builddeb --destdir=/tmp/pkg
dpkg-deb: Baue Paket »madwifi-modules-2.6.19-rc6-git4-slh64-smp-1« in »/tmp/pkg/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1_0.9.2+r1809.20061115-1+1_amd64.deb«.
make[1]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi'
/usr/bin/make  -f debian/rules kdist_clean
make[1]: Entering directory `/tmp/pkg/usr_src/modules/madwifi'
dh_testdir
dh_testroot
dh_clean
/usr/bin/make -C /tmp/pkg/usr_src/modules/madwifi clean \
        KERNELPATH=/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1 KERNELRELEASE=2.6.19-rc6-git4-slh64-smp-1 KERNELCONF=/usr/src/linux-headers-2.6.19-rc6-git4-slh64-smp-1/.config ATH_RATE=ath_rate/sample
make[2]: Entering directory `/tmp/pkg/usr_src/modules/madwifi'
for i in ./ath ./ath_hal ath_rate/sample ./net80211; do \
                /usr/bin/make -C $i clean; \
        done
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath'
rm -f *~ *.o *.ko *.mod.c .*.cmd
rm -f .depend .version .*.o.flags .*.o.d
rm -rf .tmp_versions
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath'
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath_hal'
rm -f *~ *.o *.ko *.mod.c uudecode .*.cmd
rm -f .depend .version .*.o.flags .*.o.d
rm -rf .tmp_versions
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath_hal'
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/ath_rate/sample'
rm -f *~ *.o *.ko *.mod.c
rm -f .depend .version .*.o.flags .*.o.d .*.o.cmd .*.ko.cmd
rm -rf .tmp_versions
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/ath_rate/sample'
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/net80211'
rm -f *~ *.o *.ko *.mod.c
rm -f .depend .version .*.o.flags .*.o.d .*.o.cmd .*.ko.cmd
rm -rf .tmp_versions
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/net80211'
/usr/bin/make -C ./tools  clean
make[3]: Entering directory `/tmp/pkg/usr_src/modules/madwifi/tools'
rm -f athstats 80211stats athkey athchans athctrl athdebug 80211debug wlanconfig core a.out
make[3]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi/tools'
rm -rf .tmp_versions
rm -f *.symvers svnversion.h
make[2]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi'
make[1]: Leaving directory `/tmp/pkg/usr_src/modules/madwifi'

real    0m23.335s
user    0m20.001s
sys     0m2.984s

$ ls -gG /tmp/pkg/madwifi*
-rw-r--r-- 1 270012 2006-11-23 09:33 /tmp/pkg/madwifi-modules-2.6.19-rc6-git4-slh64-smp-1_0.9.2+r1809.20061115-1+1_amd64.deb
This takes a little longer if you have to use "apt-get update" first (to update the package lists, so you can get the newest madwifi module source package) and to download the source package itself. For ordinary uses the following is still the preferred way of compiling the package (automatically fetches the current madwifi source (if needed), builds and installes it:
Code:
$ su
# m-a --kvers-list 2.6.18.3-slh-up-1 --kernel-dir /usr/src/linux-headers-2.6.18.3-slh-up-1 a-i

With, or without --text-mode depends on your personal taste, this builds and installs the madwifi module (or almost every other module) for the specified kernel.
h2 - 27.11.2006, 06:01 Uhr
Titel:
New feature in Miscellaneous Tweaks - dump gtk file handler.

this now also edits all user profile prefs.js files to add the following tweaks:
hubi - 28.11.2006, 01:55 Uhr
Titel:
h2,

just used your script for the first time. It is massive, absolutely brilliant. And I am so happy to have a useful filehandler in iceweasel now Sehr glücklich

Thank you so much,
hubi
LinuxGeek - 28.11.2006, 08:06 Uhr
Titel:
h2,
All I can is say is 'sweet'. This is the first time that I've used the script, and so far, so good. Thanks Smilie
h2 - 09.12.2006, 00:08 Uhr
Titel:
Version 4.8.0: Finally, had to do it: Removed support for Kanotix users, now Kanotix users must accept the option to switch to sidux the script will give them before the dist-upgrade section, after the warning section, if they want to use du-fixes-h2.sh.

It can still be used for kernel installs for the time being of course, so there is no problem with that.

All Kanotix users will be given the option to switch to sidux sources and sidux every time they try to do a du with du-fixes, that question will now no longer only be asked one time, it will be every 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, and I don't have the time or energy to try to keep up with both.

So if you want sid based distro, go with the option to switch, and if you want to go with kanotix still as it moves to more stable waters, I can't support you any longer.

The script should be able to handle the switchover with not too many glitches for users who want to do that, so either way you should be fine, whether you decide to stay with Kanotix or if you go to the new sid based sidux.

I'd like to thank Kano for all his efforts over the last years, he proved running true debian sid based desktops could be done, but of course, he also learned that this was not going to become a commercially viable concept.

I wish kano and all other kanotixer's good luck in their future endeavors, and thank you all for everything I learned along the way.

Sorry I couldn't maintain support for longer, I was really hoping to, but I'm not going to have any time to deal with issues next week so I had to do this now, the likelihood is getting too high that at any minute things may start breaking as Kanotix and sidux begin to separate structurally.

Happy and smooth sailing no matter what path you select, Harald, h2
Richard - 09.12.2006, 00:59 Uhr
Titel:
Thanks for hanging in as long as you could.

I'm keeping a partition with an installation of kanotix-2006-01rc4 with a "gentle" upgrade tracking testing/etch. It will just get more stable for the next few months and soon will become stable.

I will keep using sidux for my everyday use but really like having that stable installation to fall back on. I like using Sidux because it is new, exiting and fun. But I must have a solid way to keep working when I break my main box. And I know it will break from time to time. That is the nature of Sid. It is a part of the allure and what we learn from. Just not conducive to getting one's work done.

Sidux-to-be is working great, especially without Splashy. I saw the new Sidux login one time but my latest round of installing and du-fixing lost it. Looking forward to first sidux release. Actually it's rather boring at the moment since everything is working. :} Jeez. Never satisfied.

regards,
Richard.
h2 - 09.12.2006, 08:24 Uhr
Titel:
I would like to add one note, the script can still be used in some of its functionality by kanotix users.

You can still use it to install kernels with no problem for the time being, although how long that will be safe for I cannot tell you.

If you start the script with this option -wd you can skip all the dist-upgrade components, which is what I am no longer supporting for kanotix, and go to miscellaneous tweaks with all its stuff, and graphics install.

However, I cannot guarantee how long any of this will work for unfortunately.
dacorsa - 10.01.2007, 20:13 Uhr
Titel:
hi i have always this error:

root@KanotixBox:~# apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
Need to get 0B of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]?
Setting up linux-image-2.6.18.6-slh-up-1 (1) ...
Running depmod.
Finding valid ramdisk creators.
Using /usr/sbin/mkinitrd.yaird to build the ramdisk.
yaird error: Could not read output for /sbin/modprobe -v -n --show-depends --set-version 2.6.18.6-slh-up-1 usbmouse (fatal)
/usr/sbin/mkinitrd.yaird failed to create initrd image.
Failed to create initrd image.
dpkg: error processing linux-image-2.6.18.6-slh-up-1 (--configure):
subprocess post-installation script returned error exit status 9
dpkg: dependency problems prevent configuration of linux-custom-patches-2.6.18.6-slh-up-1:
linux-custom-patches-2.6.18.6-slh-up-1 depends on linux-image-2.6.18.6-slh-up-1; however:
Package linux-image-2.6.18.6-slh-up-1 is not configured yet.
dpkg: error processing linux-custom-patches-2.6.18.6-slh-up-1 (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
linux-image-2.6.18.6-slh-up-1
linux-custom-patches-2.6.18.6-slh-up-1
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@KanotixBox:~#



how can i resolve this????

thanks
op4latino - 11.01.2007, 04:16 Uhr
Titel:
Problem: Kernel 2.6.18.6 complains about using yaird and wants to use initramfs

Question: Did you try to install the kernel with h2's script? If so, It sees you answered "Yes" to the configuration of the kernel's image when you were supposed to respond "No". Run the script again and read the whole screen when it ask you to say "yes" or "no"

IF you didn't use h2's script, then install initramfs-toos with apt-get, then do apt-get install -f. If you still have problems, in /etc/kernel-img.conf remove the yaird line
dacorsa - 11.01.2007, 11:21 Uhr
Titel:
i used h2's script and answered YES to the question......now i have try to reinstall, but not ask me again that question.....how can i resolve??

can i this for resolve??:

"IF you didn't use h2's script, then install initramfs-toos with apt-get, then do apt-get install -f. If you still have problems, in /etc/kernel-img.conf remove the yaird line"

but i used h2's script...
op4latino - 11.01.2007, 15:29 Uhr
Titel:
hmm, the script should have asked you again the question when you tried to install 2.6.18.6. Please do apt-get install -f and see if you still have problems.

If you still have problems, do the "IF you didn't use h2's script" part of my last post and come back to report your status
Alle Zeiten sind GMT + 1 Stunde
PNphpBB2 © 2003-2007