Package Details: openafs-modules 1.8.13.1-1

Git Clone URL: https://aur.archlinux.org/openafs-modules.git (read-only, click to copy)
Package Base: openafs-modules
Description: Kernel module for OpenAFS
Upstream URL: http://www.openafs.org
Licenses: IPL-1.0
Conflicts: openafs, openafs-features-libafs
Submitter: Bevan
Maintainer: Bevan
Last Packager: Bevan
Votes: 10
Popularity: 0.000000
First Submitted: 2014-03-23 13:24 (UTC)
Last Updated: 2024-12-21 09:26 (UTC)

Dependencies (4)

Required by (1)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

Bevan commented on 2015-08-07 21:30 (UTC)

@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 (UTC)

@Bevan 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 (UTC)

@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 1.6.11.1)? 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 (UTC)

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 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. Extra info: $ uname -r 4.0.4-2-ARCH $ cat /lib/modules/extramodules-*/version 3.14.43-2-lts 4.0.4-2-ARCH $ 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?

aspirogrammer commented on 2015-02-22 21:01 (UTC)

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

Bevan commented on 2015-02-22 17:55 (UTC)

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

aspirogrammer commented on 2015-02-22 16:12 (UTC)

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 (UTC)

@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

aspirogrammer commented on 2015-02-11 02:49 (UTC)

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 3.18.6-1-ARCH $ cat /lib/modules/extramodules-*/version 3.18.6-1-ARCH $ pacman -Q linux-headers linux-headers 3.18.6-1

Bevan commented on 2014-10-28 22:54 (UTC)

@kaptoxic: Normally this occurs when the version of installed kernel headers differ from the version of the running kernel. Maybe you haven't rebooted yet after the latest kernel update? Otherwise please post the output of - uname -r - cat /lib/modules/extramodules-*/version - pacman -Q linux-headers

« First ‹ Previous 1 2 3 4 Next › Last »