Package Details: openafs

Git Clone URL: (read-only, click to copy)
Package Base: openafs
Description: Open source implementation of the AFS distributed file system
Upstream URL:
Licenses: custom:"IBM Public License Version 1.0"
Conflicts: openafs-features
Submitter: None
Maintainer: Bevan
Last Packager: Bevan
Votes: 61
Popularity: 0.010211
First Submitted: 2006-02-01 17:18 (UTC)
Last Updated: 2022-07-26 05:15 (UTC)

Latest Comments

bidulock commented on 2021-11-30 21:29 (UTC)

Need to add libxcrypt to depends.

kaspi commented on 2021-10-25 12:31 (UTC)

Hi Bevan, indeed, it is most likely this (unfortunate) outage. Thanks for pointing it out!

Bevan commented on 2021-10-25 11:26 (UTC)

Hi Jan. Could that be caused by this outage?

kaspi commented on 2021-10-25 11:10 (UTC) (edited on 2021-10-25 11:10 (UTC) by kaspi)

Hi all,

after updating the system, I have troubles using AFS (details follow) and I wonder if anyone experiences the same or potentially would know how to fix it.

The SW versions which I use: kernel 5.14.14-arch1-1, openafs 1.8.8-1 and openafs-modules 1.8.8-2. The first problem occurs when running aklog:

Authenticating to cell (server
Trying to authenticate to user's realm CERN.CH.
Getting tickets: afs/
Using Kerberos V5 ticket natively
About to resolve name jkaspar to id in cell
# here it hangs for a minute
Error -1
Setting tokens. jkaspar @

Then, trying to ls a directory on AFS, I get a time out:

> ll /afs/
ls: cannot open directory '/afs/': Connection timed out

Thanks in advance,


drslmr commented on 2021-10-08 06:38 (UTC)

Yes, it works for me now with: linux 5.14.8.arch1-1 openafs-modules-dkms 1.8.8-2

Thank you very much.

Bevan commented on 2021-10-07 19:41 (UTC)

The potential RIP with kernel 5.14 should be fixed by openafs-modules-1.8.8-2 and openafs-modules-dkms-1.8.8-2. See for the ongoing review of the fix.

Bevan commented on 2021-10-06 07:29 (UTC) (edited on 2021-10-06 07:42 (UTC) by Bevan)

drslmr: Thanks for noticing us here. The same error has been reported on the openafs mailing list:

So far, it could not be reproduced but with your report it becomes pretty clear that it is an issue with 5.14.8 / 5.14.9 specifically. I will forward your report to the mailing list as well so this issue can be sorted out quickly.

drslmr commented on 2021-10-06 05:58 (UTC)

I reported a kernel bug, that may have to do with afs:

Bevan commented on 2021-03-25 09:44 (UTC)


For AFS blocking reboot/shutdown having some effective KillMode could indeed help. When restarting the service we need to be careful: As far as I know, the openafs module needs to be reloaded before afsd is started again. I guess if systemd kills afsd, ExecStop=/usr/bin/rmmod openafs won't be executed afterwards. Also I'm not entirely sure if one even can unload the module if afsd crashed / was killed. Or if afsd is even killable. So I think we need to test this.

I myself only have a little test cell available where it's hard to reproduce these hang-ups. Could you test a modified service file in your environment for a while and report back? It uses KillMode=mixed and adds a few checks on startup to make sure that we do not run into some undefined behavior on restarts.

You can just save the following file as /etc/systemd/system/openafs-client.service:

Description=OpenAFS Client Service dkms.service

ExecStartPre=/bin/bash -c "findmnt /afs >/dev/null; test $? -ne 0 || (echo /afs is still mounted -- not starting && exit 1)"
ExecStartPre=/bin/bash -c "pidof afsd >/dev/null; test $? -ne 0 || (echo AFS client appears to be still running -- not starting && exit 1)"
ExecStartPre=/bin/bash -c "/usr/bin/lsmod|grep openafs >/dev/null; test $? -ne 0 || (echo openafs module still loaded -- not starting && exit 1)"
ExecStartPre=/usr/bin/modprobe openafs
ExecStart=/usr/bin/afsd $AFSD_ARGS
ExecStartPost=/usr/bin/fs setcrypt on
ExecStop=/usr/bin/umount /afs
ExecStop=/usr/bin/afsd -shutdown
ExecStop=/usr/bin/rmmod openafs


kgizdov commented on 2021-03-23 09:42 (UTC)

is it possible to adjust the KillMode=none in the service file to KillMode=control-group or KillMode=mixed at least? I've had the issue of AFS blocking reboot/shutdown or not being able to restart the service, because systemd can't manage it properly.

gay commented on 2020-10-20 00:57 (UTC)

@Bevan: Thanks again for your help. Trying again a week later, the package compiled cleanly. Since the source has evidently not changed, the problem must have been something with my system last week. Perhaps something did not update correctly without me noticing.

Bevan commented on 2020-10-13 19:06 (UTC)

@gay: That's weird. I cannot reproduce this issue. Did you clean the build directory between the builds? Maybe there is a partial build still lying around from your earlier attempts?

gay commented on 2020-10-13 16:52 (UTC)

@Bevan: Thanks for the very quick reply and for pointing out that I am missing bison.

However, it seems that I receive the exact same error as reported below (even the addresses) with /usr/bin/yacc from bison 3.7.2-1 (the most recent version of bison), all of base-devel installed and all packages up to date.

It is, of course, possible that I am somehow missing something again.

A quick search reveals that similar errors have popped up periodically with openafs. (Apparently that was occasionally related to both byacc and bison being installed, but it's not that in my case.)

Bevan commented on 2020-10-13 14:21 (UTC)

@gay: the packages in the AUR assume that all packages from the base-devel group are installed: pacman -S base-devel

This also includes the bison package which contains yacc. byacc-bison in the AUR is an alternative implementation which seems to be missing some symbols required by openafs.

gay commented on 2020-10-13 14:04 (UTC) (edited on 2020-10-13 14:05 (UTC) by gay)

I am having difficulty compiling this. Are there maybe missing dependencies? The make process complains about missing yacc. I tried installing byacc-bison from AUR that provides /usr/bin/yacc, but make is still not happy:

/usr/bin/ld: compile_et.o: in function `main':
compile_et.c:(.text+0x7f5): undefined reference to `yyin'
/usr/bin/ld: compile_et.c:(.text+0x813): undefined reference to `yyout'
/usr/bin/ld: compile_et.c:(.text+0x9d0): undefined reference to `yyout'
/usr/bin/ld: compile_et.c:(.text+0xc74): undefined reference to `yyin'
/usr/bin/ld: compile_et.o: in function `yyerror':
compile_et.c:(.text+0xf2e): undefined reference to `yylineno'
/usr/bin/ld: error_table.o: in function `yyparse':
error_table.c:(.text+0x9ab): undefined reference to `yylex'
/usr/bin/ld: error_table.c:(.text+0xefe): undefined reference to `yylex'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:39: compile_et] Error 1

nickoe commented on 2020-07-08 22:55 (UTC)

@Bevan, ok, thank you for looking into this and maintaining the package :)

Bevan commented on 2020-07-08 21:38 (UTC) (edited on 2020-07-08 21:38 (UTC) by Bevan)

@nickoe: I had another look and I think there is not much we can do about that. The source code contains the __FILE__ macro in many places and the build system is written in a way that the source code location is given as absolute path to the compiler. It's mostly a cosmetic warning. A possible consequence is that certain error messages contain the path where the openafs package was built.

nickoe commented on 2020-07-07 11:52 (UTC)

@Bevan, ok no worries. I noticed this in a couple of packages by now. Maybe it is a new check that has been added to makepkg.

Bevan commented on 2020-07-07 11:38 (UTC)

@nickoe: Yes, for some reason the paths to some of the source files are included in those binaries / libraries. So far I just ignored this phenomenon - it does not really hurt. But I will see if I can find the root cause for this and if it is easily avoidable.

nickoe commented on 2020-07-07 11:30 (UTC)

I got this warning when building:

==> WARNING: Package contains reference to $srcdir

darkxsun commented on 2020-04-06 22:22 (UTC)

@dmaxter Not needed. See

Note: Packages in the AUR assume that the base-devel group is installed, i.e. they do not list the group's members as build dependencies explicitly.

dmaxter commented on 2020-04-06 21:31 (UTC) (edited on 2020-04-06 21:32 (UTC) by dmaxter)

Missing dependencies: automake and autoconf

drslmr commented on 2017-11-24 14:02 (UTC)

Hi, I had some issue concerning ypbind together with logging into my afs account where I have my home directory under afs. See In the above communication there was one workaround suggested to give the appropriate privileges to the login process, which works for me. But the better option would be to use nscd or sssd instead of yp. Does anyone have any experience using nscd or sssd with logging into an afs account?

drslmr commented on 2017-11-06 13:06 (UTC)

Unfortunately I could not find out what exactly caused my recent issue. But from a former snapshot of my installation that did not have the issue it was possible to upgrade to today's state. And now the issue is gone.

drslmr commented on 2017-11-04 09:50 (UTC) (edited on 2017-11-04 09:50 (UTC) by drslmr)

Bevan, thanks a lot for your effort. I'm sorry for taking your time. On a different machine I did update openafs and linux to 4.13.11-1-ARCH and I can not reproduce the problem. Too, on my ill machine I can still use an older snapshot of an complete arch installation without the reported issue. So I guess something went wrong during upgrading. I remember that at some point during post installation hook my disk ran out of space. I think it was due to openafs-modules-dkms. I removed parts of /var/vache and tried to reinstall every package again. But still something is wrong. It's my problem. Thanks again.

Bevan commented on 2017-11-03 14:05 (UTC)

drslmr: This sounds more like an issue with your AFS cell to me. If it's not, I guess it would be an upstream bug as I don't think we touch any code that's relevant for that. Can you try to debug this with your cell provider? I did a small test in a local test cell and it worked as expected with kernel 4.13.10-1-ARCH and the current openafs packages: 1. Created a user for an IP range: 2. Created a group containing this user named localnet 3. Set ACLs for a folder to only allow access by group localnet 4. Within this directory I created another folder only accessible for my authenticated user Without a token I could access the folder from step 3 from my local network and after obtaining a token I could also enter the folder from step 4. One thing that does not work is giving the IP-based user (i.e. permissions via ACLs. This is on purpose and documented in

drslmr commented on 2017-11-03 09:59 (UTC)

Since last linux and openafs upgrade I can't access my directories anymore. In the directory tree I can see directories only down to a certain level. As soon as there is an additional IP based access right required I don't see the directories anymore. This IP based access right seams to require that the hosts IP address belongs to a certain set of IP sub-nets. I have no clue how that works. But it seams to not work anymore now.

kgizdov commented on 2017-10-24 21:00 (UTC)

latest version compiles for me fine.

totsilence commented on 2017-10-24 10:32 (UTC)

I prepared a patch and submitted it here as an OpenAFS bug: I guess they will move the patch to gerrit if they agree with it. The patch solves the linking issue for me.

Bevan commented on 2017-10-23 17:23 (UTC)

Good catch! So it is caused by the latest ncurses update: Searching the web for "ncurses with-termlib=tinfo" shows that this is/was an issue for other software packages as well. I guess the configure logic needs to be extended for again. I won't have time to look into this today. If you come up with a patch we can directly send it upstream for review.

totsilence commented on 2017-10-23 17:13 (UTC)

I can reproduce the linking issue as well. It is related to missing "LINES" symbol which is part of in our ncurses package and -ltinfo is missing in some linker commands. When adding -ltinfo things build. Probably another patch to openafs autotools files is required.

Bevan commented on 2017-10-23 16:57 (UTC)

Mmh.. I think we are actually having two different issues here: 1) Infinite loop on configure: For some reason this seems to only occur on some systems. I cannot reproduce it. However, thanks to totsilence there is a patch which I now applied to all three openafs packages. 2) Linking error when trying to build openafs. This issue I can reproduce and it only occurs when building the openafs package. The module packages build fine. Unfortunately, the curses patch does not fix this issue although the error points into a similar direction (maybe the latest ncurses update?) So this is still unfixed...

kgizdov commented on 2017-10-23 09:18 (UTC)

Yes, indeed. It filled up my SSD twice yesterday... I was able to build it by manually waiting and killing the process, so the compilation can continue. What's strange is that it builds on my desk PC fine with the same exact environment. Interesting...

totsilence commented on 2017-10-23 08:33 (UTC)

Bevan, kgizdov: Yes, I need that patch to compile the kernel module. I don't know yet at which point this patched became necessary, but it's definetely required here: Otherwise ./configure goes into an infinite loop (it calls the "/usr/bin/yes") and "make.log" in the dkms build folder grows infinitely - I stopped it at 12 GB size.

Bevan commented on 2017-10-23 07:42 (UTC)

kgizdov: Could be related to the issue addressed here: I will try to reproduce this later today.

kgizdov commented on 2017-10-22 23:53 (UTC)

stopped building for me: [ yes != "" ] || case amd64_linux26 in \ alpha_dux*|sgi_*|sun*_5*|rs_aix*|*linux*|hp_ux11*|ia64_hpux*|*[nof]bsd*) \ cd src && cd tptserver && make all ;; \ *_darwin_[1-6][0-9]) \ echo Not building MT ptserver for amd64_linux26 ;; \ *_darwin_*) \ cd src && cd tptserver && make all ;; \ *) \ echo Not building MT ptserver for amd64_linux26 ;; \ esac set -x; \ if test "-lncurses"; then \ cd src && cd gtx && make all ; \ else \ echo Not building gtx, because no curses-headers found. ; \ fi + test -lncurses + cd src + cd gtx + make all make[3]: Entering directory '/home/gizdov/Packages/builds/openafs/src/openafs-' gcc -o gtxtest gtxtest.o libgtx.a /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- /home/gizdov/Packages/builds/openafs/src/openafs- -lncurses -lresolv /usr/bin/ld: libgtx.a(curseswindows.o): undefined reference to symbol 'LINES' /usr/lib/ error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[3]: *** [Makefile:179: gtxtest] Error 1 make[3]: Leaving directory '/home/gizdov/Packages/builds/openafs/src/openafs-' make[2]: *** [Makefile:350: gtx] Error 2 make[2]: Leaving directory '/home/gizdov/Packages/builds/openafs/src/openafs-' make[1]: *** [Makefile:694: build] Error 2 make[1]: Leaving directory '/home/gizdov/Packages/builds/openafs/src/openafs-' make: *** [Makefile:39: all_nolibafs] Error 2

Ethyling commented on 2017-09-14 14:01 (UTC)

@Bevan thanks

darkxsun commented on 2017-09-13 15:52 (UTC)

caddar: for more context, note than AUR packages assume base-devel is installed (including patch)

caddar commented on 2017-09-13 11:35 (UTC)

Yes and no. The hint with the AUR helper helped to resolved the problem - I tried to build the package manually and got an error complaining about missing command 'patch'... I use pacaur, and it seems it somehow doesn't complain or at least properly propagate the error that the patch was found, but never applied due to missing patch-utility. After installing 'patch' everything worked, both manually and with the AUR helper. Thanks for the hint, should have known myself to try it manually...

Bevan commented on 2017-09-13 11:22 (UTC)

caddar: The fact that the error still occurs in line 109 shows that the patch has not been applied. Otherwise it would have to be line 112. I double checked that the patch should be applied in the PKGBUILD, though. I therefore guess there is some kind of caching problem. A wild guess: Was there still an old src directory lying around before you ran makepkg? Or are you maybe using some AUR helper that caches package sources? I did not increase pkgrel because the compiled result does not change by applying the patch but this may confuse AUR helpers.

caddar commented on 2017-09-13 11:14 (UTC) (edited on 2017-09-13 11:15 (UTC) by caddar)

Hi, seems the push yesterday included some fix (0004), but I still get the same error (I think): "volinodes.h:109:45: error: unitptr_t undeclared (first use in this function); did you mean intptr_t?" Any ideas? I'm not familiar with c(++), so before wasting time for something that might be trivial.. (I checked that my openafs-git indeed includes the 0004-patch) best, c

Bevan commented on 2017-09-12 16:32 (UTC)

Ethyling: Thanks for the hint. I can reproduce the issue and will push a fixed version within the next hours.

Ethyling commented on 2017-09-12 14:33 (UTC)

Hi guys, There is a build problem with file volinodes.h : Got the error "‘uintptr_t’ undeclared (first use in this function); did you mean ‘intptr_t'". I'm building it on a fresh system. Regards.

totsilence commented on 2017-02-27 11:14 (UTC)

Hey Bevan, openafs needs this patch: (789319bf0f2b26ad67995f8cbe88cee87a1bbdc0 in master) to build with Linux 4.10. Cheers!

mmrezaie commented on 2016-10-20 12:11 (UTC)

@Bevan thanks

Bevan commented on 2016-10-20 11:25 (UTC)

@mmrezaie: The tool to obtain an AFS token using Kerberos is called aklog, not afslog:

mmrezaie commented on 2016-10-20 11:01 (UTC)

I wonder why I cannot find afslog command with this package and I cannot see anyone has any problem with it. So maybe I am doing something wrong or am I? Because of this I cannot get afs token so to get write access to my home folder on afs.

totsilence commented on 2016-03-19 12:13 (UTC)

Hi guys, There are new build problems with Linux 4.5 :( This is in addition to the build problems with Linux 4.4. I think the 4.4 patches are still under review?

drslmr commented on 2016-03-01 07:45 (UTC)

@Bevan it would be fine with me if you could please forward my post.

Bevan commented on 2016-02-29 16:43 (UTC)

There are first reports of data corruption when running OpenAFS on Linux 4.4. The proposed patches should therefore only be considered for testing and debugging and not for actual use in production.

Bevan commented on 2016-02-29 16:26 (UTC)

@drslmr: Thank you for testing! I'm glad that it only hit a git workspace that is easy to recover. code -512 is -ERESTARTSYS, so I think you hit exactly the problem that was anticipated on the mailing list: I think it would be great if you could report this to the mailing list. If you don't want to do that, I'd like to forward your post from here to the mailing list, if you have no objections.

drslmr commented on 2016-02-29 14:03 (UTC)

I tried the patch and I get problems. When I do checkout a different branch of my software from a git repository things fail and I'm left with a corrupted workspace. The log files shows the following message: kernel: afs: Lost contact with file server ... in cell ... (code -512) (all multi-homed ip addresses down for the server) kernel: afs: failed to store file (network problems) kernel: afs: file server ... in cell ... is back up (code 0) (multi-homed address; other same-host interfaces may still be down)

Bevan commented on 2016-01-18 19:17 (UTC)

@totsilence: If you are brave and have backups, you may test this version: Patches applied:

totsilence commented on 2016-01-18 16:35 (UTC)

Thanks @Bevan, but it appears there are no patches, yet (or I couldn't find them). I've opened a bug report on the OpenAFS bug tracker.

Bevan commented on 2016-01-18 16:13 (UTC)

@totsilence: I will have a look and add them if they are already available. This may take until tomorrow, though.

totsilence commented on 2016-01-18 10:47 (UTC)

Linux 4.4 is in testing and openafs does not compile. Was anybody able to find the necessary patches?

Bevan commented on 2015-10-27 17:15 (UTC)

openafs's /usr/bin/sys file currently causes issues with python programs using packages from gi.repository (Gtk, Gdk, GObject, ...). Also other python programs could be affected. Corresponding bugs are already reported: A workaround is to add " -I" to the shebang (first line) of affected scripts.

Bevan commented on 2015-09-05 13:31 (UTC)

I will have a look into this. Hopefully today or tomorrow.

totsilence commented on 2015-09-03 22:24 (UTC)

Also this one, I think.,11933

totsilence commented on 2015-09-03 21:51 (UTC)

Hi guys, it appears Linux 4.2 (now in testing) requires patches again. Could you check Bevan? I think these are the patches (not sure though),11948,11949,11950,11951 Thanks!

kaspi commented on 2015-07-27 09:24 (UTC)

@Bevan: OK, thanks for explanation!

Bevan commented on 2015-07-27 09:18 (UTC)

@kaspi: bison and flex are both part of the base-devel group. All users using the AUR are supposed to have base-devel installed and the packages in this group should not be included in makedepends:

kaspi commented on 2015-07-27 09:16 (UTC)

I've just tried to build the package, which failed due to unknown commands 'yacc' and 'flex'. The problem got solved after having installed 'bison' and 'flex' packages. Therefore I wonder whether it would be reasonable to include them into 'makedepends'. And likewise for 'openafs-modules'. Thanks!

Bevan commented on 2015-05-02 10:40 (UTC)

@alexpe87: I now added that option. You just need to rebuild openafs, no need to rebuild the module.

alexpe87 commented on 2015-05-02 10:30 (UTC)

I would be really happy to have that back at least as an option in the PKGBUILD... Our cell is unfortunately still relying on DES and thus I can't access it anymore. My plan is now moving data from there to somewhere else, but unless the module doesn't work, I can't get the data out of the cell, upgrade it and then rely on a more secure encryption unfortunately. It would be great to keep some kind of backward compatibility at least for a while from now...

Bevan commented on 2015-04-30 21:04 (UTC)

Yes, I removed those on purpose. When updating to openafs a message was shown explaining this. Nobody should use this anymore, really... Removing "--disable-kauth" will not work as part of the kauth suite conflict with already existing files. If you really still need this I will add an option to the PKGBUILD to enable installation of the old tools. But please check again if and why you need them.

darkxsun commented on 2015-04-30 19:05 (UTC)

@alexpe87 I think this is related to dropping kauth: It looks like you can remove the --disable-kauth line from the PKGBUILD to build with kauth.

alexpe87 commented on 2015-04-30 18:48 (UTC)

When updating to Kernel 4.0 and upgrading to the openafs, openafs-modules, I loose the possibility to get a token via klog, klog.afs etc... these aren't there anymore! Any idea what mmight have gone wrong?

Bevan commented on 2015-04-13 11:23 (UTC)

For Linux 4.0 two patches are required:,status:merged+project:openafs+branch:openafs-stable-1_6_x+topic:release16111,n,z I won't backport these here as openafs is expected to be released soon which includes these changes.

kaptoxic commented on 2015-02-22 21:04 (UTC)

I installed openafs-modules package and now the openafs service started working again for me

kaptoxic commented on 2015-02-11 02:55 (UTC)

I cannot start openafs (with or without -module(-dkms) package installed). Error: $ uname -r 3.18.6-1-ARCH $ cat /lib/modules/extramodules-*/version 3.18.6-1-ARCH

Bevan commented on 2015-02-09 08:44 (UTC)

Linux 3.19 landed in [ŧesting]. I will push new versions of openafs to deal with that during the day.

alexpe87 commented on 2015-01-15 14:26 (UTC)

Works again! Reboot fixed it.

Bevan commented on 2015-01-15 14:18 (UTC)

The status output looks like there are several afsd processes still running. AFS was never really good at being restarted... Could you try a reboot?

alexpe87 commented on 2015-01-15 14:09 (UTC)

Other message by journalctl -xe... Jan 15 15:08:00 romanov systemd[1]: Failed to start OpenAFS Client Service. -- Subject: Unit openafs-client.service has failed -- Defined-By: systemd -- Support: -- -- Unit openafs-client.service has failed. -- -- The result is failed. Jan 15 15:08:00 romanov systemd[1]: Unit openafs-client.service entered failed state. Jan 15 15:08:00 romanov systemd[1]: openafs-client.service failed.

alexpe87 commented on 2015-01-15 14:07 (UTC)

Hi! I recompiled the module and the DKMS module on the current (3.18.2) kernel. Then I did a systemctl restart openafs-client preceded by a systemctl daemon-reload. It came back to me with an error message, stating that the module couldn't be started. Yes I use the DKMS, too and I'm aware it should take some seconds - minutes till the module works. sudo systemctl status openafs-client.service ⏎ ● openafs-client.service - OpenAFS Client Service Loaded: loaded (/usr/lib/systemd/system/openafs-client.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2015-01-15 15:05:14 CET; 16s ago Process: 9878 ExecStart=/usr/bin/afsd $AFSD_ARGS (code=exited, status=1/FAILURE) Process: 9876 ExecStartPre=/usr/bin/modprobe openafs (code=exited, status=0/SUCCESS) Main PID: 3913 CGroup: /system.slice/openafs-client.service ├─3913 /usr/bin/afsd -dynroot -fakestat -afsdb ├─4035 /usr/bin/afsd -dynroot -fakestat -afsdb ├─4145 /usr/bin/afsd -dynroot -fakestat -afsdb ├─4315 /usr/bin/afsd -dynroot -fakestat -afsdb ├─4509 /usr/bin/afsd -dynroot -fakestat -afsdb ├─9648 /usr/bin/afsd -dynroot -fakestat -afsdb ├─9715 /usr/bin/afsd -dynroot -fakestat -afsdb └─9883 /usr/bin/afsd -dynroot -fakestat -afsdb

Bevan commented on 2015-01-15 13:13 (UTC)

@alexpe87: Could you be a bit more specific? In principle it should work with that kernel version. Please note that if you are using the dkms version of the module it takes some time after the first boot of the new kernel for the module to be compiled.

alexpe87 commented on 2015-01-15 12:05 (UTC)

on kernel 3.18.2 seems to be broken for me....

totsilence commented on 2014-12-17 22:56 (UTC)

That did it :) Thanks! Let's hope they include something along the lines of your patch in the official repo.

Bevan commented on 2014-12-17 21:27 (UTC)

OK, one last attempt :D Please try again. If that does not work we have to wait.

totsilence commented on 2014-12-17 20:51 (UTC)

I tried your patch, and compilation moves on a bit, but still doesn't succeed: (We don't really need to debug this, I can also just wait until the developers have included support for 3.18.1)

Bevan commented on 2014-12-17 20:32 (UTC)

In the new packages there is a very dirty patch included that should fix the problem. You have to uncomment a line in the build() section of the PKGBUILD for that. This is untested but if you want give it a try :)

Bevan commented on 2014-12-17 19:55 (UTC)

Thanks for testing! I followed the error up to a change in Linux 3.18.1. As far as I can see there is no patch for openafs available yet, that addresses this. I will double check and contact the developers.

totsilence commented on 2014-12-17 19:37 (UTC)

Thanks! You're really fast :) Unfortunately it still does not compile:

Bevan commented on 2014-12-17 19:24 (UTC)

I just pushed updates to the openafs-modules packages.

totsilence commented on 2014-12-17 19:16 (UTC)

Hello Bevan, another Linux release, another openafs build failure :) It appears the kernel module does not compile with Linux 3.18 (which is now in testing). Have you heared anything? Cheers Bastian

Bevan commented on 2014-12-03 15:29 (UTC)

The two files you found are fine. They just let openafs start automatically after boot. I think I might have a clue what's going on. I suggest moving this from AUR to email. Could you contact me using the mail address in my AUR profile?

drslmr commented on 2014-12-03 15:00 (UTC)

@Bevan Concerning consequences: The computer does not completely switch off during shutdown. It keeps well sort of running with the display on but other way to switch it off as to press the on/off button for more than 10 seconds.

drslmr commented on 2014-12-03 14:44 (UTC)

I do have these: /etc/systemd/system/ /etc/systemd/system/ Should these files be removed? The error does not occur by stopping openafs-client alone.

Bevan commented on 2014-12-03 14:38 (UTC)

Two things you could check before that: - Do you have a /etc/systemd/system/openafs-client.service lying around? - Is the error reproducable by stopping openafs-client? (systemctl stop openafs-client.service)

Bevan commented on 2014-12-03 14:34 (UTC)

OK, so we know it's not caused by our patching. I would suggest asking on the mailing list. I'm also following the conversation there so if there are questions about the packaging I can jump in. By the way: is the error message the only symptom or are there any visible consequences?

drslmr commented on 2014-12-03 14:28 (UTC)

@Bevan Thanks a lot for the quick support. Unfortunately I get a similar error with the new version. The error occurs when I shut down my computer not on logout as I wrote earlier. For modules I use only openafs-modules-dkms not openafs-modules. The completet message is: ystemd[1] Unmounted /afs. kernel: openafs: inode freed while on LRU kernel: ------------[ cut here ]------------ kernel: kernel BUG at /var/lib/dkms/openafs/1.6.11pre1/build/src/libafs/MODLOAD-3.17.4-1-ARCH-SP/osi_vfsops.c:291! kernel: invalid opcode: 0000 [#1] PREEMPT SMP kernel: Modules linked in: bnep bluetooth rfkill fuse openafs(PO) xt_conntrack iptable_filter ipt_MASQUERADE xt_REDIRECT xt_tcpudp iptable_nat n kernel: processor sch_fq_codel nfs lockd sunrpc fscache vboxnetflt(O) vboxdrv(O) e1000e ptp pps_core e100 mii ext4 crc16 mbcache jbd2 hid_gener kernel: CPU: 0 PID: 1172 Comm: umount Tainted: P IO 3.17.4-1-ARCH #1 kernel: Hardware name: Comptronic pczW1007/DX38BT, BIOS BTX3810J.86A.1893.2008.1009.1712 10/09/2008 kernel: task: ffff880217015a90 ti: ffff8800c8fbc000 task.ti: ffff8800c8fbc000 kernel: RIP: 0010:[<ffffffffa08c1f32>] [<ffffffffa08c1f32>] afs_evict_inode+0x52/0x70 [openafs] kernel: RSP: 0000:ffff8800c8fbfdd8 EFLAGS: 00010286 kernel: RAX: 0000000000000021 RBX: ffff8802195f9800 RCX: 0000000000000021 kernel: RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 kernel: RBP: ffff8800c8fbfde0 R08: 0000000000000092 R09: 00000000000003af kernel: R10: 0000000000000003 R11: 00000000000003af R12: ffff8802195f9900 kernel: R13: ffffffffa08e6100 R14: ffff8800c8fbfe30 R15: ffff8802195f9888 kernel: FS: 00007f37a29e5780(0000) GS:ffff88022fc00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b kernel: CR2: 00007fff8ff28118 CR3: 0000000223646000 CR4: 00000000000407f0 kernel: Stack: kernel: ffff8802195f9800 ffff8800c8fbfe08 ffffffff811e2ad4 ffff8800c8fbfe30 kernel: ffff8802206c37a8 ffff8802206c38a8 ffff8800c8fbfe20 ffffffff811e2bf9 kernel: ffff8802206c37a8 ffff8800c8fbfe70 ffffffff811e3a6c ffff8800c8fbfe30 kernel: Call Trace: kernel: [<ffffffff811e2ad4>] evict+0xb4/0x1a0 kernel: [<ffffffff811e2bf9>] dispose_list+0x39/0x50 kernel: [<ffffffff811e3a6c>] evict_inodes+0x11c/0x140 kernel: [<ffffffff811c9cf8>] generic_shutdown_super+0x48/0xf0 kernel: [<ffffffff811ca062>] kill_anon_super+0x12/0x20 kernel: [<ffffffff811ca429>] deactivate_locked_super+0x49/0x60 kernel: [<ffffffff811ca874>] deactivate_super+0x64/0x70 kernel: [<ffffffff811e725e>] mntput_no_expire+0xde/0x140 kernel: [<ffffffff811e8660>] SyS_umount+0xa0/0x420 kernel: [<ffffffff8153db29>] system_call_fastpath+0x16/0x1b kernel: Code: 00 00 75 29 48 8d bf 48 01 00 00 31 f6 e8 e7 04 8a e0 48 89 df e8 6f fd 91 e0 5b 5d c3 48 c7 c7 b0 f5 8d a0 31 c0 e8 75 4e c7 e0 < kernel: RIP [<ffffffffa08c1f32>] afs_evict_inode+0x52/0x70 [openafs] kernel: RSP <ffff8800c8fbfdd8> kernel: ---[ end trace 534464180560c616 ]---

Bevan commented on 2014-12-03 09:33 (UTC)

Correct. Linux 3.17 is not yet supported by 1.6.10. But the openafs-module packages include the neccessary patches to make it work with Linux 3.17. Of course it could be possible that this has side effects. Although I can't see anything related in the changelog for 1.6.11 you might test the prerelease that came out on monday. I created PKGBUILDs for that:

drslmr commented on 2014-12-03 08:30 (UTC)

@Bevan: Is kernel 3.17 supported anyway? In a thread on I found this statement: OpenAFS 1.6.10 does not support Linux 3.17 or later kernels. Linux 3.17 will be supported in 1.6.11. Not sure if it is related. The thread is:

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 ( or file a bug report ( 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:,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... :) 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.

cptiglo commented on 2014-03-22 10:04 (UTC)

Sorry for so much input, but I just figured out a more elegant solution than creating a dummy Makefile by just setting the dkms clean command to CLEAN="rm -f openafs.ko && [ ! -f Makefile ] || make clean" so that the "make clean" is only run if a Makefile exists.

cptiglo commented on 2014-03-21 13:13 (UTC)

The problem is that there exists no Makefile before the first "./configure". One solution would be to create a dummy Makefile by inserting # Create dummy Makefile if none exists [ -f ${pkgdir}/usr/src/${_srcname}-${pkgver}/Makefile ] || \ printf "clean:\n\t@echo 'Nothing to clean yet.'" > ${pkgdir}/usr/src/${_srcname}-${pkgver}/Makefile at the end of the package() function.

cptiglo commented on 2014-03-21 11:36 (UTC)

Doing a "dkms install openafs/1.6.6" in the end successfully builds the module, but in the beginning I do get a message: cleaning build area....(bad exit status: 2) Is it somehow possible to fix this?

cptiglo commented on 2014-03-21 09:26 (UTC)

Just one more thing concerning /extramodules: If two kernel directories symlink to the same extramodules, dkms should only build the module once for both of them, which is exactly the behaviour we would like to have. I think without putting the module into /extramodules dkms would rebuild for every minor release of the kernel.

cptiglo commented on 2014-03-21 09:19 (UTC)

Thank you!

Bevan commented on 2014-03-20 21:50 (UTC)

You are right. There can be two or even more extramodules directories in case some package (like openafs-modules ;)) has still a module lying around. I will include your change. Regarding DEST_MODULE_LOCATION: /extramodules was my first thought here, too. This would become an issue, if someone has two kernel versions installed where /extramodule points to the same location. But I don't think this should ever be the case, so I'll include that change, too. Thanks :)

cptiglo commented on 2014-03-20 21:33 (UTC)

Okay I can live with that. Then for the openafs-modules I would suggest doing _extramodules=$(cd /usr/lib/modules && ls -dt extramodules-*-ARCH | head -1) which should always give the path to the latest extramodules directory. I think after a major kernel update and before reboot the old extramodules directory in /usr/lib/modules will still exist. Concerning the dkms package: Could you change DEST_MODULE_LOCATION[0] to DEST_MODULE_LOCATION[0]="/extramodules" ?

Bevan commented on 2014-03-20 21:04 (UTC)

Hi, I thought about it and decided against a fixed kernel version in the PKGBUILD. I agree that this would be the right way in [community], but here in AUR it is different I think. If a fixed version was specified updating the kernel package would be a pain. You would first have to remove openafs-modules (because it depends on the old kernel package), then update the kernel, then build&install openafs-modules again with the updated PKGBUILD. Also this would not completely solve the issue of silently failing openafs. Sometimes the ABI also changes in minor kernel releases what makes a rebuild of the module necessary. So you still would have to be cautious after every kernel update. I did a few changes to the packages, including many of your suggestions and will probably release them on weekend if I cannot find any show-stopper. Thanks for all your feedback! :)

cptiglo commented on 2014-03-20 12:55 (UTC)

At least _I_ think it should be done in the "right" way. First of all because it's annoying that after a major kernel release openafs silently stops working, but also because I want to have openafs in the community repository sooner or later and it will most probably not be accepted if it's not packaged in the "right" way. Concerning your cons: I think these are just the reasons to have an additional dkms package for people who can't wait updating their kernel or use a different kernel version.

Bevan commented on 2014-03-20 10:58 (UTC)

Hi. Thanks for your input :) I'll apply the changes to openafs and test them. I'm a bit hesitating to put the kernel version into the PKGBUILD of openafs-modules. Pros: - it's the "right" way to do it - openafs most of the time needs patches for newer kernel versions anyway Cons: - I would have to modify the package here exactly when a new kernel hits [core]. I obviously cannot manage that - People using [testing] or other kernels would always have to edit the PKGBUILD if they're using another kernel version Another idea: Couldn't we just look for /usr/lib/modules/extramodules-*-ARCH and extract the version from that? Or are there chances that there is more than one extramodules dir? Should not be the case using the official kernel packages because you always only have one of them installed.

cptiglo commented on 2014-03-20 08:47 (UTC)

@Bevan: I am suggesting the following changes to your package files: openafs: * Changing package description from "client" to "open source implementation" to reflect that the openafs package does not only contain the client, but also database-/volume-server, pam-modules, etc... * Modified configure flags in order for the build not to depend on kernel headers. openafs-modules: * Made modules dependend on the latest kernel and kernel-headers major release, which is conform to the ARCH Kernel Module Package Guidelines ( This ensures that the modules will be automatically rebuild when updating the kernel to a new major release. * Getting the latest kernel version from /usr/lib/modules/extramodules-x.xx-ARCH/version and not with "uname -r". This and adding the --with-linux-kernel-build flag to the configuration will ensure that the modules are always build for the latest installed kernel version even without a reboot. * Added the specific kernel major version to the depmod calls in the openafs-modules.install file. Updating the install-file to the correct kernel version using sed in the PKGBUILD (This is also done in the NVIDIA kernel module in the official ARCH repositories).

Bevan commented on 2014-03-19 22:35 (UTC)

I worked on splitting the package. You can find the result here: I will wait a bit before releasing it here so people who are interested can test it.

Bevan commented on 2014-03-18 17:12 (UTC)

@cptiglo: Definately on my TODO list. Unfortunately I didn't find time until now. I'll give it a higher priority in the next days.

cptiglo commented on 2014-03-18 11:20 (UTC)

@Beavan: Would you be willing to split your package in kernel module and userspace tools?

Bevan commented on 2014-01-20 23:58 (UTC)

@cptiglo: I think a first step would be to separate the kernel module and the userspace tools like it is done in the openafs-features package. This should be possible and would reduce the amount of code that needs to be rebuilt after a kernel update. A second step would then be to provide a openafs-dkms package that provides openafs-module (or whatever it's called). I have little to no experience with dkms so this would either require some effort by me or a package/patch from someone else. One way or the other the dkms package should be an alternative to a "classic" openafs-module package so that dkms is not strictly required.

cptiglo commented on 2014-01-20 23:03 (UTC)

@Bevan Wouldn't it be desireable to have the openafs kernel module in a separate openafs-dkms package to have it rebuild automatically on a kernel upgrade?

darkxsun commented on 2014-01-15 20:11 (UTC)

@nickoe Restarting the service succeeds for me even though it shows the reload message.

nickoe commented on 2014-01-15 20:07 (UTC)

@Bevan, well, I need to do the deamon-reload, systemctl don't allow me to ignore it. But I can indeed see the implication that it could make by making the install do it. Maybe it is best to do nothing further.

Bevan commented on 2014-01-15 20:03 (UTC)

@nickoe: Rebuilding the package is necessary after some but not all minor kernel updates. The last two kernel updates it was unfortunately nescessary. Regarding the service file: systemd detects that the service file was overwritten. If you just rebuild/reinstall the package you can safely ignore this because the file was overwritten with exactly the same content it had before. If you upgrade this package it might be that the content of the file changes (this was the case when we introduced encryption by default in this package). So I would recommend to do a daemon-reload after an upgrade. But if it is really necessary I will inform about this during upgrade. Reloading in the post install script would make this message disappear but I think this is not something people expect (and it could cause harm if people are working on service files in that moment or something fails during reload), so I won't include that.

nickoe commented on 2014-01-15 19:44 (UTC)

Every time I upgrade kernel I need to recompile openfs, that is fine. I rebuild and try to start the service but always get the error from systemctl. Warning: Unit file of openafs-client.service changed on disk, 'systemctl daemon-reload' recommended. But is it possible to to make the openafs.install file do this reloading, or is this against some pkgbuild guidelines?

Eothred commented on 2014-01-07 14:12 (UTC)

Wow, thanks for getting all this information for me! I understood that it was probably this strict_type thing, but I did not succeed to find/create the patch needed. I will try again, and sorry for the noise!

Bevan commented on 2014-01-07 14:03 (UTC)

@Eothred: The module compiles fine on 3.12.6 on Arch. The problem seems to be the kernel setting CONFIG_UIDGID_STRICT_TYPE_CHECKS. It is set on Chakra[1] but not on Arch[2]. You could try compiling your own kernel without that option or you can use a 1.6.6 prerelease of openafs that should fix the issue[3]. [1]: [2]: [3]:

Eothred commented on 2014-01-07 13:14 (UTC)

This package compiles fine for you with Linux 3.12.6? I maintain a similar package for Chakra GNU/Linux (also uses pacman/makepkg for the moment), and for me it fails with errors of the kind: error: incompatible types when assigning to type ‘kgid_t’ from type ‘gid_t’ That is, the 'make' command finishes (so exit value 0 I suppose, not very nice), but the installation target fails because it cannot find openafs.ko.

alexpe87 commented on 2013-12-19 10:17 (UTC)

That would be indeed very good!

cptiglo commented on 2013-11-28 19:17 (UTC)

Will openafs anytime soon migrate to the [community] repository?

Bevan commented on 2013-09-03 20:34 (UTC)

@totsilence: Yeah, these two are the right ones. I hoped that ver. 1.6.6 would be released before linux 3.11 hits our testing repo. I think I will release a new pkgrel in a moment.

totsilence commented on 2013-09-03 19:19 (UTC)

Hey Bevan, business as usual: openafs needs patching with Linux 3.11 I found the following two patches:,10118 (already reviewed and merged),10219 (not yet merged) I don't know if there are more, I'm not good at searching gerrit :) Cheers Bastian

nickoe commented on 2013-07-31 12:50 (UTC)

I think it was the appdefaults I added to /etc/krb5.conf to make it aklog automatically upon gaining a krb ticket. [appdefaults] program = /usr/bin/aklog

nickoe commented on 2013-07-31 12:48 (UTC)

@Bevan, Yes, indeed, I can use aklog, but before, it was possbile to _just_ kinint and then I also gained an afs token. I have put something in some krb conf somewhere, I will see if I am able to find it.

Bevan commented on 2013-07-31 12:28 (UTC)

@nickoe: You really should not need heimdal at all. kinit only gets a Kerberos ticket, not an AFS token. You should be able to run "aklog" afterwards to get a token using your Kerberos ticket. "klog" should not be necessary. If aklog does not work, try "aklog -d" to get debugging information. You can also use third party apps like krb5-auth-dialog to get you an AFS token automatically.

Bevan commented on 2013-07-30 08:25 (UTC)

@nickoe: The disagreement of the first two commands could be the result of the failed attempts to start the afs client. Maybe it is trapped in some ugly state now... But I think a few lines later we see the root of the problem: [root@t410-arch nickoe]# fs setcrypt on fs: error while loading shared libraries: cannot open shared object file: No such file or directory The inclusion of this line in the service file was the only change between 1.6.5-1 and 1.6.5-2. So you should be able to work around this problem by removing the line "ExecStartPost=/usr/bin/fs setcrypt on" in /usr/lib/systemd/system/openafs-client.service. Maybe you need another reboot to resolve the obscure state of /afs. Note that this file will be overwritten when reinstalling/updating openafs. You can copy it to /etc/systemd/systemd to be persistent but I do not recommend to use it for a long time. But this is only a workaround to get openafs running again. We should find out why fs is linked against a non-existing The package krb5 ships, so that's what fs should use. I remember that you once had heimdal-aur installed. I'm wondering if there is some old library lying around... Could you please run the following commands? pacman -Qs heimdal locate (or if this does not work: find -L /lib* -name

totsilence commented on 2013-07-29 12:09 (UTC)

Get nickoe, try with openafs-client.service :) Cheers Bastian

Bevan commented on 2013-07-28 10:54 (UTC)

It is an error in documentation. Default ist encryption enabled on windows, disabled on all other systems. See: (fix for manpage) Until the solution of the last link is implemented upstream, I suggest just keeping encryption enabled by default on Arch. It doesn't make much sense to me to use a world wide filesystem without data encryption.

cptiglo commented on 2013-07-26 14:49 (UTC)

@Bevan: Thanks. I'm curious what the openafs-developers will say. - Maybe you could keep us updated ...

Bevan commented on 2013-07-26 12:42 (UTC)

@simmel: Exactly what I thought but in fact it seems to be disabled by default. Try running "fs getcrypt". For me it shows "clear", so no encryption is used. For me this seems to be a bug either in OpenAFS or the man page. I will post to the mailing list and ask what the proposed behaviour is. All the other init scripts seem to set this flag, so it makes sense to add it to the service file, too. I will upload a new pkgrel in a second...

cptiglo commented on 2013-07-26 12:33 (UTC)

I would suggest to add the line ExecStartPost=/usr/bin/fs setcrypt on to the systemd-service-file openafs-client.service to have data-encryption enabled by default.

commented on 2013-07-26 12:33 (UTC)

$ man fs_setcrypt [...] The default encryption status is enabled. [...] So no need.

Bevan commented on 2013-07-14 19:51 (UTC)

@grawity: Good catch. You may be the first person ever using the server on Arch ;-) I sent this upstream, so lets see what the developers think about it:,10087 Until then you can just add "-nofork" to BOSSERVER_ARGS in /etc/conf.d/openafs. And please report if you experience any other issues with the server part.

grawity commented on 2013-07-13 16:07 (UTC)

openafs-server.service should be using 'bosserver -nofork', otherwise it thinks bosserver died when it forks/exits.

Bevan commented on 2013-06-04 11:02 (UTC)

Yep, you're absolutely right. I hope I can fix this in the next 12 hours.

totsilence commented on 2013-06-04 08:33 (UTC)

The adjust-configs.patch should also be fixed, to point everything to /usr/bin :)

drslmr commented on 2013-06-04 06:42 (UTC)

In order to be compliant with the new filesystem package I added "--sbindir=/usr/bin" in PKGBUILD of my copy.

kaspi commented on 2013-05-02 12:39 (UTC)

@Bevan: Many thanks for your quick reply! And I can confirm that the patch you pointed out solved the problem :-)

Bevan commented on 2013-05-02 11:30 (UTC)

@ kaspi: Every new major kernel release brings some fun using openafs... :) I will have a look at it as soon as possible and add the necessary patches. The appropriate change to fix your problem seems to be this:,9639

kaspi commented on 2013-05-02 10:49 (UTC)

It seems that the module doesn't compile against the new kernel 3.9.0-2-ARCH: ... CC [M] /home/jkaspar/install/openafs/src/openafs- /home/jkaspar/install/openafs/src/openafs- In function ‘canonical_dentry’: /home/jkaspar/install/openafs/src/openafs- error: macro "hlist_for_each_entry" passed 4 arguments, but takes just 3 hlist_for_each_entry(cur, p, &ip->i_dentry, d_alias) { ^ /home/jkaspar/install/openafs/src/openafs- error: ‘hlist_for_each_entry’ undeclared (first use in this function) hlist_for_each_entry(cur, p, &ip->i_dentry, d_alias) { ^ /home/jkaspar/install/openafs/src/openafs- note: each undeclared identifier is reported only once for each function it appears in /home/jkaspar/install/openafs/src/openafs- error: expected ‘;’ before ‘{’ token hlist_for_each_entry(cur, p, &ip->i_dentry, d_alias) { ... ^ make[6]: *** [/home/jkaspar/install/openafs/src/openafs-] Error 1

Bevan commented on 2013-03-04 22:32 (UTC)

I will upload 1.6.2 stable in a second. Please make sure to stop the openafs-client before applying the update. This is important because the kernel module was renamed and with the new service file you won't be able to stop the client correctly. If you need to stop the old client manually after applying the update, do the following: umount /afs afsd -shutdown rmmod libafs

Stebalien commented on 2013-02-24 08:57 (UTC)

@Bevan: works for me.

Bevan commented on 2013-02-21 18:21 (UTC)

Here is an untested version of 1.6.1 that should build with linux 3.8: I can't test it at the moment so I won't add it to AUR until someone tested it.

totsilence commented on 2013-02-21 18:09 (UTC)

Thank you! You're really doing a good job of finding these patches, I always google for them in case I encounter problems with a new linux release, but can't seem to find them. It's working for me now (I also had to uncomment the ./ line in the PKGBUILD to pick up some of the changes from the patch set.) Looking forward to your new package. Thanks for the good work!

Bevan commented on 2013-02-21 17:48 (UTC)

@totsilence: Yes for linux 3.8 there are some new patches needed. I hoped that they would release 1.6.2 before linux 3.8 hits testing. I will include these patches later today or tomorrow. If you need a running AFS now and want to try it on your own, this should be what you need:,8941,8942,8948

totsilence commented on 2013-02-21 14:09 (UTC)

Hey, now that linux 3.8 is in testing I have another build problem (this is with the 1.6.2pre3 PKGBUILD posted below). Error messages are: In file included from ~/abs/aur/openafs/src/openafs-1.6.2pre3/src/libafs/MODLOAD-3.8.0-1-ARCH-SP/rx_pag_knet.c:27:0: ~/abs/aur/openafs/src/openafs-1.6.2pre3/src/afs/LINUX/osi_compat.h: In function ‘afs_linux_search_keyring’: ~/abs/aur/openafs/src/openafs-1.6.2pre3/src/afs/LINUX/osi_compat.h:194:13: error: ‘afs_ucred_t’ has no member named ‘tgcred’ ~/abs/aur/openafs/src/openafs-1.6.2pre3/src/afs/LINUX/osi_compat.h:196:26: error: ‘afs_ucred_t’ has no member named ‘tgcred’

Bevan commented on 2013-01-31 23:48 (UTC)

I set up a new public git repo on bitbucket containing this package: I translated the commit messages into english - that's why all commits are from today... ;)

Bevan commented on 2013-01-31 15:47 (UTC)

@simmel: Thanks for testing. I think 1.6.2 final will come soon. At the moment this package is kept in a private git repo at bitbucket. I think there is no reason to keep this private, so I'll publish it (after looking through the history ;)) and post the link here.

commented on 2013-01-31 15:41 (UTC)

The latest version you posted works for me Bevan. Is it possible to setup (or make your repo public) a git(or any other VCS)-repo with the current package in it? So others can contribute and see what has changed (and possibly what's on the TODO).

Bevan commented on 2013-01-12 00:45 (UTC)

1.6.2 pre3:

Bevan commented on 2012-12-25 22:18 (UTC)

For those, who want to test, ver. 1.6.2 prerelease 2:

Bevan commented on 2012-12-14 09:40 (UTC)

I also found out what causes the problems with autodetection of the linux headers path: configure is looking for the file include/linux/version.h in the headers path. With kernel 3.7 this file seems to have vanished. I will work around this in the PKGBUILD and file a bug report.

Bevan commented on 2012-12-13 22:35 (UTC)

@kaspi and @totsilence: I've found the missing patches. Basically it is this one: I will include this and another one based on this in ver. 1.6.1-13 (probably tomorrow) so it should build with Linux 3.7. But you are also fine using 1.6.2pre1 :) Thanks again for your comments.

kaspi commented on 2012-12-13 18:39 (UTC)

I've got a similar problem as totsilence. At kernel 3.7.0-1-ARCH, openafs 1.6.1-12, I needed to supply --with-linux-kernel-headers=/usr/src/linux-$(uname -r) for configure. Then trying to run it, there is an error and dmesg gives: libafs: Unknown symbol kernel_thread (err 0).

drslmr commented on 2012-12-13 15:47 (UTC)

1.6.2pre1 works for me on kernel 3.6.9-1-ARCH

totsilence commented on 2012-12-13 14:07 (UTC)

Thanks for the 1.6.2pre1 package. That one works, but I still had to add the --with-linux-kernel-headers=/usr/src/linux-$(uname -r) configure parameter. And yes, before I had tried openafs-1.6.1-12 after a fresh reboot.

Bevan commented on 2012-12-13 11:55 (UTC)

@totsilence: Thanks for your comment. Maybe I missed one of the necessary patches for linux 3.7. Just to make some things clear: - You tried ver. 1.6.1-12? In 1.6.1-11 some patches for linux 3.7 were missing. - Did you reboot before rebuilding openafs? If $(uname -r) still said 3.6-... the module would have been built for the wrong kernel. Could you please try ver 1.6.2pre1 which you can find in my last comment and post here if this works for you?

totsilence commented on 2012-12-13 10:48 (UTC)

Your latest version only compiles for me with linux 3.7 from testing when I add --with-linux-kernel-headers=/usr/src/linux-$(uname -r) to the configure flags. Then the package is created correctly, but I can't load the libafs module: sudo modprobe libafs modprobe: ERROR: could not insert 'libafs': Unknown symbol in module, or unknown parameter (see dmesg) dmesg [3448.743262] libafs: Unknown symbol kernel_thread (err 0) Any idea?

Bevan commented on 2012-12-12 21:55 (UTC)

If anyone is interested in testing the upcoming version 1.6.2 of openafs: I made a source package of the 1st prerelease, which is available here:

nickoe commented on 2012-11-18 15:14 (UTC)

Hmm, interresting, but yes I indeeed had. But thank you. It works now. :O

Bevan commented on 2012-11-18 14:32 (UTC)

@nickoe: You already had exactly the same problem in April this year.. :-D

jpate commented on 2012-11-18 14:11 (UTC)

@nickoe why do you still have heimdal installed? krb5 replaced it a year and a half ago according to my pacman.log. this packge builds fine with krb5

theodore commented on 2012-10-26 07:48 (UTC)

@Bevan thanks for the responce ;-)

Bevan commented on 2012-10-26 07:12 (UTC)

@theodore: The answer is: it depends Definitely you have to recompile the package after a major kernel update (e.g. 3.5 -> 3.6). Unfortunately you have to do it also after SOME minor updates (e.g. 3.6.2 -> 3.6.3). We place the module in /usr/lib/modules/extramodules... to allow reusing it after minor kernel updates but if loading the modules fails with the new kernel you have to recompile it.

theodore commented on 2012-10-26 07:00 (UTC)

one question, do we still need to recompile the package after each new kernel update? p.s. i am using systemd and openafs-client.service

kaspi commented on 2012-10-25 04:16 (UTC)

@ Bevan Thanks for your reply anyway!

Bevan commented on 2012-10-23 16:52 (UTC)

To be honest I have no clue what's going wrong there. systemd should do exactly what you have tried. You could check that you don't still have openafs-client listed in the DAEMONS array in /etc/rc.conf but this shouldn't make any difference at all when initscripts is not installed... What does "systemctl status openafs-client.service" say after starting the service has failed?

kaspi commented on 2012-10-23 09:15 (UTC)

> Please also try to run the commands of the service file manually to see what happens (make sure, afsd is not running before!): > /sbin/modprobe libafs > /usr/sbin/afsd -dynroot -fakestat -afsdb Yes, this works (using the same parameters as below). > Could you please post the content of your /etc/conf.d/openafs here? I'm using one of the presets used on the computers maintained by my laboratory: LARGE="-fakestat -stat 2800 -dcache 2400 -daemons 5 -volumes 128" export AFSD_ARGS="$LARGE" > And a last question: Do you have the initscripts package installed? No. Thanks for your help, Kašpi.

Bevan commented on 2012-10-21 20:45 (UTC)

@kaspi: Sorry for the late response. I'm using the systemd service file myself and it works for me. Could you please post the content of your /etc/conf.d/openafs here? Please also try to run the commands of the service file manually to see what happens (make sure, afsd is not running before!): /sbin/modprobe libafs /usr/sbin/afsd -dynroot -fakestat -afsdb And a last question: Do you have the initscripts package installed?

kaspi commented on 2012-10-15 09:11 (UTC)

Hi all, is someone actually using the systemd service file? For me it seems to fail. Starting the service sudo systemctl start openafs-client issues no error message, but AFS is clearly not up. Inspecting the journal sudo journalctl gives this: Oct 15 10:33:07 myhostname systemd[1]: Starting OpenAFS Client Service... Oct 15 10:33:07 myhostname kernel: libafs: module license '' taints kernel. Oct 15 10:33:07 myhostname kernel: Disabling lock debugging due to kernel taint Oct 15 10:33:07 myhostname kernel: Key type afs_pag registered Oct 15 10:33:07 myhostname kernel: enabling dynamically allocated vcaches Oct 15 10:33:08 myhostname kernel: Starting AFS cache scan...found 1272 non-empty cache files (17%). Oct 15 10:33:08 myhostname afsd[1661]: afsd: All AFS daemons started. Oct 15 10:33:08 myhostname afsd[1661]: afsd: All AFS daemons started. Oct 15 10:33:08 myhostname udisks-daemon[572]: **** /proc/self/mountinfo changed Oct 15 10:33:08 myhostname udisks-daemon[572]: **** /proc/self/mountinfo changed Oct 15 10:33:08 myhostname kernel: afs: WARM shutting down of: vcaches... CB... afs... BkG... CTrunc... AFSDB... RxEvent... UnmaskRxkSignals. Oct 15 10:33:08 myhostname afsd[1694]: afsd: Shutting down all afs processes and afs state Oct 15 10:33:08 myhostname kernel: AFS not initialized - not shutting down Oct 15 10:33:08 myhostname kernel: Key type afs_pag unregistered Oct 15 10:33:08 myhostname systemd[1]: Started OpenAFS Client Service. Any ideas? Thanks in advance, Kašpi.

totsilence commented on 2012-10-03 16:39 (UTC)

Works! Thanks for the really fast response Bevan! Great work. Yeah, let's hope they release 1.6.2 soon.

Bevan commented on 2012-10-03 09:09 (UTC)

@totsilence: Could you please test the new version with linux 3.6 and report your results here?

Bevan commented on 2012-10-02 16:47 (UTC)

@totsilence: Thanks for your work. I will include those patches in the next package version. I really hope for a soon 1.6.2 release so that we don't have to maintain so much patches here...

totsilence commented on 2012-10-02 16:41 (UTC),status:merged+project:openafs+branch:openafs-stable-1_6_x+topic:linux_36,n,z should contain the necessary changes...

totsilence commented on 2012-10-02 16:35 (UTC)

Hey, the package doesn't compile with linux 3.6. It needs a patch / new upstream release. Did anybody look into this? I'm trying to patch now and will share my results in case I suceed

commented on 2012-09-20 20:20 (UTC)

works for me! Thanks!

Bevan commented on 2012-08-14 15:27 (UTC)

There are some bigger changes in ver. 1.6.1-8. After installation you will get a list of them. One benefit for those already using systemd: the package now includes service files for openafs-client and openafs-server. If you have any problems with the new version please tell them here.

Bevan commented on 2012-07-25 17:43 (UTC)

@kaspi: Thanks for telling me. I included the patch in the newest package version.

kaspi commented on 2012-07-25 12:52 (UTC)

@Bevan: Thanks for a quick and helpful reply! It seems that my AFS client is running well with only the first patch.

Bevan commented on 2012-07-24 11:57 (UTC)

@kaspi: There were some changes in the kernel so that openafs needs to be patched to run with kernel 3.5. I will include those as soon as I have some time for testing. Your problem should be solved by this change:,7578 Two other recently added changes are the following (may be needed, too):,7577,7579

kaspi commented on 2012-07-24 11:38 (UTC)

Hello, it seems there is a problem under the kernel 3.5.0: In file included from /home/jkaspar/install/openafs/src/openafs-1.6.1/src/libafs/MODLOAD-3.5.0-1-ARCH-MP/osi_vfsops.c:25:0: /home/jkaspar/install/openafs/src/openafs-1.6.1/src/afs/LINUX/osi_compat.h: In function ‘afs_get_fh_from_dentry’: /home/jkaspar/install/openafs/src/openafs-1.6.1/src/afs/LINUX/osi_compat.h:336:9: warning: passing argument 1 of ‘dp->d_sb->s_export_op->encode_fh’ from incompatible pointer type [enabled by default] /home/jkaspar/install/openafs/src/openafs-1.6.1/src/afs/LINUX/osi_compat.h:336:9: note: expected ‘struct inode *’ but argument is of type ‘struct dentry *’ /home/jkaspar/install/openafs/src/openafs-1.6.1/src/libafs/MODLOAD-3.5.0-1-ARCH-MP/osi_vfsops.c: In function ‘afs_evict_inode’: /home/jkaspar/install/openafs/src/openafs-1.6.1/src/libafs/MODLOAD-3.5.0-1-ARCH-MP/osi_vfsops.c:287:5: error: implicit declaration of function ‘end_writeback’ [-Werror=implicit-function-declaration] Any suggestions? Thanks, Kaspi.

Bevan commented on 2012-07-15 10:05 (UTC)

The latest available updates in the Arch repos require some manual intervention (also see 1. Remove openafs from your system (your configuration unter /etc/openafs will be backed up) 2. Update your system as described in the news bulletin: pacman -Syu --ignore glibc && pacman -Su 3. Reboot your system to get the new kernel running 4. Build and install openafs again (important: use package version 1.6.1-6) 5. Restore your configuration under /etc/openafs 6. Start openafs by running "rc.d start openafs"

Bevan commented on 2012-07-11 16:43 (UTC)

@drslmr: I can reproduce your problem. It seems that there is an include of sys/resource.h missing. In this header PRIO_PROCESS gets declared. I added a patch to solve this issue in pkgver. 1.6.1-5 @honza801: I also added autoconf in this release.

drslmr commented on 2012-07-11 11:45 (UTC)

Hi, Iget the following error: ./afsd_kernel.c: In function ‘afsd_set_rx_rtpri’: ./afsd_kernel.c:140:5: error: ‘PRIO_PROCESS’ undeclared (first use in this function) ./afsd_kernel.c:140:5: note: each undeclared identifier is reported only once for each function it appears in For curiosity introducing #define PRIO_PROCESS 0 into afsd/afsd_kernel.c prevents the error.

honza801 commented on 2012-07-03 11:42 (UTC)

please add 'autoconf' to makedepends

Bevan commented on 2012-06-16 09:51 (UTC)

@subnex: added. Thanks for the hint.

subnex commented on 2012-06-05 08:43 (UTC)

automake has to be added to makedepends

Bevan commented on 2012-06-03 17:52 (UTC)

@totsilence: Very good idea to get this working with systemd :) I didn't write any systemd service files yet but I think we can't transfer the logic of openafs.rc into that service file. Instead we may need to change our configuration to something like AFSD_ARGS="-afsdb -dynroot -fakestat" so that we can use that file as EnvironmentFile. That's what RedHat does if I am correct. Would be glad to hear from others about that.

totsilence commented on 2012-06-03 15:49 (UTC)

Did anyone try to add a systemd service file for openafs? In the source tree there is the RedHat one, but it has to be modified. I wrote my own but I can't seem to properly parse the configuration files in /etc for the arguments of the afsd daemon...

nickoe commented on 2012-04-13 19:49 (UTC)

I removed heimdal-aur, and compiled the original PKGBUILD and it did build.

Bevan commented on 2012-04-13 19:47 (UTC)

That's not really an improvement :-/ heimdal-aur is asking the user to run a shell script that changes environment variables. I assume that you did that. Please try to revert these changes before building openafs. If that doesn't help I really would suggest removing heimdal-aur. The standard krb5 should do the job for you.

nickoe commented on 2012-04-13 19:33 (UTC)

Bevan: I now got this error:

Bevan commented on 2012-04-13 18:40 (UTC)

@nickoe: Please try the following PKGBUILD: The only additional change is the export line in build(). If this does not work I would suggest removing heimdal-aur and using the default kerberos implementation. In general those two should be compatible. I have used both MIT kerberos and heimdal and for me it made no difference. Good luck :)

nickoe commented on 2012-04-13 18:22 (UTC)

Becan: I tried to add the paramaters to the ./configure command, and it did not fix it. Here is the full build log: It will be up for a month.

nickoe commented on 2012-04-12 21:38 (UTC)

Bevan: yes I got aur-heimdal istalled. The admin at my place suggests to use heimdal to use the kinit and afslog programs. I will try to build tomorrow.

Bevan commented on 2012-04-12 16:09 (UTC)

I just see that there is already a bug report: So as soon as this gets fixed it should be possible again to link aklog against heimdal.

Bevan commented on 2012-04-12 15:57 (UTC)

@nickoe: One thing I see in your log is that aklog seems to be linked against heimdal (-I/usr/heimdal/include). aklog.c contains a reference to krb5_524_conv_principal which is not provided by heimdal anymore. See this mailing list entry: In Arch Linux heimdal was replaced by MIT kerberos some time ago. Do you have the package heimdal-aur installed? You should be able to compile openafs anyway by replacing ./configure --prefix=/usr --sysconfdir=/etc with ./configure --prefix=/usr --sysconfdir=/etc --with-krb5-include=/usr/include/krb5 --with-krb5-lib=/usr/lib/krb5 in the PKGBUILD. This is completely untestet because I haven't got heimdal-aur installed. Please report if this works for you. I would then consider adding it to the PKGBUILD in AUR.

nickoe commented on 2012-04-11 21:01 (UTC)

I can't compile it. I get the following error (sorry for the danish language, I may post the english version if you cannot understand it): -I/usr/heimdal/include -I/usr/include -DALLOW_REGISTER -c linked_list.c gcc -o aklog -O -I/tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/src/config -I/tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/include -I. -I. -D_LARGEFILE64_SOURCE -I/usr/heimdal/include -I/usr/include -DALLOW_REGISTER aklog.o aklog_roken.o krb_util.o linked_list.o -L/usr/heimdal/lib -lkrb5 -lhx509 -lcom_err -L/usr/lib -lcrypto -lasn1 -lwind -lheimbase -lroken -lcrypt -pthread -ldl -lresolv -pthread /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/libprot.a /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/libauth.a /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/libubik.a /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/librxkad.a /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/libsys.a /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/librx.a /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/libsys.a /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/liblwp.a /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/libdes.a /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/libafscom_err.a /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/libcmd.a /tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/lib/libafsutil.a -lresolv aklog.o: In function `rxkad_build_native_token': aklog.c:(.text+0xe71): undefined reference to `krb5_524_conv_principal' collect2: fejl: ld returnerede afslutningskoden 1 make[3]: *** [aklog] Fejl 1 make[3]: Forlader katalog '/tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4/src/aklog' make[2]: *** [aklog] Fejl 2 make[2]: Forlader katalog '/tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4' make[1]: *** [build] Fejl 2 make[1]: Forlader katalog '/tmp/yaourt-tmp-nickoe/aur-openafs/src/openafs-1.6.1pre4' make: *** [all] Fejl 2

Bevan commented on 2012-03-30 16:09 (UTC)

@bins: Both cacheinfo and ThisCell are marked as config files, so they won't be overwritten when you install a new version of this package. So you can just install the package as it is and then (only after first installation) edit the files directly under /etc/openafs. There is no need to change the files in the package. See for a detailed overview how pacman handles config files. I hope this is an acceptable answer to your comment. Otherwise please complain :)

bins commented on 2012-03-30 08:14 (UTC)

well, as cacheinfo and ThisCell are tracked by pacman, their checksum won't match if one edits them on the fly... it was a rather convenient way to customize things on the fly with 'yaourt'

Bevan commented on 2012-03-29 18:46 (UTC)

I cleaned up the PKGBUILD a lot. Please report if you have any problems with it.

commented on 2012-03-05 21:03 (UTC)

@Bevan "yaourt -S openafs" worked like a charm. Thanks for the tip and thanks again for the fast support :)

Bevan commented on 2012-03-05 20:14 (UTC)

You have to rebuild the package using makepkg again. Reinstalling the old package won't help. Or if you use yaourt, do a "yaourt -S openafs" again.

commented on 2012-03-05 19:24 (UTC)

@nickoe, I had, it's after one or two reboots i actually noticed. @Bevan, recompiling = just reinstalling the package ? Just wondering, i'm not so familiar with Linux environnment. Thanks for the fast answers =)

Bevan commented on 2012-03-05 18:56 (UTC)

It seems to be necessary to recompile openafs after the latest kernel update. In most cases a module can be used in different minor kernel versions but this time it doesn't.

nickoe commented on 2012-03-05 18:47 (UTC)

@EvilSakray have you rebooted?

commented on 2012-03-05 18:38 (UTC)

I'm sorry bothering here again.. ever since last kernel update (i updated this week-end) i noticed openafs wouldn't connect anymore. (I had the same error as before), i decided to check it was started running it manually and got the following error: [login@EvilSakray ~]$ sudo rc.d start openafs :: Starting OpenAFS with -afsdb -dynroot -fakestat ERROR: could not insert 'libafs': Exec format error Any idea ? Thanks =)

commented on 2012-02-07 22:15 (UTC)

@Bevan: Thanks, it was the problem, sudo /etc/rc.d/openafs start solved it =)

Bevan commented on 2012-02-07 17:44 (UTC)

@EvilSakray: Are you sure the openafs daemon is running and the kernel module is loaded? After installation it has to be started by "rc.d start openafs". If this doesn't help please try "aklog -d" and post the output here.

commented on 2012-02-07 15:34 (UTC)

I installed latest openafs pre-release since i'm under Linux 3.2 however, I get the following error running aklog: aklog: a pioctl failed while obtaining tokens for cell Any help on this ? (kinit works fine)

theodore commented on 2012-01-19 00:31 (UTC)

@Bevan thanks for the update ;) keep up the good work

Bevan commented on 2012-01-19 00:22 (UTC)

@theodore: Thanks for remarking this problem. I updated the package to version 1.6.1pre1 as this fixes compatibility problems with Linux 3.2. With this version we also get rid of the linux-3.1 patch and we benefit of some important fixes to the AFS fileserver. In general I will try to stick to the latest stable version but it seems that we have to use prereleases sometimes.

theodore commented on 2012-01-18 23:50 (UTC)

new kernel in the repositories new problems :( during the build it exits with error without any specific information i tried to disable also the kernel patch for the previous kernel but it didn't work either... any idea?

theodore commented on 2012-01-14 20:42 (UTC)

indeed i can confirm that problem fixed.....;) thanks @Bevan

Bevan commented on 2012-01-14 11:39 (UTC)

Problem should be fixed in linux-3.1.9-2 and linux-headers-3.1.9-2. Until it is in the repositories you can get it here:

Bevan commented on 2012-01-13 22:13 (UTC)

Btw: The error message during configure is the following: FATAL: vmlinux is truncated. sechdrs[i].sh_offset=18446744071588955904 > sizeof(*hrd)=64 If you need to build the module now you could try downgrading to linux-3.1.8 and linux-headers-3.1.8, install openafs and update the kernel again. The module will work with the upgraded kernel.

Bevan commented on 2012-01-13 22:03 (UTC)

I could reproduce the problem. It seems to be related to this bug in libarchive: It is fixed in libarchive-3.0.3 which is in testing at the moment. But you can't just upgrade to that version because other software (like pacman) is linked to libarchive-2 and will be broken. Also it is not possible to apply the patch to libarchive-2. So I don't really have a solution to this problem at the moment :( But it also affects other modules that can't be built at the moment, so I hope it get fixed soon.

theodore commented on 2012-01-13 21:19 (UTC)

yeap i rebooted before starting compiling and then i came out with that problem... :( "uname -r" shows 3.1.9-1-ARCH

Bevan commented on 2012-01-13 21:08 (UTC)

@theodore: I will test compiling the kernel module soon and if necessary I will look for a fix. Just to be sure: Did you reboot your machine after updating the kernel? So does "uname -r" show version 3.1.9 already? The thing here is that the running kernel and the installed kernel headers have to be the same version.

theodore commented on 2012-01-13 21:00 (UTC)

checking if linux kbuild requires EXTRA_CFLAGS... yes checking for linux kernel module build works... no configure: error: in `/home/theodore/Desktop/openafs/src/openafs-1.6.0': configure: error: Fix problem or use --disable-kernel-module... See `config.log' for more details ==> ERROR: A failure occurred in build(). Aborting... after the last update of the kernel when i tried to recompile the package i took this error. Any idea? what is wrong with the kernel module? should i disable it from the PKGBUILD?

nickoe commented on 2011-12-28 19:08 (UTC)

@Bevan: That was definetly the case. I rebooted and tried to compaile again -- with success. :D Thank you.

Bevan commented on 2011-12-28 18:44 (UTC)

@nickoe: I guess that you have installed linux-headers 3.1.5-1 but you are still running Linux kernel 3.1.4 (maybe not yet rebooted after the latest kernel update?)

nickoe commented on 2011-12-28 18:17 (UTC)

I can not compile this version (1.6.0-2), I get the following error (I compile through yaourt): ... checking whether printf understands the %z length modifier... yes checking your OS... configure: WARNING: No usable linux headers found at /usr/src/linux so disabling kernel module linux checking your AFS sysname... configure: error: Couldn't guess your Linux version. Please use the --with-afs-sysname option to configure an AFS sysname. ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build openafs. I am on the following kernel: $ uname -srvm Linux 3.1.4-1-ARCH #1 SMP PREEMPT Tue Nov 29 08:55:45 CET 2011 x86_64

szym commented on 2011-12-05 20:50 (UTC)

Package needs new maintainer. (I no longer actively use AFS.)

Bevan commented on 2011-12-05 13:11 (UTC)

I changed PKGBUILD and openafs.install a bit. Maybe you want to use it here: PKGBUILD: openafs.install: kernel-3.1.patch: Changes: - Remove note in openafs.install on ReiserFS - Change modules directory from /lib/modules/VERSION/fs to /lib/modules/extramodules-VERSION-ARCH (untested, we will see how it behaves after next kernel update) - Add patch to fix problems with Linux 3.1 (should be removed when a new version of openafs is available)

Eothred commented on 2011-12-04 11:58 (UTC)

@Bevan Thanks for the reply. I haven't understood how it works myself, I just realised it would be nice to have the functionality for this module as well if possible.

Bevan commented on 2011-12-02 17:24 (UTC)

@Eothred: If I'm correct virtualbox modules are now provided in binary form by an own package. This just places the modules under /lib/modules/extramodules-3.x-ARCH instead of /lib/modules/3.x.x-x-ARCH. Therefore they don't need to be replaced when a new minor version of the kernel is installed (e.g. 3.1.3 -> 3.1.4). By the way: the proprietary nvidia drivers are handled the same. I think this should be possible for the afs module, too.

Eothred commented on 2011-12-02 11:05 (UTC)

@jpate Perhaps because you need the patch for it to work? I'm not sure. I have noticed that virtualbox now recompiles when a new kernel is installed, upon next reboot (right?). Could something similar perhaps be done for this package?

jpate commented on 2011-12-01 23:01 (UTC)

why has this been flagged out of date? indicates this is the latest stable release.

drslmr commented on 2011-11-17 09:25 (UTC)

Hi Bevan, thanks for this great hint. I pathced the diff into my local installation. And up to now it seams to work.

Bevan commented on 2011-11-11 21:48 (UTC)

I'm getting frequent system freezes with kernel 3.1. The reason (and a possible fix) can be found here:,5945

Bevan commented on 2011-10-08 12:26 (UTC)

FYI: openAFS 1.6 used with a kernel >= 2.6.25 allows it to use any filesystem you want for the cache. So the note in openafs.install on ReiserFS is obsolete. You can even use tmpfs to store the cache data in RAM.

ataraxia commented on 2011-09-02 13:41 (UTC)

1.6.0 final release is out.

pnutzh4x0r commented on 2011-08-07 21:45 (UTC)

Changing kernel26-headers to linux-headers for the new linux package (linux-3.0.1-1) appears to work.

commented on 2011-06-11 10:25 (UTC)

update pkgbuild to 1.6.0pre6 to make it work with kernel 2.6.39

Bevan commented on 2011-06-11 10:25 (UTC)

Prerelease 6 is available. This commit message could mean that the problem with BKL is solved in that version:

szym commented on 2011-05-12 03:41 (UTC)

updated to 1.6.0pre4 since the new kernel is in core

szym commented on 2011-04-14 19:52 (UTC)

Bummer, no workaround for the 2.6.38 problem. Move to openafs1.6 if you really need it (I know I do).

Eothred commented on 2011-04-14 11:30 (UTC)

@kaspi Thanks for the info. Just tried myself also, I don't see any problems from initial startup at least. I'll ask the IT helpdesk at work about their recommendation just in case there are some known issues.

kaspi commented on 2011-04-14 10:50 (UTC)

@Eothred: I've just compiled the `openafs1.6 1.6.0pre4-1' package, it went smooth and seems working.

Eothred commented on 2011-04-14 10:04 (UTC)

Doh! I need it for work. Would it be complicated for me to use the 1.6 pre? Is it trustworthy enough? Stability, speed? I recommend to add dependency kernel26-headers<2.6.38 then for the time being szym..

commented on 2011-04-02 17:55 (UTC)

It doesn´t works with the kernel 2.6.38:

realturner commented on 2011-03-20 11:46 (UTC)

@Eothred: I guess you should add a "-j1" flag after `make' command.

Eothred commented on 2011-01-18 07:38 (UTC)

I have problems compiling the latest version: This is on a i386 machine. Let me know if I can provide further aid.

nickoe commented on 2010-12-03 12:49 (UTC)

Thank you

szym commented on 2010-12-02 22:02 (UTC)

Thanks go to iamcraig and Eothred.

Eothred commented on 2010-12-02 13:53 (UTC)

@nickoe I already sent my suggestion to the maintainer by e-mail some days ago. I placed it in my dropbox public here for the time being: You obviously then decide to trust me if you use it...

nickoe commented on 2010-12-02 08:37 (UTC)

Does anyone want to update the PKGBUILD? I am not familiar with patching stuff, and I am very busy with school stuff. Sincerely nickoe

Bevan commented on 2010-11-29 23:24 (UTC)

I can confirm the problem and for me the patch worked, too (without patching files in /doc).

commented on 2010-11-27 11:19 (UTC)

After upgrading to kernel26, rebuilding openafs failed with "error: implicit declaration of function ‘inode_setattr’". This appears similar to the Gentoo bug reported at Using the patch attached to that thread (with some modification for missing and existing files) appears to have fixed the problem for now.

Bevan commented on 2010-06-29 06:35 (UTC)

After building the package yaourt complains of a reference to $srcdir in the package. Is this expected behaviour?

chneukirchen commented on 2010-06-27 17:08 (UTC)


szym commented on 2010-05-18 19:49 (UTC)

1.4.12-2 replaces invalidate_inode_pages (absent from 2.6.34) with invalidate_mapping_pages

commented on 2010-05-08 17:51 (UTC)

I have a small bug report: it seems that if I have configured in `/etc/makepkg.conf` the MAKEFLAGS=-j8 the build breaks as the OpenAFS build system was not designed for this, so in order to fix this I had to add a `-j1` in the line `make || exit 1` and everything worked just fine.