Re: [Cooker] cooker - state of play
THANK YOU! np, i'm not doing the hardest part :) you have been the first who actually *did* something to resolve the issue instead of just going on with bla-bla-bla. - do you have /lib/dev-state/log file? yes $ ls /lib/dev-state/log -l srw-rw-rwT1 root root0 jui 4 22:13 /lib/dev-state/log= Good, this was the immediate culprit. Remove it and you should be able to boot normally. It was expected to be removed by devfsd update but probably something did not work as expected. Anyway the whole story is so fragile that this is the minor problem. I will have to think about final solution. I do not like losing boot messages before syslogd start so reverting my last minilogd patch is not an option (at least, the last one to consider). This is *very* system dependent, in your case I presume the USB was the reason you experienced it (by adding more syslog users). please tell me if removing /lib/dev-state/log fixed it; else I need stack again, do not bother with ksymoops. Please, Cc me I do not receive cooker. -andrey
Re: [Cooker] cooker - state of play
Adam Williamson [EMAIL PROTECTED] writes: Oh yes, very sorry, I should've mentioned this too, Danny - older kernels also do the hang on boot for me if I don't change minilogd, the only option which boots correctly is failsafe. So I'm not convinced it's a kernel bug. it's not because external events make triggering a bug in another package more easier or difficult that the bug is in the event source package. devfs implementation was crappy with scores of arguments in every function in case someone want to add X, Y, or Z feature some day (a lot of cleanups has been done in 2.5.x). the odds're high that there're bugs there and andrey explanation does not look stupid to me.
Re: [Cooker] cooker - state of play
- do you have /lib/dev-state/log file? yes $ ls /lib/dev-state/log -l srw-rw-rwT1 root root0 jui 4 22:13 /lib/dev-state/log= Good, this was the immediate culprit. Remove it and you should be able to boot normally. It was expected to be removed by devfsd update but probably something did not work as expected. Anyway the whole story is so fragile that this is the minor problem. Thanks :-) It boots normally now. I will have to think about final solution. I do not like losing boot messages before syslogd start so reverting my last minilogd patch is not an option (at least, the last one to consider). Good luck :) Olivier
Re: [Cooker] cooker - state of play
Andrey Borzenkov [EMAIL PROTECTED] writes: Good, this was the immediate culprit. Remove it and you should be able to boot normally. It was expected to be removed by devfsd update but probably something did not work as expected. because i put in %%postun instead of %post. and it was only run in the this is not an update but a definitive package remval me sucks :-( Anyway the whole story is so fragile that this is the minor problem. yes, it only fix the symptoms and hide the real problem (me trying to pressure planel so that he pressure juan so that your patch is merged) ...
Re: [Cooker] cooker - state of play
Thierry Vignaud [EMAIL PROTECTED] writes: Good, this was the immediate culprit. Remove it and you should be able to boot normally. It was expected to be removed by devfsd update but probably something did not work as expected. because i put in %%postun instead of %post. and it was only run in the this is not an update but a definitive package remval but wait, there's still something crappy somewhere in devfsd since it should just have ignored /lib/dev-state/log entry ... :-(
Re: [Cooker] cooker - state of play
On Wed, 9 Jul 2003, Thierry Vignaud wrote: Anyway the whole story is so fragile that this is the minor problem. yes, it only fix the symptoms and hide the real problem (me trying to pressure planel so that he pressure juan so that your patch is merged) ... Well, Andreys patch doesn't fix this specific problem. But while your pressuring, add supermount-ng and ACL on XFS to the list;) d.
Re: [Cooker] cooker - state of play
Andrey Borzenkov [EMAIL PROTECTED] writes: one possibility is to leave DELETE uncommented but then it will result in error message every time after /lib/dev-state/log has been removed the first time the new postin script should be enough now (in order to fix the symptom that is) if only the kernel team could release faster ... :-(
Re: [Cooker] cooker - state of play
[EMAIL PROTECTED] writes: Anyway the whole story is so fragile that this is the minor problem. yes, it only fix the symptoms and hide the real problem (me trying to pressure planel so that he pressure juan so that your patch is merged) ... Well, Andreys patch doesn't fix this specific problem. But while your pressuring, add supermount-ng and ACL on XFS to the list;) supermount-ng is on the list. don't know for acl. nicolas ?
Re: [Cooker] cooker - state of play
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thierry Vignaud wrote: [EMAIL PROTECTED] writes: supermount-ng is on the list. don't know for acl. nicolas ? http://www.linux-mandrake.com/ is not accessible at present, but I am sure ACLs was listed as a feature for 9.1, and is quite an important feature for people running samba (only SuSE has ACL support in their current release). ACLs on XFS are running fine on our new server running Danny's -22mdk (which has Thomas' xfs+acl patch) on 9.1. Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/DC1TrJK6UGDSBKcRAtwTAKCFMb92jCa3yAXqmM/nRIYo43Dl7ACeOlpX V4gswLTlYylF9BAWk37jNFM= =0mIc -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] cooker - state of play
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Backlund wrote: From: Buchan Milne [EMAIL PROTECTED] AFAIK a new kernel update for 9.1 is on the way... (the one Juan is working on right now...) But there hasn't been one kernel update for 8.2 or 9.0 yet, which are still officially supported according to the policies on mandrakesecure.net. And 9.0 had ACLs on ext2/ext3 also ... If I understand it correctly, the ACL for XFS will be in it, and also a fixed ipsec/freeswan, and then some Great! More and better info on this will be available when the kernel is released... Well, it might be an idea if the info were made available *before* being released ... it might calm some nerves. BTW: the new kernel is installed now. Works so far (I didn't test all yet). However, the PCMCIA problem remains: 00:09.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller Subsystem: Mitac: Unknown device 8640 Flags: bus master, medium devsel, latency 192, IRQ 17 Memory at 10001000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=05, sec-latency=64 I/O window 0: -0003 I/O window 1: -0003 16-bit legacy interface ports at 0001 cardctl status no pcmcia driver in /proc/devices Well, I give up for now and hope, that this kernel is stable. As the winmodem should work, I don't need PCMCIA for now. This user is running -22mdk on 9.1. With the rc1 kernel from cooker, he had pcmcia support, but not with 0.13mdk or 0.18mdk. But -22mdk is the only kernel usable by him at present, due to the fixes it has. I can ask him for more detail if necessary. Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/DD+HrJK6UGDSBKcRAq10AJ9VQGCN3X1YINnyQj9khmvabxSQiACfV+E5 lu7ZdHq8zjkChSNDmR13vsc= =u+IR -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] cooker - state of play
From: Buchan Milne [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thierry Vignaud wrote: [EMAIL PROTECTED] writes: supermount-ng is on the list. don't know for acl. nicolas ? http://www.linux-mandrake.com/ is not accessible at present, but I am sure ACLs was listed as a feature for 9.1, and is quite an important feature for people running samba (only SuSE has ACL support in their current release). ACLs on XFS are running fine on our new server running Danny's -22mdk (which has Thomas' xfs+acl patch) on 9.1. Regards, Buchan AFAIK a new kernel update for 9.1 is on the way... (the one Juan is working on right now...) If I understand it correctly, the ACL for XFS will be in it, and also a fixed ipsec/freeswan, and then some More and better info on this will be available when the kernel is released... Thomas
Re: [Cooker] cooker - state of play
Oh yes, very sorry, I should've mentioned this too, Danny - older kernels also do the hang on boot for me if I don't change minilogd, the only option which boots correctly is failsafe. So I'm not convinced it's a kernel bug. Well, this thread stopped to be amusing ... folks, there are 2 (two) patches for minilogd in this intscripts. If all of you are so sure it is minilogd - why won't you revert these one-by-one to see which patch is responsible? It is no rocket sience, it compiles in 5 seconds; and finally there are just two compiles needed (with either patch) because we obviously have other two cases already covered. Or, better yet, would somebody finally produce a stack trace of hanging system and send it to me ... -andrey
Re: [Cooker] cooker - state of play
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Williamson wrote: On Mon, 2003-07-07 at 21:58, Olivier Blin wrote: Oh yes, very sorry, I should've mentioned this too, Danny - older kernels also do the hang on boot for me if I don't change minilogd, the only option which boots correctly is failsafe. So I'm not convinced it's a kernel bug. BTW, I had someone phone me who is seeing this problem on stock 9.1, not all the time, but quite often, except when booting failsafe. Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Co4hrJK6UGDSBKcRAjJdAJ9LM0XE0f3H91NqnfNGEPmcq/enowCdFwgU 0UuvGBEBx/LUxITdW21wPLo= =aW9t -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] cooker - state of play
On Tue, 8 Jul 2003, Buchan Milne wrote: BTW, I had someone phone me who is seeing this problem on stock 9.1, not all the time, but quite often, except when booting failsafe. well, did 0.22mdk fix it? d.
Re: [Cooker] cooker - state of play
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: On Tue, 8 Jul 2003, Buchan Milne wrote: BTW, I had someone phone me who is seeing this problem on stock 9.1, not all the time, but quite often, except when booting failsafe. well, did 0.22mdk fix it? Haven't managed to get them to try -22mdk, will report when I have. But until now the fact that it affects 9.1 also hasn't been made abundantly clear (which is why people are trying to revert to kernel or devfsd from 9.1). Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/CqIkrJK6UGDSBKcRArgiAKCySRIX57YabDsySNkgCn+FWEtopQCdEWct xXaa6xdH4T0+c2mG25rA4CI= =KrcB -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] cooker - state of play
But until now the fact that it affects 9.1 also hasn't been made abundantly clear (which is why people are trying to revert to kernel or devfsd from 9.1). this problem is two and half year old. This problem has been reported long before 9.1 including cooker as well. I have been having it interminnently long before 9.1. Pavel (who did all the debugging) had this problem under RedHat - so without any relation to either mdk kernel or minilogd. The problem has been reported on a.o.l.m more than once for 9.1 as well. If archives of devfs mailing list were online you would see lo-o-ong thread about it there with exactly the same stacks posted by Juan. reverting to old minilogd simply puts it off until next kernel or initscripts change. Besides it will lose early boot messages again. I won't promise to eat my hat if it turns out to be completely unrelated - but I will be suprised very very much. -andrey actually I probably can promise it because I have no hat :))
Re: [Cooker] cooker - state of play
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrey Borzenkov wrote: But until now the fact that it affects 9.1 also hasn't been made abundantly clear (which is why people are trying to revert to kernel or devfsd from 9.1). this problem is two and half year old. This problem has been reported long before 9.1 including cooker as well. I have been having it interminnently long before 9.1. Pavel (who did all the debugging) had this problem under RedHat - so without any relation to either mdk kernel or minilogd. The problem has been reported on a.o.l.m more than once for 9.1 as well. If archives of devfs mailing list were online you would see lo-o-ong thread about it there with exactly the same stacks posted by Juan. But how many people on cooker (besides you, Juan and Danny) know this? If everyone on cooker knew this, why would they be reverting packages? I just wanted to make sure people on cooker know it's not cooker-specific (which *has* *not* been said much until now). reverting to old minilogd simply puts it off until next kernel or initscripts change. Besides it will lose early boot messages again. Agree, which is why people need to know that reverting is not the solution (which has been used already by a number of people). I won't promise to eat my hat if it turns out to be completely unrelated - but I will be suprised very very much. And if Juan is working on another kernel update for 9.1, shouldn't the patch be applied there too, or must we keep telling people not to use Mandrakesoft kernels but Danny's update instead? Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x202 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Cre4rJK6UGDSBKcRAq+uAJ43tCG56EbCVAlsLtXQul2O7AWi6wCeKMxe 8p1xKn/y0lKAPFEo5XeF65k= =Wz2A -END PGP SIGNATURE- ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] cooker - state of play
And if Juan is working on another kernel update for 9.1, shouldn't the patch be applied there too, or must we keep telling people not to use Mandrakesoft kernels but Danny's update instead? First we have to be sure it is this problem :) Andrew Morton pointed one more race condition in devfs. It is not related to my patch - it exists with or without - but it is good occasion to fix both at the same time (they are related to the same problem) I hope to convince somebody on lkml to include it into 2.4. Pavel does this as well. The problem is, Richard is not online for a long time now and he is still official maintainer at least for 2.4 ... -andrey
Re: [Cooker] cooker - state of play
If it really does not work, I am guilty of yelling at everbody (although other people have reported success with this patch). No, you're not guilty, this patch had to be tried. Anyway, can you produce a stack trace? alt-sysrq-T at the hang? please run it through ksymoops if needed. I have joined the strace to this mail. Actually, even if the kernel didn't print the strace on screen (with a log level of 0), it was written in /var/log/kernel/warnings :-) Olivier strace_depmod.gz Description: Binary data strace_through_ksymoops.gz Description: Binary data
Re: [Cooker] cooker - state of play
I have joined the strace to this mail. THANK YOU! [Buchan, you will laugh, but it was different problem] OK, could you please check a couple of things. - do you have /lib/dev-state/log file? - what gives 'grep log /etc/devfsd.conf' - what happens if you boot without devfs (with devfs unmounted)? - what happens if you boot without devfs with root mounted read-write initially (I am afraid, if you use ext3, reiser or similar you will have to edit mkinitrd and recreate initrd to do it - currently mkinitrd has builtin 'mount --ro'). In short it appears that minilogd tries to exit but blocks and all other programs that try to connect to it block as well. The above is mostly to make sure why it tries to exit. I will have to think why it blocks (I know how to reproduce it now easily without rebooting). thank you for your help -andrey
Re: [Cooker] cooker - state of play
THANK YOU! np, i'm not doing the hardest part :) - do you have /lib/dev-state/log file? yes $ ls /lib/dev-state/log -l srw-rw-rwT1 root root0 jui 4 22:13 /lib/dev-state/log= - what gives 'grep log /etc/devfsd.conf' $ grep log /etc/devfsd.conf # Restoring /dev/log on startup would trigger the minilogd/initlog deadlock # (minilogd falsely assuming syslogd has been started). REGISTER^log$ IGNORE CREATE ^log$ IGNORE CHANGE ^log$ IGNORE DELETE ^log$ IGNORE - what happens if you boot without devfs (with devfs unmounted)? - what happens if you boot without devfs with root mounted read-write initially (I am afraid, if you use ext3, reiser or similar you will have to edit mkinitrd and recreate initrd to do it - currently mkinitrd has builtin 'mount --ro'). let me some more minutes to do it :) thanks for your help
[OT] Re: [Cooker] cooker - state of play
Hello Olivier Blin, I know its not on topic but it seemms that your email address on laposte.net is blacklisted by spamcop... I was playing with some antispam tools and obviously it intrigued me what was supposedly spam. So if you find people not responding or members on the cooker and other lists donot see your responses and use an antispam service. Thanks for having pointed this out :) SpamCop probably assumes that laposte.net is an open relay, which is wrong because you need to log in your pop3 account before being able to use the SMTP server ... Anyway, laposte.net sux these days, they have lost about 2 days of mail since Saturday, so I read the ML with http://marc.theaimsgroup.com/?l=mandrake-cooker . I use a new account, can you tell me if my new mail address/SMTP server is blocked by SpamCop ? Thanks
Re: [Cooker] cooker - state of play
- what happens if you boot without devfs (with devfs unmounted)? It boots fine when i start the kernel with devfs=unmount. /var/log/syslog:Jul 8 23:44:35 blino rc.sysinit: Unmounting initrd: succeeded - what happens if you boot without devfs with root mounted read-write initially (I am afraid, if you use ext3, reiser or similar you will have to edit mkinitrd and recreate initrd to do it - currently mkinitrd has builtin 'mount --ro'). Since I use ext3, i've changed --ro to --rw in /sbin/mkinitrd and I've launched /usr/share/loader/make-initrd, I hope it was the right thing to do :-) I cannot see any difference with the previous case. /var/log/syslog:Jul 8 23:50:26 blino rc.sysinit: Unmounting initrd: succeeded thanks for your help Olivier
Re: [Cooker] cooker - state of play
This is (most likely) a devfs bug, it was fixed by a patch by Andrey. If you have this hang often, please test attached patch (for some people it never occurs, for others only rarely) Hi Thanks for the help. I applied this patch to the kernel source (it was a pain to download the package with my 56k ...) and rebuilded the package, but depmod still hangs at boot. Are you sure this patch can be applied to the current kernel source ? It was written for Mandrake 9.1 kernel ... Thanks Olivier
Re: [Cooker] cooker - state of play
On Mon, 7 Jul 2003, Olivier Blin wrote: This is (most likely) a devfs bug, it was fixed by a patch by Andrey. If you have this hang often, please test attached patch (for some people it never occurs, for others only rarely) Hi Thanks for the help. I applied this patch to the kernel source (it was a pain to download the package with my 56k ...) and rebuilded the package, but depmod still hangs at boot. Are you sure this patch can be applied to the current kernel source ? It was written for Mandrake 9.1 kernel ... thanks for trying! Well, if you did it correctly it should work. And it is only a one-liner in code that didn't change since last release AFAIK. If it really does not work, I am guilty of yelling at everbody (although other people have reported success with this patch). Anyway, can you produce a stack trace? alt-sysrq-T at the hang? please run it through ksymoops if needed. d.
Re: [Cooker] cooker - state of play
To be absolutely sure you applied it correctly, and it is working, can you type as root: while true ; do ls /dev/foo rm -f /dev/foo done better ctrl-c it after after a few 100 times. Than, check in ps ax if you have all these processes hanging in the D state. If so: patch is not applied correctly, or you are not running patched kernel. If it does not hang: your hang at boot is due to a different problem. It doesn't hang. I've noticed that my old kernel, kernel-2.4.21-0.13mdk, has the same problem on boot, it also hang in depmod :-/ Thanks for your help.
Re: [Cooker] cooker - state of play
On Mon, 7 Jul 2003, Olivier Blin wrote: This is (most likely) a devfs bug, it was fixed by a patch by Andrey. If you have this hang often, please test attached patch (for some people it never occurs, for others only rarely) Hi Thanks for the help. I applied this patch to the kernel source (it was a pain to download the package with my 56k ...) and rebuilded the package, but depmod still hangs at boot. Are you sure this patch can be applied to the current kernel source ? It was written for Mandrake 9.1 kernel ... To be absolutely sure you applied it correctly, and it is working, can you type as root: while true ; do ls /dev/foo rm -f /dev/foo done better ctrl-c it after after a few 100 times. Than, check in ps ax if you have all these processes hanging in the D state. If so: patch is not applied correctly, or you are not running patched kernel. If it does not hang: your hang at boot is due to a different problem. d.
Re: [Cooker] cooker - state of play
On Mon, 7 Jul 2003, Olivier Blin wrote: It doesn't hang. good. hmm..I wonder what are the chances of 2 bugs having a so similar appearence. I still would like a stack trace on the hang. I've noticed that my old kernel, kernel-2.4.21-0.13mdk, has the same problem on boot, it also hang in depmod :-/ Yes, but this kernel should also show lots of processes in D state when you try that small test script. d.
Re: [Cooker] cooker - state of play
On Mon, 2003-07-07 at 21:58, Olivier Blin wrote: To be absolutely sure you applied it correctly, and it is working, can you type as root: while true ; do ls /dev/foo rm -f /dev/foo done better ctrl-c it after after a few 100 times. Than, check in ps ax if you have all these processes hanging in the D state. If so: patch is not applied correctly, or you are not running patched kernel. If it does not hang: your hang at boot is due to a different problem. It doesn't hang. I've noticed that my old kernel, kernel-2.4.21-0.13mdk, has the same problem on boot, it also hang in depmod :-/ Oh yes, very sorry, I should've mentioned this too, Danny - older kernels also do the hang on boot for me if I don't change minilogd, the only option which boots correctly is failsafe. So I'm not convinced it's a kernel bug. -- adamw
Re: [Cooker] cooker - state of play
Anyway, can you produce a stack trace? alt-sysrq-T at the hang? please run it through ksymoops if needed. No, i can't produce a stack trace. The kernel prints he will show the trace, but nothing occurs :(
Re: [Cooker] cooker - state of play
On Mon, 07 Jul 2003 23:26:03 +0200 Olivier Blin [EMAIL PROTECTED] wrote: Anyway, can you produce a stack trace? alt-sysrq-T at the hang? please run it through ksymoops if needed. No, i can't produce a stack trace. The kernel prints he will show the trace, but nothing occurs :( Try alt-sysrq-8 then alt-sysrq-T, that should set the log level to 8 (highest IIRC), which should have a more detailed printout pgp0.pgp Description: PGP signature
Re: [Cooker] cooker - state of play
Viestissä Maanantai 7. Heinäkuuta 2003 22:31, [EMAIL PROTECTED] kirjoitti: [...] To be absolutely sure you applied it correctly, and it is working, can you type as root: while true ; do ls /dev/foo rm -f /dev/foo done better ctrl-c it after after a few 100 times. Than, check in ps ax if you have all these processes hanging in the D state. If so: patch is not applied correctly, or you are not running patched kernel. I tested this... under 13mdk I let the loop run ~4000 times, wich left ~4000 processes in D state... with your 22mdk I let the loop run ~25000 times, but not a single process got left hanging... there were no trace what so ever of those processes in ps ax ... now this was fun ;-) Now to an other topic: now I'm going to set bonnie++ to benchmark my hdd until tomorrow... I have had some reports that some harddrives drops out of UDMA after a while in use on nForce2 systems ... (both normal and heavy use apparently ...) Regards Thomas
Re: [Cooker] cooker - state of play
Le Dimanche 6 Juillet 2003 02:12, Stphane Soucy a crit : I try to put set -x at the start of my /etc/rc.sysinit script and it stop to freeze!!! not for me...
Re: [Cooker] cooker - state of play
Le Samedi 5 Juillet 2003 23:52, Adam Williamson a écrit : But you maybe *do* have the bug. the nvidia module should load if you have this line in /etc/modules.conf: alias /dev/nvidia* nvidia but for many of us, it doesn't. We have to load it manually or put it in /etc/modules. what about you? I have the line alias /dev/nvidia* nvidia in the modules.conf, but the driver isn't loaded! so no the bug isn't here...
Re: [Cooker] cooker - state of play
Le Samedi 5 Juillet 2003 14:23, [EMAIL PROTECTED] a écrit : On 5 Jul 2003, Adam Williamson wrote: just now, the system's starting freezing at Finding module dependencies: - it sits there and does nothing. I can workaround this with Alt-SysRq-E, which terminates whatever is freezing the system, and boot continues, but then the X Font Server fails to initialise properly (complains about some executable not existing). This is (most likely) a devfs bug, it was fixed by a patch by Andrey. If you have this hang often, please test attached patch (for some people it never occurs, for others only rarely) not sure. I've upgraded my whole box (and kernel and devfsd), and I got the same problem as described before. But downgrading to 2.4.21-0.18mm-mdk , my default, kernel didin't solve these problems. So the bug of depmod -A getting sucked isn't related to 2.4.21 kernel, for me. X wouldn't start, but only doing a service dm restart has started X, without the need to load at hand the NVidia module. I have another problem who raises at the same time: vmware can't start anymore, it's end with a sigfpe... Emmanuel
Re: [Cooker] cooker - state of play
On Sunday 06 July 2003 12:38, Blindauer Emmanuel wrote: Le Dimanche 6 Juillet 2003 02:12, Stphane Soucy a crit : I try to put set -x at the start of my /etc/rc.sysinit script and it stop to freeze!!! not for me... same here. it stopped freezing the first time after I installed grub, but, now, it freeze too. depmod has nothing to do with it. In fact, with true instead of depmod, in rc.sysinit, it freeze. and, with the whole line commented ( nb 510 and 512 , INITLOG_ARGS= action Finding module dependencies: depmod -A ) , it pass, and freeze after ( on activating swap ) So, this has something to do with initlog, i think. For information, the last commande of the strace of depmod was brk(0) = 0x80c8000 since brk should return 0 on success, this is no good :/ -- Michal Scherer
Re: [Cooker] cooker - state of play
On Sunday 06 July 2003 15:38, Michael Scherer wrote: On Sunday 06 July 2003 12:38, Blindauer Emmanuel wrote: Le Dimanche 6 Juillet 2003 02:12, Stphane Soucy a crit : I try to put set -x at the start of my /etc/rc.sysinit script and it stop to freeze!!! not for me... same here. it stopped freezing the first time after I installed grub, but, now, it freeze too. depmod has nothing to do with it. In fact, with true instead of depmod, in rc.sysinit, it freeze. and, with the whole line commented ( nb 510 and 512 , INITLOG_ARGS= action Finding module dependencies: depmod -A ) , it pass, and freeze after ( on activating swap ) So, this has something to do with initlog, i think. and the winner is minilogd. thanks to the advice of Abel Cheung on irc, I reverted to the binary of 9.1, and now, everything work. so, if you want to boot, you should take /sbin/minilogd from mdk9.1, and replace the one in -13mdk. -- Michal Scherer
Re: [Cooker] cooker - state of play
On Sun, 6 Jul 2003, Michael Scherer wrote: and the winner is minilogd. Well why do you think Andrey's patch i resent was called devfs.minilogd ? I think the problem is really in the kernel, but nobody wants to try:( d.
Re: [Cooker] cooker - state of play
On Sun, 6 Jul 2003, Blindauer Emmanuel wrote: This is (most likely) a devfs bug, it was fixed by a patch by Andrey. If you have this hang often, please test attached patch (for some people it never occurs, for others only rarely) not sure. I've upgraded my whole box (and kernel and devfsd), and I got the same problem as described before. But downgrading to 2.4.21-0.18mm-mdk , my default, kernel didin't solve these problems. So the bug of depmod -A getting sucked isn't related to 2.4.21 kernel, for me. Well, older kernels have that bug as well, except for an updated kernel I put on the club. And it can be triggered by other apps. If nobody tries the patch, we'll never know. d.
Re: [Cooker] cooker - state of play
On Sun, 2003-07-06 at 16:39, [EMAIL PROTECTED] wrote: On Sun, 6 Jul 2003, Michael Scherer wrote: and the winner is minilogd. Well why do you think Andrey's patch i resent was called devfs.minilogd ? I think the problem is really in the kernel, but nobody wants to try:( probably because it's a bit of a pain to apply the patch and recompile the kernel...is there no easier way of testing? -- adamw
Re: [Cooker] cooker - state of play
On Sun, 2003-07-06 at 01:31, Duncan wrote: That's what I thought I said.. However, I attribute it to something else.. the binary only bit of the nvidia module, as I had to force recompile/reinstall of the nvidia module after compiling and switching to 2.4.21, as the nvidia installer otherwise gave me a warning/error about me using a different compiler to compile the module than I had to compile the kernel, tho it was the same one, and I'd just finished compiling the kernel. The only reasonable explanation for that is that the nvidia binary-only component was compiled with a different compiler, which would be expected since I rather doubt they could be using the latest Cooker gcc, when I believe this release (the latest, but..) was out b4 the latest gcc! Thus, I think the problem is the stupid binary-only core, which of necessity HAS to be compiled with something older than the newest gcc, rather than devfsd or some other such thing. I expect the reason it won't load by default now has to do with the compiler differences, tho it will still load if specifically loaded, as it is when loaded from modules or manually. No, that's not it. It didn't stop working with a kernel version change for me; it was working with a kernel then stopped working with the same kernel when something else changed. It's not the gcc version. -- adamw
Re: [Cooker] cooker - state of play
On 6 Jul 2003, Adam Williamson wrote: probably because it's a bit of a pain to apply the patch and recompile the kernel...is there no easier way of testing? Ah...but I still suspect you are all being lazy. It is not that much work to compile a minimal kernel with this patch. It is a timing issue, every change in rc.sysinit can trigger it. And reverting to an old minilogd is not a real solution. Well..If you all stay being lazy I might build a kernel rpm with the patch. I thought this list was for cookers d. (now you will all kill me if the patch doesn't fix it *grin*) O..perhaps another way to be sure is to produce a stack trace with alt-sysrq-T. But ofcourse that doesn't fix it.
Re: [Cooker] cooker - state of play
On 6 Jul 2003, Adam Williamson wrote: On Sun, 2003-07-06 at 16:39, [EMAIL PROTECTED] wrote: On Sun, 6 Jul 2003, Michael Scherer wrote: and the winner is minilogd. Well why do you think Andrey's patch i resent was called devfs.minilogd ? I think the problem is really in the kernel, but nobody wants to try:( probably because it's a bit of a pain to apply the patch and recompile the kernel...is there no easier way of testing? Ah...but I still suspect you are all being lazy. It is not that much work to compile a minimal kernel with this patch. It is a timing issue, every change in rc.sysinit can trigger it. And reverting to an old minilogd is not a real solution. Well..If you all stay being lazy I might build a kernel rpm with the patch. I thought this list was for cookers d. (now you will all kill me if the patch doesn't fix it *grin*) O..perhaps another way to be sure is to produce a stack trace with alt-sysrq-T. But ofcourse that doesn't fix it.
Re: [Cooker] cooker - state of play
On 6 Jul 2003, Adam Williamson wrote: probably because it's a bit of a pain to apply the patch and recompile the kernel...is there no easier way of testing? I just did think of an easier way to test it: grab a copy of the 22mdk kernel in the clubcontributions for 9.1 (under unsupported on the mirrors). It also contains the patch. For people that have access to klama: I have put an 2.4.21.3 kernel with the patch+acls+supermount in my homedir (dtholen). I have no access to my x86 cooker box now, so that one is not tested yet. d.
Re: [Cooker] cooker - state of play
On Sun, 2003-07-06 at 23:00, [EMAIL PROTECTED] wrote: On 6 Jul 2003, Adam Williamson wrote: probably because it's a bit of a pain to apply the patch and recompile the kernel...is there no easier way of testing? I just did think of an easier way to test it: grab a copy of the 22mdk kernel in the clubcontributions for 9.1 (under unsupported on the mirrors). It also contains the patch. OK, I'll try that in the morning. For people that have access to klama: I have put an 2.4.21.3 kernel with the patch+acls+supermount in my homedir (dtholen). I have no access to my x86 cooker box now, so that one is not tested yet. Any chance you could make that one publicly accessible somewhere? -- adamw
Re: [Cooker] cooker - state of play
On Sun, 2003-07-06 at 20:38, [EMAIL PROTECTED] wrote: On 6 Jul 2003, Adam Williamson wrote: On Sun, 2003-07-06 at 16:39, [EMAIL PROTECTED] wrote: On Sun, 6 Jul 2003, Michael Scherer wrote: and the winner is minilogd. Well why do you think Andrey's patch i resent was called devfs.minilogd ? I think the problem is really in the kernel, but nobody wants to try:( probably because it's a bit of a pain to apply the patch and recompile the kernel...is there no easier way of testing? Ah...but I still suspect you are all being lazy. It is not that much work to compile a minimal kernel with this patch. It is a timing issue, every change in rc.sysinit can trigger it. And reverting to an old minilogd is not a real solution. Well..If you all stay being lazy I might build a kernel rpm with the patch. I thought this list was for cookers We're *lazy* cookers. :) -- adamw
Re: [Cooker] cooker - state of play
probably because it's a bit of a pain to apply the patch and recompile the kernel...is there no easier way of testing? - Speaking as one of the Hairy Knuckle/Kilingon crowd its not that bad if you know what options to set/module/unset you can do the compile run in a few minutes (My Intel celeron 700 did a compile during a midshow commerical break) Side note does the kernel source rpm have the matching .config file included? ie if i install 2.4.21-3mdk.src.rpm does it have the .config used to build 2.4.21-3mdk.i586.rpm?
Re: [Cooker] cooker - state of play
On 5 Jul 2003, Adam Williamson wrote: just now, the system's starting freezing at Finding module dependencies: - it sits there and does nothing. I can workaround this with Alt-SysRq-E, which terminates whatever is freezing the system, and boot continues, but then the X Font Server fails to initialise properly (complains about some executable not existing). This is (most likely) a devfs bug, it was fixed by a patch by Andrey. If you have this hang often, please test attached patch (for some people it never occurs, for others only rarely) d. 2.4.21-0.13-devfs.minilogd.patch.bz2 Description: BZip2 compressed data
Re: [Cooker] cooker - state of play
So to boot up I have to pick my kernel, do Alt-SysRq-E when module dependencies freeze, login to the console, modprobe nvidia and usbmouse, restart the xfs service and restart the dm service. This is not optimal. :) Same problem here, but I also need to modprobe some i2c and video modules to then modprobe bttv :/ Thanks for the SysRq tip :-) Any status on these problems, particularly the devfsd one? I'm running devfsd-1.3.25-30mdk , which seems to be the latest. I note that the changelog for 29mdk reads really package /sbin/devfsd-try-modload, but I don't *have* /sbin/devfsd-try-modload , nor does urpmf find it. You should have a look at devfsd-1.3.25-30mdk changelog :-) - patch 100: run-time kernel 2.5 detection for MODLOAD action (Andrey Borzenkov) (replace source 5 and patch 40) Source5 was the devfsd-try-modload file : http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/devfsd/devfsd.spec.diff?r1=1.100r2=1.101f=h Olivier
Re: [Cooker] cooker - state of play -2421-3
On Saturday July 5 2003 07:23 am, [EMAIL PROTECTED] wrote: On 5 Jul 2003, Adam Williamson wrote: just now, the system's starting freezing at Finding module dependencies: - it sits there and does nothing. I can workaround this with Alt-SysRq-E, which terminates whatever is freezing the system, and boot continues, but then the X Font Server fails to initialise properly (complains about some executable not existing). This is (most likely) a devfs bug, it was fixed by a patch by Andrey. If you have this hang often, please test attached patch (for some people it never occurs, for others only rarely) I'm urpmi --auto-selecting back to cooker after a fresh 9.1 install (urpmi urpmi first ;) 2421-3 hung for me on Finding module deps. Alt-SysRq-E got it unstuck, but after several screens of mesg's flying by it'd get to a login prompt. Any attempt to do anything there would cause a reboot as soon as I pressed Enter after typing my user name. I tried several times. I booted the 1st CD to try a rescue, but any attempt to try and -force a reinstall of 2421-18mm (to possibly fix /boot) errored on 'db3'. I lack the trouble shootin skills to do much more. After the reinstall of 9.1, 2421-3 installed and booted with no problems, tho it was a little (few seconds more'n normal) slow getting by Finding module deps. I've probly got about 45mins to go getting cooker current ... then I'll see if 2421-3 will boot again. OTOH, I now have installin 9.1, adding cooker sources, and gettin cooker current down to a science ;) -- Tom Brinkman Corpus Christi, Texas
Re: [Cooker] cooker - state of play
On Sat, 2003-07-05 at 13:23, [EMAIL PROTECTED] wrote: On 5 Jul 2003, Adam Williamson wrote: just now, the system's starting freezing at Finding module dependencies: - it sits there and does nothing. I can workaround this with Alt-SysRq-E, which terminates whatever is freezing the system, and boot continues, but then the X Font Server fails to initialise properly (complains about some executable not existing). This is (most likely) a devfs bug, it was fixed by a patch by Andrey. If you have this hang often, please test attached patch (for some people it never occurs, for others only rarely) What does the patch apply to? -- adamw
Re: [Cooker] cooker - state of play
just now, the system's starting freezing at Finding module dependencies: - it sits there and does nothing. I can workaround this with Alt-SysRq-E, which terminates whatever is freezing the system, and boot continues, but then the X Font Server fails to initialise properly (complains about some executable not existing). I added -v option to depmod -A in /etc/rc.d/rc.sysinit (gruik gruik), it seems to break on : type 2 /lib/modules/2.4.21-3mdk/kernel/3rdparty/atmelwlan/usbvnet_i xftw_readdir /lib/modules/2.4.21-3mdk/kernel/3rdparty/atmelwlan/usbvnet_i How could I debug this ?
Re: [Cooker] cooker - state of play
On 5 Jul 2003, Adam Williamson wrote: What does the patch apply to? You could have looked at it, it's small... But the answer is: the kernel. d.
Re: [Cooker] cooker - state of play
On Sat, 5 Jul 2003, Olivier Blin wrote: just now, the system's starting freezing at Finding module dependencies: - it sits there and does nothing. I can workaround this with Alt-SysRq-E, which terminates whatever is freezing the system, and boot continues, but then the X Font Server fails to initialise properly (complains about some executable not existing). I added -v option to depmod -A in /etc/rc.d/rc.sysinit (gruik gruik), it seems to break on : type 2 /lib/modules/2.4.21-3mdk/kernel/3rdparty/atmelwlan/usbvnet_i xftw_readdir /lib/modules/2.4.21-3mdk/kernel/3rdparty/atmelwlan/usbvnet_i How could I debug this ? By trying Andreys patch. d.
Re: [Cooker] cooker - state of play
You could have looked at it, it's small... But the answer is: the kernel. --- linux-2.4.21-0.13mdk/fs/devfs/base.c.minilogd 2002-11-29 02:53:15.0 +0300 +++ linux-2.4.21-0.13mdk/fs/devfs/base.c2003-05-06 00:41:35.0 +0400 It's not a patch for the latest kernel source, does it apply to it ? Thanks
Re: [Cooker] cooker - state of play
On Fri 04 Jul 2003 19:52, Adam Williamson posted as excerpted below: still seem to have this devfsd problem that people are experiencing to various degrees. loop, nvidia, usbmouse and probably some others I don't know about are not loaded on boot. So to boot up I have to pick my kernel, do Alt-SysRq-E when module dependencies freeze, login to the console, modprobe nvidia and usbmouse, restart the xfs service and restart the dm service. This is not optimal. :) Sounds like that is a bit of an understatement. At least it boots! g FWIW.. My system is a bit different. I'm running 2.4.21 self-compiled from kernel.org. As such, I have boot-required modules like reiserfs (on all my partitions except for swap, naturally, and legacy vfat) built-in, so don't need or have an initrd to worry about. That said, with devfsd -30mdk here, no serious issues. I don't have usbmouse (still use ps2, since I have the port and it's less complicated than tracking USB for such a critical input device), but I have nvidia supporting two monitors on my AGP GForce2 (svirge on the PCI supporting a third monitor). I originally didn't load it on boot, but at X start (I boot init 3 by default and start X/KDE from my user login with the kde command from BASH). However, I'm assuming due to the binary portion being compiled with a different gcc, that didn't work after I upgraded to kernel 2.4.21. It does, however, work if I load nvidia from /etc/modules at boot, which I am doing now. I have loopback modulized, but haven't used it recently so don't know whether it works or not. Anyway, while several have said it's a devfsd issue, I'm not sure that's entirely the case, as it doesn't seem to be affecting me here, with a standard kernel.org kernel, and no initrd. If it IS specifically a devfsd issue, the kernel and/or initrd apparently triggers it. -- Duncan - List replies preferred. They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. Benjamin Franklin
Re: [Cooker] cooker - state of play
On Sat, 2003-07-05 at 22:38, Duncan wrote: On Fri 04 Jul 2003 19:52, Adam Williamson posted as excerpted below: still seem to have this devfsd problem that people are experiencing to various degrees. loop, nvidia, usbmouse and probably some others I don't know about are not loaded on boot. So to boot up I have to pick my kernel, do Alt-SysRq-E when module dependencies freeze, login to the console, modprobe nvidia and usbmouse, restart the xfs service and restart the dm service. This is not optimal. :) Sounds like that is a bit of an understatement. At least it boots! g FWIW.. My system is a bit different. I'm running 2.4.21 self-compiled from kernel.org. As such, I have boot-required modules like reiserfs (on all my partitions except for swap, naturally, and legacy vfat) built-in, so don't need or have an initrd to worry about. That said, with devfsd -30mdk here, no serious issues. I don't have usbmouse (still use ps2, since I have the port and it's less complicated than tracking USB for such a critical input device), but I have nvidia supporting two monitors on my AGP GForce2 (svirge on the PCI supporting a third monitor). I originally didn't load it on boot, but at X start (I boot init 3 by default and start X/KDE from my user login with the kde command from BASH). However, I'm assuming due to the binary portion being compiled with a different gcc, that didn't work after I upgraded to kernel 2.4.21. It does, however, work if I load nvidia from /etc/modules at boot, which I am doing now. I have loopback modulized, but haven't used it recently so don't know whether it works or not. Anyway, while several have said it's a devfsd issue, I'm not sure that's entirely the case, as it doesn't seem to be affecting me here, with a standard kernel.org kernel, and no initrd. If it IS specifically a devfsd issue, the kernel and/or initrd apparently triggers it. But you maybe *do* have the bug. the nvidia module should load if you have this line in /etc/modules.conf: alias /dev/nvidia* nvidia but for many of us, it doesn't. We have to load it manually or put it in /etc/modules. what about you? -- adamw
Re: [Cooker] cooker - state of play
On Sat, 5 Jul 2003, Olivier Blin wrote: You could have looked at it, it's small... But the answer is: the kernel. --- linux-2.4.21-0.13mdk/fs/devfs/base.c.minilogd 2002-11-29 02:53:15.0 +0300 +++ linux-2.4.21-0.13mdk/fs/devfs/base.c2003-05-06 00:41:35.0 +0400 It's not a patch for the latest kernel source, does it apply to it ? well duhh..you could at least try and then complain if it doesn't. It is made for an older version because the bug is known for a long time. The only thing that is not sure it if the patch works actually correctly (but it has been in my kernel version on club for some time, without complaints). d.
Re: [Cooker] cooker - state of play
I try to put set -x at the start of my /etc/rc.sysinit script and it stop to freeze!!! I don't know why??? Le ven 04/07/2003 22:52, Adam Williamson a crit : Here's the current happy fun bugs I have with Cooker: still seem to have this devfsd problem that people are experiencing to various degrees. loop, nvidia, usbmouse and probably some others I don't know about are not loaded on boot. just now, the system's starting freezing at Finding module dependencies: - it sits there and does nothing. I can workaround this with Alt-SysRq-E, which terminates whatever is freezing the system, and boot continues, but then the X Font Server fails to initialise properly (complains about some executable not existing). So to boot up I have to pick my kernel, do Alt-SysRq-E when module dependencies freeze, login to the console, modprobe nvidia and usbmouse, restart the xfs service and restart the dm service. This is not optimal. :) Any status on these problems, particularly the devfsd one? I'm running devfsd-1.3.25-30mdk , which seems to be the latest. I note that the changelog for 29mdk reads really package /sbin/devfsd-try-modload, but I don't *have* /sbin/devfsd-try-modload , nor does urpmf find it. -- Stphane Soucy [EMAIL PROTECTED]
Re: [Cooker] cooker - state of play
On Sat 05 Jul 2003 14:52, Adam Williamson posted as excerpted below: But you maybe *do* have the bug. the nvidia module should load if you have this line in /etc/modules.conf: alias /dev/nvidia* nvidia but for many of us, it doesn't. We have to load it manually or put it in /etc/modules. what about you? That's what I thought I said.. However, I attribute it to something else.. the binary only bit of the nvidia module, as I had to force recompile/reinstall of the nvidia module after compiling and switching to 2.4.21, as the nvidia installer otherwise gave me a warning/error about me using a different compiler to compile the module than I had to compile the kernel, tho it was the same one, and I'd just finished compiling the kernel. The only reasonable explanation for that is that the nvidia binary-only component was compiled with a different compiler, which would be expected since I rather doubt they could be using the latest Cooker gcc, when I believe this release (the latest, but..) was out b4 the latest gcc! Thus, I think the problem is the stupid binary-only core, which of necessity HAS to be compiled with something older than the newest gcc, rather than devfsd or some other such thing. I expect the reason it won't load by default now has to do with the compiler differences, tho it will still load if specifically loaded, as it is when loaded from modules or manually. I really wish they'd just release the thing so it could be fully compiled with whatever I happen to be using, already! I doubt I will buy another nvidia card due to all this hassle. (I got this one back b4 I switched to Linux. At the time I was planning to switch, so I verified Linux drivers and that the dual head worked with them, but I didn't know enough to realize what complications nvidia proprietary drivers would cause, nor even that they were different from the nv drivers. I just knew to verify they were there and would work with the card I was looking to purchase.) Of course, one does have a hard time arguing with nvidia's price and wide availability.. -- Duncan - List replies preferred. They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. Benjamin Franklin
Re: [Cooker] cooker - state of play
On Sat 05 Jul 2003 17:12, Stphane Soucy posted as excerpted below: I try to put set -x at the start of my /etc/rc.sysinit script and it stop to freeze!!! I don't know why??? Please observe the Cooker list guidelines and refrain from posting in HTML. I am replying to this out of my trash folder, where it was deposited because you posted in HTML, which IMO is only fit for use in mail by spammers and crackers. Some may not see your post at all, if in HTML. (It seems Evolution users have this issue more than most, for some reason. You aren't the first and won't be the last..) Your question?.. I don't know, but I'm guessing it may have something to do with the system not being fully up and ready for such a command at that point. IOW, it may cause BASH to attempt to load something it doesn't yet have access to. It may also have to do with the BASH vs. SH distinction, or some such. Just guesses.. -- Duncan - List replies preferred. They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. Benjamin Franklin
Re: [Cooker] cooker - state of play
Hello Olivier Blin, I know its not on topic but it seemms that your email address on laposte.net is blacklisted by spamcop... I was playing with some antispam tools and obviously it intrigued me what was supposedly spam. So if you find people not responding or members on the cooker and other lists donot see your responses and use an antispam service. -- Best regards, tracer Using theBAT 1.63 Beta/7 mail to : [EMAIL PROTECTED] C.C.S. Associates handphone : 01-891-9560 FAX (USA): (208) 460-3753 pgp 6.5.3 : 0x909D9B10
