The libafs kernel module fails to install on kernels 4.20 or higher because compilation fails. The newer kernels have removed several symbols used by libafs 1.8.2. As a result, the AFS filesystem cannot be used on Mageia 7 or Cauldron.
Please update from upstream; 1.8.3 restores compatibility with new kernels, and was releassed in April 2019.
Yep, we need to be more careful about this if we're going rolling release for the kernel. xfsprogs, iproute2, and strace are other packages that come to mind that may need to be updated as the kernel is. There are probably others.
Well, I'm not going to blindly accept maintenance burden of every package in Mageia that happends to build against kernel just because someone else have imported it just to ignore it after that... Thats not how this works....
And considering we switched to 4.20 series kernels in January and its just now
noticed that it broke, i guess it has not been that critical...
Looking at this package I see it's listed as unmaintained, so maybe we should just drop it from cauldron... anyway we are stuck with it in Mageia 7...
As for xfsprogs and other userspace tools, they dont break just because we bump the kernel, so obsessing about version match is useless...
For example the xfrprogs change between 5.1 and 5.2 only synced some header stuff, nothing userspace visible, or no missing feature added...
Same goes for iproute2, it does not stop working, it just sometimes adds support for new kernel features, so it's not a regression...
But yes, I usually try to keep stuff uptodate when there is known fixes needed becuse of some upsteam change...
Having said that, I've now pushed 1.8.3 to testing including fixes for upcoming 5.3 series kernels
and obviously those packages are *.mga7.*
I do understand what you're saying, and mostly agree. This package is not strictly necessary, and being unmaintained could certainly be dropped. As for things like the other packages I mentioned that you also touched on (as well as strace which sometimes adds support for new syscalls in new kernels) and other packages that have adaptations because of new kernels, I'd argue it's the responsibility that you take on when you upgrade the kernel instead of sticking to an LTS branch. I'm not asking to revisit that decision as it has already been made, just saying let's be careful to make sure to keep the userspace support up to date if we're going this way.
ethtool and iw are other ones I just remembered. I'm not sure if things like alsa stuff or iptables/nftables ever need to be updated with the kernel. Maybe systemtap or acpica-tools? Not sure about e2fsprogs, iputils, kmod, lsof, ltrace, procps, pciutils, usbutils, coreutils, or util-linux. The audit package probably doesn't matter since we disabled syscall auditing, and there's other low level stuff like acpid, bluez, hdparm, irqbalance, and dmidecode, but I'm just spitballing here. That's all I can think of, but you would know better than anyone what actually matters.
@Ralf Brown: have you tested this update ?
Sorry, it's been a hectic week. I did update on 8/25 and it the DKMS module compiled and installed without error, but systemctl wasn't able to start the AFS client. Today I had a chance to plumb the depths of systemd....
In /usr/lib/systemd/system/openafs-client.service, two instances of "libafs" need to be changed to "kafs" -- the name of the kernel module changed.
Wait, what ?
DKMS: build Completed.
- Installing to /lib/modules/5.2.11-desktop-2.mga7/dkms/3rdparty/libafs//
DKMS: install Completed.
[root@thunder ~]# modinfo libafs
vermagic: 5.2.11-desktop-2.mga7 SMP mod_unload
(In reply to Ralf Brown from comment #8)
> Sorry, it's been a hectic week. I did update on 8/25 and it the DKMS module
> compiled and installed without error, but systemctl wasn't able to start the
> AFS client. Today I had a chance to plumb the depths of systemd....
> In /usr/lib/systemd/system/openafs-client.service, two instances of "libafs"
> need to be changed to "kafs" -- the name of the kernel module changed.
I cant reproduce this...
The module builds as libafs in all my tests
Tried installing openafs from release, which started dkms-libafs.
After some time the module build failed.
Error! Bad return status for module build on kernel: 5.2.13-desktop-2.mga7 (x86_64)
Updated to mga8 packages.
The libafs module build succeeded.
DKMS: install Completed.
Deleting module version: 1.8.2-1.mga7
completely from the DKMS tree.
# dkms status | grep afs
libafs, 1.8.3-1.mga7, 5.2.13-desktop-2.mga7, x86_64: installed
openafs-server appeared in the list of system services. Enabled run on boot.
$ systemctl status openafs-server
● openafs-server.service - OpenAFS Server Service
Loaded: loaded (/usr/lib/systemd/system/openafs-server.service; enabled; ven>
Active: active (running) since Sun 2019-09-15 09:08:11 BST; 38s ago
Main PID: 6046 (bosserver)
└─6046 /usr/sbin/bosserver -nofork
Started the openafs-client service.
$ ls /usr/libexec/openafs
buserver* dasalvager* fileserver* salvager* upclient* vlserver*
dafileserver* davolserver* ptserver* salvageserver* upserver* volserver*
# ls /var/openafs
This is a distributed filesystem application which I have tested in the past but have no memory of how. There was a tutorial somewhere which allowed me to sync with other cells on the web.
Fiddled with various commands....
# export PATH=$PATH:/usr/afs/bin
# bos setcellname canopus grasshopper -localauth
bos: could not find entry (configuring connection security)
# bos listhosts
bos: Missing required parameter '-server'
# bos listhosts canopus -localauth
bos: running unauthenticated
Cell name is localcell
Host 1 is canopus
$ ls /afs
$ cd /afs/openstack.org
lcl@canopus:openstack.org $ ls
developer-docs/ docs/ docs-old/ mirror/ project/ service/ user/
lcl@canopus:openstack.org $ cd
Even with a high bandwidth connection this is all rather slow. The remote server is probably overloaded.
Openstack is probably the best site to visit for more information:
This is as far as I go. It certainly works.
An update for this issue has been pushed to the Mageia Updates repository.