The openafs-client script assumes that the module extension is *.ko while in my case it is just *.o as I am using the 2.4 kernel. Actually, upgrading from openafs 1.10, one cannot really be using kernel 2.6 since openafs 1.10 works only with 2.4 kernels, as far as I know. Unfortunately, the 1.10, which is the only version marked stable, does not compile with gcc 3.4.4 at all, so the upgrade is necessary. Thanks for working on the OpenAFS ebuilds!
I guess you mean the line: elif [ ! -f /lib/modules/$(uname -r)/kernel/fs/openafs/openafs.ko ]; then right? I've tried to make everything both linux-2.4 and -2.6 compliant, but this hack clearly doesn't conform. Sorry about that. I didn't see any other solution at the time, but now I think maybe the patch for /etc/init.d/openafs-client that I'm including could work. Could you try it out and send me some feedback on that? Thanks for reporting! (ps: did your upgrade go smoothly for the rest?)
Created attachment 75248 [details, diff] patch for /etc/init.d/openafs-client to work with 2.4 kernels Here it is. Let me know?
(In reply to comment #2) > Created an attachment (id=75248) [edit] > patch for /etc/init.d/openafs-client to work with 2.4 kernels > > Here it is. Let me know? > This does not seem to work. The "modprobe -l" command requires an exact match to be satisfied. You'd have to say "modprobe -l openafs.o" or "modprobe -l openafs.*". Of course, then it would be no different from using openafs.* in the normal file existence test "if [ ! -f /.../openafs.* ]", which is what I have in the script right now. Other than that, the upgrade worked fine, which was quite a relief. The "stable" openafs (1.2.10) does not compile with gcc 3.4.4, so after the gcc upgrade users have no choice. Perhaps it's time to mark some later version stable, it's probably more stable than 1.2.10 ever was. I seem to recall openafs versions <1.2.12 had some serious issues discussed on the openafs list. The only serious trouble is with the findutils package (xargs, find, ...), not openafs itself. Basically, findutils detection of afs keyword in the USE variable will seriously break the system startup scripts. I filed a bug report for findutils about this problem. Thanks a lot for working on gentoo openafs, it's been extremely useful for me.
Created attachment 75382 [details, diff] New attempt for patch to init script to work under both 2.4 and 2.6 > This does not seem to work. The "modprobe -l" command requires an exact match > to be satisfied. You'd have to say "modprobe -l openafs.o" or "modprobe -l > openafs.*". But this doesn't work on 2.6 kernels, so doesn't solve anything either. > Of course, then it would be no different from using openafs.* in > the normal file existence test "if [ ! -f /.../openafs.* ]", which is what I > have in the script right now. I kind of dislike this path specification in an init script. This patch is a bit of a rewrite. Could you test this? Thanks
(In reply to comment #4) > > I kind of dislike this path specification in an init script. This patch is a > bit of a rewrite. Could you test this? I agree, this is a cleaner solution. So far, it seems to work fine, loading and unloading afs on reboot. However, I cannot test it on 2.4 kernel any more because I have just upgraded to 2.6.
Fixed in openafs-1.4.0-r1
