| Summary: | OpenAFS 1.8.2 kernel module incompatible with Linux kernel 4.20+ | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Ralf Brown <ralfbrown> |
| Component: | RPM Packages | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | marja11, sysadmin-bugs, tarazed25, tmb |
| Version: | 7 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA7-64-OK | ||
| Source RPM: | openafs-1.8.2.-1.mga7 | CVE: | |
| Status comment: | |||
|
Description
Ralf Brown
2019-08-22 15:11:12 CEST
Marja Van Waes
2019-08-24 19:43:34 CEST
Assignee:
bugsquad =>
kernel 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
Thomas Backlund
2019-08-24 21:35:05 CEST
Assignee:
kernel =>
qa-bugs 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-OK
Thomas Backlund
2019-09-15 15:25:38 CEST
Keywords:
(none) =>
advisory, validated_update An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2019-0128.html Status:
NEW =>
RESOLVED |