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.
Assignee: bugsquad => kernelCC: (none) => marja11Source RPM: dkms-libafs-1.8.2.-1.mga7 => openafs-1.8.2.-1.mga7
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.
CC: (none) => tmb
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 SRPM: openafs-1.8.3-1.mga8.src.rpm i586: openafs-1.8.3-1.mga8.i586.rpm openafs-client-1.8.3-1.mga8.i586.rpm openafs-server-1.8.3-1.mga8.i586.rpm libopenafs2-1.8.3-1.mga8.i586.rpm libopenafs-devel-1.8.3-1.mga8.i586.rpm libopenafs-static-devel-1.8.3-1.mga8.i586.rpm dkms-libafs-1.8.3-1.mga8.noarch.rpm openafs-doc-1.8.3-1.mga8.noarch.rpm x86_64: openafs-1.8.3-1.mga8.x86_64.rpm openafs-client-1.8.3-1.mga8.x86_64.rpm openafs-server-1.8.3-1.mga8.x86_64.rpm lib64openafs2-1.8.3-1.mga8.x86_64.rpm lib64openafs-devel-1.8.3-1.mga8.x86_64.rpm lib64openafs-static-devel-1.8.3-1.mga8.x86_64.rpm dkms-libafs-1.8.3-1.mga8.noarch.rpm openafs-doc-1.8.3-1.mga8.noarch.rpm
QA Contact: (none) => qa-bugs
Assignee: kernel => qa-bugsQA Contact: qa-bugs => (none)
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. libafs.ko.xz: - Installation - Installing to /lib/modules/5.2.11-desktop-2.mga7/dkms/3rdparty/libafs// depmod........ DKMS: install Completed. [root@thunder ~]# modinfo libafs filename: /lib/modules/5.2.11-desktop-2.mga7/dkms/3rdparty/libafs/libafs.ko.xz license: http://www.openafs.org/dl/license10.html depends: retpoline: Y name: 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
mga7, x86_64 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. Warm reboot. $ 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) Memory: 4.8M CGroup: /system.slice/openafs-server.service └─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 db logs 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 acm-csuf.org/ laroia.net/ acm.jhu.edu/ lcp.nrl.navy.mil/ adrake.org/ le.infn.it/ [...] kfki.hu/ wu-wien.ac.at/ kloe.infn.it/ zcu.cz/ kth.se/ ziti.uni-heidelberg.de/ $ 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: https://docs.openstack.org/infra/system-config/afs.html This is as far as I go. It certainly works.
Whiteboard: (none) => MGA7-64-OKCC: (none) => tarazed25
Keywords: (none) => advisory, validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2019-0128.html
Status: NEW => RESOLVEDResolution: (none) => FIXED