Working on this....

CC: (none) => tarazed25

mga7, x86_64

Installed the release version against 5.5.15-desktop-3.mga7 without problems.
The build process takes a long time even on a fast system - using 10 cores here by the look of it.
Rebooted.
$ sudo dkms status
libafs, 1.8.5-1.mga7, 5.5.15-desktop-3.mga7, x86_64: installed
$ systemctl status openafs-server
● openafs-server.service - OpenAFS Server Service
   Loaded: loaded (/usr/lib/systemd/system/openafs-server.service; disabled; ve>
   Active: inactive (dead)

That is fair enough - it could be set to run on boot.

Updated the testing packages.
That rebuilt the libafs module.

$ sudo systemctl enable openafs-server.service
Created symlink /etc/systemd/system/multi-user.target.wants/openafs-server.service → /usr/lib/systemd/system/openafs-server.service.
$ sudo systemctl start openafs-server.service
$ 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 Wed 2020-04-22 14:57:59 BST; 10s ago
 Main PID: 13764 (bosserver)
   Memory: 4.1M
   CGroup: /system.slice/openafs-server.service
           └─13764 /usr/sbin/bosserver -nofork
$ ls /etc/openafs
bosserver.rxbind  CellServDB       CellServDB.local  ThisCell
cacheinfo         CellServDB.dist  server/

Switched to superuser.
# systemctl enable openafs-client
Created symlink /etc/systemd/system/multi-user.target.wants/openafs-client.service → /usr/lib/systemd/system/openafs-client.service.
Created symlink /etc/systemd/system/remote-fs.target.wants/openafs-client.service → /usr/lib/systemd/system/openafs-client.service.
# systemctl start openafs-client
# systemctl status openafs-client
● openafs-client.service - OpenAFS Client Service
   Loaded: loaded (/usr/lib/systemd/system/openafs-client.service; enabled; ven>
   Active: active (running) since Wed 2020-04-22 15:03:23 BST; 9s ago
  Process: 23401 ExecStartPre=/bin/sed -n w/etc/openafs/CellServDB /etc/openafs>
  Process: 23402 ExecStartPre=/bin/chmod 0644 /etc/openafs/CellServDB (code=exi>
  Process: 23403 ExecStartPre=/sbin/modprobe libafs (code=exited, status=0/SUCC>
  Process: 23547 ExecStart=/sbin/afsd $AFSD_ARGS (code=exited, status=0/SUCCESS)
 Main PID: 23579 (afsd)
   Memory: 7.0M
   CGroup: /system.slice/openafs-client.service
           └─23579 /sbin/afsd -dynroot -fakestat -afsdb

Apr 22 15:03:23 canopus systemd[1]: Starting OpenAFS Client Service...
Apr 22 15:03:23 canopus afsd[23547]: afsd: All AFS daemons started.
Apr 22 15:03:23 canopus afsd[23547]: afsd: All AFS daemons started.
Apr 22 15:03:23 canopus systemd[1]: Started OpenAFS Client Service.

# export PATH=$PATH:/usr/afs/bin
# bos listhosts canopus -localauth
bos: running unauthenticated
Cell name is localcell
    Host 1 is canopus

Back to user.
$ ls /afs
acm-csuf.org/                  laroia.net/
acm.jhu.edu/                   lcp.nrl.navy.mil/
adrake.org/                    le.infn.it/
afs.ietfng.org/                lnf.infn.it/
[...]
kloe.infn.it/                  ziti.uni-heidelberg.de/
kth.se/
$ cd /afs/wu-wien.ac.at/
lcl@canopus:wu-wien.ac.at $ ls
<That hung>
^C
$ cd /afs/openstack.org
lcl@canopus:openstack.org $ ls
developer-docs/  docs/  docs-old/  mirror/  project/  service/  user/
$ cd
$ bos setcellname canopus grasshopper -localauth
bos: could not find entry (configuring connection security)
$ ls /bin/*afs*
/bin/afs_compile_et*  /bin/afsmonitor*  /bin/up.afs*
/bin/afsio*           /bin/pagsh.afs*

$ afsio read /afs/openstack.org/docs/ocata/user/index.html
afsio: No such device (file not found: /afs/openstack.org/docs/ocata/user/index.html)
$ cd /afs/openstack.org/docs/ocata/user/
$ afsio read index.html
afsio: No such file or directory (file not found: index.html)
$ ls
index.html
$ cd
$ cat /afs/openstack.org/docs/ocata/user/index.html
<As it says on the can>
Read the documentation:
$ afsio read -file /afs/openstack.org/docs/ocata/user/index.html
afsio: No such device (file not found: /afs/openstack.org/docs/ocata/user/index.html)
This implies that afsio is not recognizing / - maybe assuming another root.
Herman, in bug 25816, echoed the distributed file system index to /etc/openafs/ThisCell.
Oops, just found a note to self, dated 2016-12-05...

# echo "/afs:/var/cache/openafs:321912832" > /etc/openafs/cacheinfo

Configured OpenAFS Cache manager:

# f=/etc/sysconfig/openafs
# sed < ${f} -e s/^AFSD_ARGS=/#AFSD_ARGS=/ -e s/^$/AFSD_ARGS="-dynroot -fakestat -afsdb -stat 2000 -dcache 800 -daemons 3 -volumes 70 -nosettime"/ > ${f}+
# mv -f ${f} /tmp/ && mv ${f}+ ${f}

Tried to restart the openafs-client but it was dead and would not start.
Warm reboot.
openafs-server running, client in 'failed' state.
Nothing mounted on /afs.
$ cat /etc/sysconfig/openafs
# OpenAFS Client Configuration
#AFSD_ARGS="-dynroot -fakestat -afsdb"
AFSD_ARGS=-dynroot -fakestat -afsdb -stat 2000 -dcache 800 -daemons 3 -volumes 70 -nosettime
# OpenAFS Server Configuration
BOSSERVER_ARGS=

# systemctl start openafs-client
Job for openafs-client.service failed because the control process exited with error code.
See "systemctl status openafs-client.service" and "journalctl -xe" for details.

Apr 22 16:42:53 canopus afsd[1755]: Cache size (321912832) must be less than 95% of partition size (which is 41046270). Lower cache size
Edited /etc/openafs/cacheinfo, replacing the size by 628736.
Started openafs-client successfully and AFS is mounted on /afs.
The remote files can be addressed by normal shell commands but afsio fails using the `read -file foobar` combination.  Is this a regression - che ne so?
It probably means that the afsio command does not work that way.
Let's try this:
$ wget http://dl.central.org/dl/cellservdb/CellServDB
# cat CellServDB > /etc/openafs/ThisCell
$ afsio read -file /afs/openstack.org/docs/ocata/user/index.html
afsio: Invalid argument (file not found: /afs/openstack.org/docs/ocata/user/index.html)

No idea but it raises the question, why use afsio when shell commands work?
To cut out the network lag?

Giving this its freedom on the basis of David Walser's recommendation in the current QA meeting.
Thanks David.

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

Validating. Advisory information in Comment 0.

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

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2020-0114.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED