| Autor |
Nachricht |
|
|
Titel:
 Verfasst am: 14.11.2006, 06:23 Uhr
|
|
Anmeldung: 27. Jun 2005
Beiträge: 258
|
|
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] |
|
|
| |
|
|
|
 |
|
|
|
Titel:
Verfasst am: 14.11.2006, 08:59 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
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. |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 00:20 Uhr
|
|
Anmeldung: 26. Jun 2005
Beiträge: 389
|
|
| 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? |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 01:26 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
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. |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 03:39 Uhr
|
|
Anmeldung: 27. Jun 2005
Beiträge: 258
|
|
|
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] |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 03:59 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
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. |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 04:20 Uhr
|
|
Anmeldung: 27. Jun 2005
Beiträge: 258
|
|
| 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. |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 04:29 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
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] |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
Zuletzt bearbeitet von h2 am 15.11.2006, 04:38 Uhr, insgesamt ein Mal bearbeitet
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 04:34 Uhr
|
|
Anmeldung: 27. Jun 2005
Beiträge: 258
|
|
|
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?  |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 04:44 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
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. |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
Zuletzt bearbeitet von h2 am 15.11.2006, 04:54 Uhr, insgesamt ein Mal bearbeitet
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 04:51 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
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. |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 04:59 Uhr
|
|
Anmeldung: 27. Jun 2005
Beiträge: 258
|
|
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!!!  |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 05:06 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
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. |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 05:20 Uhr
|
|
Anmeldung: 27. Jun 2005
Beiträge: 258
|
|
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. |
|
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 05:31 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
| 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? |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
|
| |
|
|
|
|
|
|
|
Titel:
Verfasst am: 15.11.2006, 05:35 Uhr
|
|
Anmeldung: 27. Jun 2005
Beiträge: 258
|
|
|
|
|
|
|
|
|
Titel: Small wrinkle and a question
Verfasst am: 16.11.2006, 19:52 Uhr
|
|
Anmeldung: 24. Feb 2006
Beiträge: 11
|
|
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 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  . 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 |
|
|
| |
|
|
|
|
|
|
|
Titel: RE: Small wrinkle and a question
Verfasst am: 16.11.2006, 20:15 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
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. |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
Zuletzt bearbeitet von h2 am 16.11.2006, 20:56 Uhr, insgesamt ein Mal bearbeitet
|
| |
|
|
|
|
|
|
|
Titel: RE: Small wrinkle and a question
Verfasst am: 16.11.2006, 20:18 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
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 |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
|
| |
|
|
|
|
|
|
|
Titel: RE: Small wrinkle and a question
Verfasst am: 16.11.2006, 20:48 Uhr
|
|
Anmeldung: 24. Feb 2006
Beiträge: 11
|
|
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 |
|
|
| |
|
|
|
|
|
|
|
Titel: RE: Small wrinkle and a question
Verfasst am: 16.11.2006, 21:09 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
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. |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
|
| |
|
|
|
|
|
|
|
Titel: RE: Small wrinkle and a question
Verfasst am: 16.11.2006, 21:29 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
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. |
_________________
Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
|
| |
|
|
|
|
|
|
|
Titel: kernel upgrade problem
Verfasst am: 23.11.2006, 01:20 Uhr
|
|
Anmeldung: 27. Jun 2005
Beiträge: 258
|
|
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? |
|
|
| |
|
|
|
|
|
|
|
Titel: RE: kernel upgrade problem
Verfasst am: 23.11.2006, 01:40 Uhr
|
|
Anmeldung: 16. Aug 2004
Beiträge: 1905
|
|
| 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
|
|
|
| |
|
|
|
|
|
|
|
Titel: RE: kernel upgrade problem
Verfasst am: 23.11.2006, 01:59 Uhr
|
|
Anmeldung: 27. Jun 2005
Beiträge: 258
|
|
| thanks, i tried your [second] suggestion, but got the following error:
Code:
/tmp/pkg/modules is not a directory!
|
|
|
| |
|
|
|
|
|
|
|
