Package Details: openafs 1.8.11pre1-1

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

Latest Comments

1 2 3 4 5 6 .. 32 Next › Last »

Bevan commented on 2024-01-22 20:38 (UTC) (edited on 2024-01-31 20:15 (UTC) by Bevan)

Can anyone report their experience with OpenAFS and Linux 6.7? I'm personally having issues with that combination (hanging accesses) but developers working with the exact same software versions cannot reproduce any issues. See: https://lists.openafs.org/pipermail/openafs-devel/2024-January/020909.html

Update 2024-01-31: No need for feedback anymore. This turned out to be a regression in the Linux kernel which is only triggered in specific scenarios. This should be solved in an upcoming kernel release. A corresponding patch has been submitted: https://lore.kernel.org/netdev/20240131155220.82641-1-bevan@bi-co.net/T/

drslmr commented on 2023-10-10 13:18 (UTC)

@Bevan: Thank you for the quick solution.

Bevan commented on 2023-10-09 08:52 (UTC)

I guess it is caused by this change, enabling the backup scripts in tar: https://gitlab.archlinux.org/archlinux/packaging/packages/tar/-/commit/23d47df2369e70dba362ac0e70036baef2475bdb#9b9baac1eb9b72790eef5540a1685306fc43fd6c_37_40

Still, I would not call this a tar issue. /usr/bin/backup is a very generic name to use and OpenAFS is quite niche while everyone uses tar. So I think we should rename the binary in this package.

drslmr commented on 2023-10-09 08:44 (UTC)

Conflict with tar?

I'm getting the following error when upgrading tar:

error: failed to commit transaction (conflicting files) tar: /usr/bin/backup exists in filesystem (owned by openafs)

Probably an tar issue?

Bevan commented on 2023-10-06 17:49 (UTC)

The kernel BUG with Linux 6.5 should now be fixed in openafs-modules 1.8.10-4 and openafs-modules-dkms 1.8.10-4.

drslmr commented on 2023-10-06 12:15 (UTC)

@Bevan: Thank you. I should have guessed that. I'm using openafs-modules-dkms. And now it works for me.

Bevan commented on 2023-10-06 11:22 (UTC)

@drslmr: You need to patch the openafs-modules or openafs-modules-dkms package, depending on which of the two you are using. This package (openafs) does not need to be patched as it does not contain any kernel-specific code.

I am planning to roll out exactly that change later today.

drslmr commented on 2023-10-06 11:19 (UTC)

Just for curiosity I tried to patch openafs 1.8.10-1 with e18f420.diff from gerrit.

I installed the patched openafs package and upgraded to kernel 6.5.5. I also reinstalled openafs-modules-dkms.

But the BUG still occurs.

Could anyone tell me what I missed?

Bevan commented on 2023-09-22 18:15 (UTC)

Just a heads up: The kernel BUG with Linux 6.5 is a false alarm in the sense that no actual buffer overflow occurs. However, it leaves the system in quite a bad state where syncs just hang and the system won't properly shut down anymore.

A patch is developed and discussed at https://gerrit.openafs.org/#/c/15573/. Currently, there are different opinions on which of two solution is preferable. I may add a minimal patch to the openafs-modules packages as soon as I'm confident that the patch does no harm.

For now, using linux-lts stays the safest option.

Bevan commented on 2023-09-14 18:59 (UTC)

The issue is easily reproducible. I could not find any related patch and for me it's not trivial to fix either. So I posted to the openafs-devel mailing list: https://lists.openafs.org/pipermail/openafs-devel/2023-September/020888.html