Package Details: openafs 1.8.13.1-1

Git Clone URL: https://aur.archlinux.org/openafs.git (read-only, click to copy)
Package Base: openafs
Description: Open source implementation of the AFS distributed file system
Upstream URL: http://www.openafs.org
Licenses: IPL-1.0
Conflicts: openafs-features
Submitter: None
Maintainer: Bevan
Last Packager: Bevan
Votes: 61
Popularity: 0.000000
First Submitted: 2006-02-01 17:18 (UTC)
Last Updated: 2024-12-21 09:26 (UTC)

Latest Comments

« First ‹ Previous 1 .. 8 9 10 11 12 13 14 15 16 17 18 .. 32 Next › Last »

Bevan commented on 2014-11-28 21:40 (UTC)

@drslmr: I haven't heard of anyone else with this problem until now. I don't think it's a packaging issue so you maybe should ask on the developer's mailing list (https://lists.openafs.org/mailman/listinfo/openafs-devel) or file a bug report (rt.central.org). Upstream is generally very responsive.

drslmr commented on 2014-11-27 11:50 (UTC)

I get this error on logouts: kernel: openafs: inode freed while on LRU kernel: ------------[ cut here ]------------ kernel: kernel BUG at /var/lib/dkms/openafs/1.6.10/build/src/libafs/MODLOAD-3.17.3-1-ARCH-SP/osi_vfsops.c:291! .....

Bevan commented on 2014-10-06 17:12 (UTC)

I just added the two patches for linux 3.17 since it hit [testing]. I only tested the build and functionality on linux 3.16 though. If there are any problems please report them.

Bevan commented on 2014-09-26 22:45 (UTC)

Yeah, as soon as linux 3.17 is released I will add the patches. Until now they are not applied to openafs-stable but still under review and it's not clear yet, if the two patches are all that's needed for linux 3.17. So I will wait until there is a stable kernel version.

totsilence commented on 2014-09-26 21:00 (UTC)

Hey, It seems that the imminent release of Linux 3.17 will require patches again. As far as I can tell these are the ones: http://gerrit.openafs.org/#q,status:open+project:openafs+branch:master+topic:linux_3.17,n,z Could you apply them to your openafs packages Bevan? Thanks in advance!

totsilence commented on 2014-04-04 08:21 (UTC)

Thanks Bevan :) I tried the packages from your git repo and I found that: a) works fine, thanks! b) does not work, because apparently the makefile which is actually used by dkms looks very simple and contains no "only_libafs" target.

Bevan commented on 2014-04-02 21:36 (UTC)

Hi, a) I assume you mean the behavior on bootup? This should be fixable by adding dmks to After= in openafs-client.service. I will try this and add it. b) You are right. "make only_libafs" should be sufficient here. I will test and correct this, too. I probably won't do a pkgrel for those two issues. I expect a new upstream version soon.

totsilence commented on 2014-04-02 21:09 (UTC)

Hey, everythings working fine here with the new dkms module + openafs split package. However, I noticed the following two things: a) when a new kernel is installed, dkms correctly rebuilds the kernel module but openafs-client.service starts before the compilation is finished and doesn't wait. Is there a way to make openafs-client.service wait for the compilation of the module? b) Is there a quicker way to compile only the kernel module? It seems that dkms compiles all of openafs and then later on only copies the kernel module. Cheers and thans for the good work :)

cptiglo commented on 2014-03-23 18:44 (UTC)

The problem with your approach is, that dkms will not notice if the "make clean" command fails. Because it just gets the last always successful exit code of the "rm -f" command!

Bevan commented on 2014-03-22 10:16 (UTC)

Oh, I should have mentioned here that I solved it using a similar approach... :) https://bitbucket.org/Bewahn/openafs-archlinux-package/commits/0a01c420c94cf19b151bdc23e2d7c6472f799d70 When already posting here: I reverted the change of the dkms module location. I'm not sure how dkms will handle the situation of minor kernel updates otherwise. I will test this on the next kernel update but until now I'd like to stay on the safe side.