openafs-fileserver 1.6.18.3-1 ADT test failure on s390x

[Andy Whitcroft]

Testing failed on:
    s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-canonical-kernel-team-unstable/yakkety/s390x/o/openafs/20160918_091929@/log.gz

[Anders Kaseorg (andersk)]

That log shows openafs-modules-dkms successfully compiling with kernel 4.8. The only problem shown is openafs-fileserver failing to start.

Setting up openafs-fileserver (1.6.18.3-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/openafs-fileserver.service → /lib/systemd/system/openafs-fileserver.service.
Job for openafs-fileserver.service failed because the control process exited with error code.
See "systemctl status openafs-fileserver.service" and "journalctl -xe" for details.
invoke-rc.d: initscript openafs-fileserver, action "start" failed.
● openafs-fileserver.service - OpenAFS file and database server manager
   Loaded: loaded (/lib/systemd/system/openafs-fileserver.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2016-09-18 09:16:56 UTC; 5ms ago
  Process: 12244 ExecStop=/usr/bin/bos shutdown localhost -wait -localauth (code=exited, status=1/FAILURE)
  Process: 12242 ExecStart=/usr/sbin/bosserver $DAEMON_ARGS (code=exited, status=0/SUCCESS)

Sep 18 09:16:56 autopkgtest-lxc-hbkuie systemd[1]: Starting OpenAFS file and ...
Sep 18 09:16:56 autopkgtest-lxc-hbkuie bos[12244]: bos: could not find entry ...
Sep 18 09:16:56 autopkgtest-lxc-hbkuie bos[12244]: [1B blob data]
Sep 18 09:16:56 autopkgtest-lxc-hbkuie systemd[1]: openafs-fileserver.service...
Sep 18 09:16:56 autopkgtest-lxc-hbkuie systemd[1]: Failed to start OpenAFS fi...
Sep 18 09:16:56 autopkgtest-lxc-hbkuie systemd[1]: openafs-fileserver.service...
Sep 18 09:16:56 autopkgtest-lxc-hbkuie systemd[1]: openafs-fileserver.service...
Hint: Some lines were ellipsized, use -l to show in full.
dpkg: error processing package openafs-fileserver (--configure):
 subprocess installed post-installation script returned error exit status 1

It’s hard to say what went wrong without knowing what’s behind those ellipses. However, since this test seems to have been run in an LXC container with host kernel 4.4.0-36-generic, this cannot possibly be related to kernel 4.8.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Anders Kaseorg (andersk)]

This is now causing failures on armhf and s390x most of the time (bug 1704156), and has been holding back the sync of 1.6.21-1 (bug 1705850) for weeks, as well as the update to 1.6.21-1ubuntu1. It’s still hard to say what the problem is with these truncated log messages; can autopkgtest be made to use -l here?

[Anders Kaseorg (andersk)]

Oh, the ellipsis problem is supposed to be fixed by init-system-helpers 1.49 (https://anonscm.debian.org/git/collab-maint/init-system-helpers.git/commit/?id=5836b307724f8731b47d3d4d064ada1833182705), which is still in artful-proposed due to its own autopkgtest regressions.

http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#init-system-helpers

[Nish Aravamudan (nacc)]

Ok, so this is a real regression.

From 1.6.20-2ubuntu2 on s390x (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/s390x/o/openafs/20170812_062159_c1e25@/log.gz):

Setting up openafs-modules-dkms (1.6.20-2ubuntu2) ...
Loading new openafs-1.6.20 DKMS files...
It is likely that 4.4.0-47-generic belongs to a chroot's host
Building for 4.11.0-13-generic and 4.12.0-11-generic
Building initial module for 4.11.0-13-generic
Done.

openafs:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.11.0-13-generic/updates/dkms/

depmod...

DKMS: install completed.
Building initial module for 4.12.0-11-generic
Error! Bad return status for module build on kernel: 4.12.0-11-generic (s390x)
Consult /var/lib/dkms/openafs/1.6.20/build/make.log for more information.

... and later

I: Installing binary package openafs-modules-dkms
Reading package lists...
Building dependency tree...
Reading state information...
openafs-modules-dkms is already the newest version (1.6.20-2ubuntu2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
I: Testing binary package openafs-modules-dkms
I: Testing if openafs modules are correctly installed
openafs, 1.6.20, 4.11.0-13-generic, s390x: installed

From 1.6.21-2 (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/s390x/o/openafs/20170823_121006_17cbc@/log.gz):

Setting up openafs-modules-dkms (1.6.21-2) ...
Loading new openafs-1.6.21 DKMS files...
It is likely that 4.4.0-47-generic belongs to a chroot's host
Building for 4.12.0-11-generic
Building initial module for 4.12.0-11-generic
Error! Bad return status for module build on kernel: 4.12.0-11-generic (s390x)
Consult /var/lib/dkms/openafs/1.6.21/build/make.log for more information.

... and later

openafs-modules-dkms is already the newest version (1.6.21-2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
I: Testing binary package openafs-modules-dkms
I: Testing if openafs modules are correctly installed
openafs, 1.6.21: added
E: not installed

From a s390x env, here is the tail of the make.log referred to above:

  CC [M] /var/lib/dkms/openafs/1.6.21/build/src/libafs/MODLOAD-4.12.0-11-generic-SP/afs_dcache.o
  CC [M] /var/lib/dkms/openafs/1.6.21/build/src/libafs/MODLOAD-4.12.0-11-generic-SP/afs_dir.o
In file included from /var/lib/dkms/openafs/1.6.21/build/src/afs/LINUX/osi_machdep.h:126:0,
                 from /var/lib/dkms/openafs/1.6.21/build/src/afs/afs_osi.h:440,
                 from /var/lib/dkms/openafs/1.6.21/build/src/libafs/MODLOAD-4.12.0-11-generic-SP/afs_dir.c:70:
./arch/s390/include/asm/uaccess.h: In function ‘set_fs’:
./arch/s390/include/asm/uaccess.h:41:6: error: implicit declaration of function ‘uaccess_kernel’; did you mean ‘getname_kernel’? [-Werror=implicit-function-declaration]
  if (uaccess_kernel()) {
      ^~~~~~~~~~~~~~
      getname_kernel
cc1: some warnings being treated as errors
scripts/Makefile.build:302: recipe for target '/var/lib/dkms/openafs/1.6.21/build/src/libafs/MODLOAD-4.12.0-11-...

[Seth Forshee (sforshee)]

@Nish: Take a look at bug 1711835, I've already posted a patch there.

[Anders Kaseorg (andersk)]

Ah, so the uaccess_kernel issue in bug 1711835 isn’t fatal when building for both kernel 4.11 and kernel 4.12, but it is fatal when building for only kernel 4.12.

However, that’s separate the openafs-fileserver issue from this bug and bug 1704156, right? These logs end much earlier with

Errors were encountered while processing:
 openafs-fileserver
 autopkgtest-satdep
 openafs-dbserver
E: Sub-process /usr/bin/dpkg returned an error code (1)

[Nish Aravamudan (nacc)]

Ok a plain rebuild of openafs in artful also fails:

.0-11-generic-SP/afs_dir.c:70:
./arch/s390/include/asm/uaccess.h: In function ‘set_fs’:
./arch/s390/include/asm/uaccess.h:41:6: error: implicit declaration of function
‘uaccess_kernel’; did you mean ‘getname_kernel’? [-Werror=implicit-function-decl
aration]
  if (uaccess_kernel()) {
      ^~~~~~~~~~~~~~
      getname_kernel
cc1: some warnings being treated as errors
scripts/Makefile.build:302: recipe for target '/var/lib/dkms/openafs/1.6.20/build/src/libafs/MODLOAD-4.12.0-11-generic-SP/afs_dir.o' failed
make[4]: *** [/var/lib/dkms/openafs/1.6.20/build/src/libafs/MODLOAD-4.12.0-11-generic-SP/afs_dir.o] Error 1
Makefile:1549: recipe for target '_module_/var/lib/dkms/openafs/1.6.20/build/src/libafs/MODLOAD-4.12.0-11-generic-SP' failed
make[3]: *** [_module_/var/lib/dkms/openafs/1.6.20/build/src/libafs/MODLOAD-4.12.0-11-generic-SP] Error 2
make[3]: Leaving directory '/usr/src/linux-headers-4.12.0-11-generic'
FAILURE: make exit code 2
Makefile.afs:241: recipe for target 'openafs.ko' failed
make[2]: *** [openafs.ko] Error 1

[Nish Aravamudan (nacc)]

@Anders: as far as I can tell, openafs-fileserver doesn't fail even in lxc systems. The failure in bug 1704156 was a real one (the service should start, even if the modules aren't built for the host kernel.

In any case, I expect Seth's latest upload will end up fixing openafs for artful.