Package Details: openafs-modules 1.8.6-1

Git Clone URL: (read-only, click to copy)
Package Base: openafs-modules
Description: Kernel module for OpenAFS
Upstream URL:
Licenses: custom:"IBM Public License Version 1.0"
Conflicts: openafs<1.6.6-2, openafs-features-libafs
Submitter: Bevan
Maintainer: Bevan
Last Packager: Bevan
Votes: 11
Popularity: 0.000504
First Submitted: 2014-03-23 13:24
Last Updated: 2020-10-17 21:52

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

batrick commented on 2016-02-11 14:41

I get this error when trying to build:

CC [M] /home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP/osi_misc.o
/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP/osi_groups.c: In function ‘afs_pag_instantiate’:
/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP/osi_groups.c:492:17: error: ‘union key_payload’ has no member named ‘value’
key->payload.value = (unsigned long) *userpag;
/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP/osi_groups.c: In function ‘afs_pag_destroy’:
/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP/osi_groups.c:516:34: error: ‘union key_payload’ has no member named ‘value’
afs_uint32 pag = key->payload.value;
/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP/osi_groups.c: In function ‘osi_get_keyring_pag’:
/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP/osi_groups.c:612:29: error: ‘union key_payload’ has no member named ‘value’
keyring_pag = key->payload.value;
scripts/ recipe for target '/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP/osi_groups.o' failed
make[6]: *** [/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP/osi_groups.o] Error 1
make[6]: *** Waiting for unfinished jobs....
Makefile:1384: recipe for target '_module_/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP' failed
make[5]: *** [_module_/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP] Error 2
make[5]: Leaving directory '/usr/lib/modules/4.4.1-2-ARCH/build'
FAILURE: make exit code 2
Makefile.afs:241: recipe for target 'openafs.ko' failed
make[4]: *** [openafs.ko] Error 1
make[4]: Leaving directory '/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs/MODLOAD-4.4.1-2-ARCH-SP'
Makefile:138: recipe for target 'linux_compdirs' failed
make[3]: *** [linux_compdirs] Error 2
make[3]: Leaving directory '/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16/src/libafs'
Makefile:483: recipe for target 'libafs' failed
make[2]: *** [libafs] Error 2
make[2]: Leaving directory '/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16'
Makefile:692: recipe for target 'build' failed
make[1]: *** [build] Error 2
make[1]: Leaving directory '/home/batrick/Downloads/openafs-modules/src/openafs-1.6.16'
Makefile:42: recipe for target 'only_libafs' failed
make: *** [only_libafs] Error 2
==> ERROR: A failure occurred in build().

Bevan commented on 2015-08-07 21:30

@darkxsun: I can image what could cause this issue, although I never observed it myself and did not verify it:

Imagine an update from linux 4.0 to 4.1. You may have another 3rd party module installed that is lying in extramodules-4.0-arch. Now you install linux 4.1. Consequently extramodules-4.1-arch is the most recent folder, which is what we and the heuristic in this PKGBUILD expect.
Now you update your other 3rd party module. It may (again: this is not verified) first install the new version in extramodules-4.1-arch and then remove its old version in extramodules-4.0-arch. Consequently extramodules-4.0-arch is the folder with the most recent update time, which confuses the heuristic in this PKGBUILD.

Currently I have no idea to handle this. I'm open for suggestions and will keep this problem in mind though. But you always can just change the PKGBUILD to point to the correct folder - or use the -dkms package... ;)

darkxsun commented on 2015-08-05 14:24


Re: my very old comment about ls -dt, you're right, there is no need to reverse-sort. The problem that made me think that has appeared again today, though.

I'm not sure exactly what scenarios cause it to happen, but sometimes after a -Syu and a reboot, the older version of extramodules (which in my case contained only an outdated openafs.ko.gz) shows up at the top of ls -dt, even though it's older and should be modified less recently. This causes the build of openafs-modules to fail.

In the end, I uninstalled the older openafs-modules (which deleted the older extramodules-4.0-arch) and then built fine, and I did this before I investigated fully the cause behind extramodules-4.0-arch showing up as more recently-modified than extramodules-4.1-arch. I'm guessing I won't have another opportunity to further debug until linux-4.2, but I'll report back if I learn anything useful.

Bevan commented on 2015-06-04 09:24

@iMike: The relevant message here is

WARNING: No usable linux headers found at /lib/modules/4.0.4-2-ARCH/build so disabling kernel module

But since linux-headers-4.0.4-2 is installed there are linux headers in that directory. Is it possible that you are using an older version of this package (e.g. 1.6.11 instead of

Independent of this issue: If you have more than one kernel installed I would recommend using the openafs-modules-dkms package instead. This package only builds a module for the most recently installed kernel.

iMike commented on 2015-06-03 14:54

I could not get this to compile against the 4.0.4-2-ARCH kernel. I get:

checking your OS... configure: WARNING: No usable linux headers found at /lib/modules/4.0.4-2-ARCH/build so disabling kernel module
checking your AFS sysname... configure: error: Couldn't guess your Linux version. Please use the --with-afs-sysname option to configure an AFS sysname.

Extra info:
$ uname -r
$ cat /lib/modules/extramodules-*/version
$ pacman -Q linux-headers
linux-headers 4.0.4-2

I tried a few wild guesses at --with-afs-sysname, but didn't have time to really look into the correct name. It should really be guessed by the system in any case. Is it because I have both the lts and regular kernels?

kaptoxic commented on 2015-02-22 21:01

Awesome, installs just fine now and openafs service started working again for me! Thanks!

Bevan commented on 2015-02-22 17:55

Thanks a lot. I missed a change of the behaviour of makepkg in pacman 4.2.0. I will fix this soon.

kaptoxic commented on 2015-02-22 16:12

Apparently the conflicting package is openafs:
$ pacman -Qs openafs
local/openafs 1.6.10-1
Open source implementation of the AFS distributed file system
$ pacman -Qo /usr/lib/afs/libafscom_err.a
/usr/lib/afs/libafscom_err.a is owned by openafs 1.6.10-1

Bevan commented on 2015-02-11 10:30

@kaptoxic: That's a nice reminder that I have to remove those files from the package. But I wonder with what other package there should be a conflict. The main openafs package does not include them and you even said you removed that.

So let's find out. Please post the output of the following commands:
pacman -Qs openafs
pacman -Qo /usr/lib/afs/libafscom_err.a

kaptoxic commented on 2015-02-11 02:49

Sorry, forgot to turn on the notifications. Interestingly, I got new errors (I first removed openafs package):
error: failed to commit transaction (conflicting files)
openafs-modules: /usr/lib/afs/libafscom_err.a exists in filesystem
openafs-modules: /usr/lib/afs/libafsutil.a exists in filesystem
openafs-modules: /usr/lib/afs/libprocmgmt.a exists in filesystem
openafs-modules: /usr/lib/afs/util.a exists in filesystem
openafs-modules: /usr/lib/libdes.a exists in filesystem
Errors occurred, no packages were upgraded.

$ uname -r
$ cat /lib/modules/extramodules-*/version
$ pacman -Q linux-headers
linux-headers 3.18.6-1