Bug 25342 - OpenAFS 1.8.2 kernel module incompatible with Linux kernel 4.20+
Summary: OpenAFS 1.8.2 kernel module incompatible with Linux kernel 4.20+
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact:
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2019-08-22 15:11 CEST by Ralf Brown
Modified: 2019-09-15 16:46 CEST (History)
4 users (show)

See Also:
Source RPM: openafs-1.8.2.-1.mga7
Status comment:


Description Ralf Brown 2019-08-22 15:11:12 CEST
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.
Marja Van Waes 2019-08-24 19:43:34 CEST

Assignee: bugsquad => kernel
CC: (none) => marja11
Source RPM: dkms-libafs-1.8.2.-1.mga7 => openafs-1.8.2.-1.mga7

Comment 1 David Walser 2019-08-24 19:50:54 CEST
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

Comment 2 Thomas Backlund 2019-08-24 20:33:29 CEST
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...
Comment 3 Thomas Backlund 2019-08-24 21:30:15 CEST
Having said that, I've now pushed 1.8.3 to testing including fixes for upcoming 5.3 series kernels




QA Contact: (none) => qa-bugs

Thomas Backlund 2019-08-24 21:35:05 CEST

QA Contact: qa-bugs => (none)
Assignee: kernel => qa-bugs

Comment 4 Thomas Backlund 2019-08-24 22:14:44 CEST
and obviously those packages are *.mga7.*
Comment 5 David Walser 2019-08-25 00:53:06 CEST
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.
Comment 6 David Walser 2019-08-25 01:35:57 CEST
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.
Comment 7 Thomas Backlund 2019-08-31 15:55:02 CEST
@Ralf Brown: have you tested this update ?
Comment 8 Ralf Brown 2019-09-02 22:17:47 CEST
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.
Comment 9 Thomas Backlund 2019-09-02 22:44:59 CEST
Wait, what ?

DKMS: build Completed.

 - Installation
   - Installing to /lib/modules/5.2.11-desktop-2.mga7/dkms/3rdparty/libafs//


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
retpoline:      Y
name:           libafs
vermagic:       5.2.11-desktop-2.mga7 SMP mod_unload
Comment 10 Thomas Backlund 2019-09-06 17:25:28 CEST
(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
Comment 11 Len Lawrence 2019-09-15 11:07:50 CEST
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:

This is as far as I go.  It certainly works.

Whiteboard: (none) => MGA7-64-OK
CC: (none) => tarazed25

Thomas Backlund 2019-09-15 15:25:38 CEST

Keywords: (none) => advisory, validated_update
CC: (none) => sysadmin-bugs

Comment 12 Mageia Robot 2019-09-15 16:46:36 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.