Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error building and installing zfs-dkms on Debian Stretch #7540

Closed
Serphentas opened this issue May 13, 2018 · 10 comments
Closed

Error building and installing zfs-dkms on Debian Stretch #7540

Serphentas opened this issue May 13, 2018 · 10 comments
Labels
Type: Building Indicates an issue related to building binaries

Comments

@Serphentas
Copy link

System information

Type Version/Name
Distribution Name Debian
Distribution Version Stretch
Linux Kernel 4.9.0-6-amd64
Architecture amd64
ZFS Version 0.7.9
SPL Version 0.7.9

Describe the problem you're observing

During make pkg-utils deb-dkms I see errors as described in #5744.

When installing the zfs-dkms deb file, the installation fails:

asdf@stretch:~/zfs$ sudo gdebi zfs-dkms_0.7.9-1_amd64.deb
Reading package lists... Done
Building dependency tree        
Reading state information... Done
Reading state information... Done

Kernel module(s) (dkms)
 This package contains the dkms ZFS kernel modules.
 .
 (Converted from a rpm package by alien version 8.95.)
Do you want to install the software package? [y/N]:y
(Reading database ... 77493 files and directories currently installed.)
Preparing to unpack zfs-dkms_0.7.9-1_amd64.deb ...

Uninstall of zfs module (zfs-0.7.9-1) beginning:

------------------------------
Deleting module version: 0.7.9
completely from the DKMS tree.
------------------------------
Done.
Unpacking zfs-dkms (0.7.9-1) over (0.7.9-1) ...
Setting up zfs-dkms (0.7.9-1) ...
Loading new zfs-0.7.9 DKMS files...
Building for 4.9.0-6-amd64
Building initial module for 4.9.0-6-amd64
configure: error: in `/var/lib/dkms/zfs/0.7.9/build':
configure: error: SHUT 'ER DOWN CLANCY, SHE'S PUMPIN' MUD!
See `config.log' for more details
Error! Bad return status for module build on kernel: 4.9.0-6-amd64 (x86_64)
Consult /var/lib/dkms/zfs/0.7.9/build/make.log for more information.

The config.log reveals:

configure:3623: $? = 0
configure:3612: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) 
configure:3623: $? = 0
configure:3612: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3623: $? = 1
configure:3612: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.
...
conftest.c:17:28: fatal error: ac_nonexistent.h: No such file or directory
 #include <ac_nonexistent.h>
                            ^
compilation terminated.
configure:7806: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "zfs"
| #define PACKAGE_TARNAME "zfs"
| #define PACKAGE_VERSION "0.7.9"
| #define PACKAGE_STRING "zfs 0.7.9"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define ZFS_META_NAME "zfs"
| #define ZFS_META_VERSION "0.7.9"
| #define ZFS_META_RELEASE "1"
| #define ZFS_META_LICENSE "CDDL"
| #define ZFS_META_ALIAS "zfs-0.7.9-1"
| #define ZFS_META_AUTHOR "OpenZFS on Linux"
| #define PACKAGE "zfs"
| #define VERSION "0.7.9"
| /* end confdefs.h.  */
| #include <ac_nonexistent.h>
configure:7831: result: gcc -E
configure:7851: gcc -E  conftest.c
configure:7851: $? = 0
configure:7865: gcc -E  conftest.c
conftest.c:17:28: fatal error: ac_nonexistent.h: No such file or directory
 #include <ac_nonexistent.h>
                           ^

...

and other similar issues.

Note that SPL builds correctly, using DKMS.

Describe how to reproduce the problem

Build SPL and ZFS for Debian using DKMS, either from releases tarballs or Git.

cd spl
autoreconf --force --install
./configure --with-config=user
make clean
make pkg-utils deb-dkms

then install appropriate SPL debs. Then ZFS:

cd ../zfs
autoreconf --force --install
./configure --with-config=user
make clean
make pkg-utils deb-dkms

then install appropriate ZFS debs and observe errors above.

I have been through #6044, #5744, #6577 and others, but to no avail.

@loli10K loli10K added the Type: Building Indicates an issue related to building binaries label May 13, 2018
@Maliuta
Copy link

Maliuta commented May 20, 2018

Kernel module(s) (dkms)
This package contains the dkms ZFS kernel modules.
.
(Converted from a rpm package by alien version 8.95.)

That is your problem right there. You should try either building from debian sources (with 'dpkg-buildpackage', or simply 'fakeroot ./debian/rules binary'), or creating your own debian directory in a source tree pulled from zol git. Building things for Debian the Debian way is good practice, relying on things converted from rpm's by alien is likely to see you end up with all sorts of problems.

@Ryushin
Copy link

Ryushin commented May 21, 2018

Building from the Debian 0.7.9-2 sources results in the same error for Jessie.

Setting up zfs-dkms (0.7.9-2) ...
Loading new zfs-0.7.9 DKMS files...
Building for 4.9.0-0.bpo.5-amd64
Building initial module for 4.9.0-0.bpo.5-amd64
configure: error: in /var/lib/dkms/zfs/0.7.9/build': configure: error: SHUT 'ER DOWN CLANCY, SHE'S PUMPIN' MUD! See config.log' for more details
Error! Bad return status for module build on kernel: 4.9.0-0.bpo.5-amd64 (x86_64)

dkms config.log
config.log

@aerusso
Copy link
Contributor

aerusso commented May 21, 2018

No such file or directory at ./scripts/enum-extract.pl line 26.

This is due to (the new enum-extract.pl, added for 338523d) not being included in the dkms package. I pushed the fix for this into the official Debian packaging, but I'm not familiar enough with the ZFS RPM to DEB process to be 100% sure how to fix it here.

I'm inclined to believe this would also affect RPM dkms builds, too.

@Serphentas Could you confirm the quoted line is in your log? I think the gcc -V error might be spurious.

EDIT: Debian keeps its kernel source organized differently. I've opened a PR that should fix this.

aerusso added a commit to aerusso/zfs that referenced this issue May 21, 2018
scripts/dkms.mkconf calls configure with

`--with-linux=${kernel_source_dir}`, but Debian puts it kernel source at
`/lib/modules/<version>/source`. This patch adds the same logic to the
DKMS file produced by `scripts/dkms.mkconf` that Debian has shipped in
its official ZFS packaging.

Signed-off-by: Antonio Russo <antonio.e.russo@gmail.com>
Closes openzfs#7352 openzfs#7540
aerusso added a commit to aerusso/zfs that referenced this issue May 21, 2018
scripts/dkms.mkconf calls configure with

`--with-linux=${kernel_source_dir}`, but Debian puts it kernel source at
`/lib/modules/<version>/source`. This patch adds the same logic to the
DKMS file produced by `scripts/dkms.mkconf` that Debian has shipped in
its official ZFS packaging: at DKMS build time, it checks if the system
is a Debian system, and adjusts the path accordingly.

Signed-off-by: Antonio Russo <antonio.e.russo@gmail.com>
Closes openzfs#7352 openzfs#7540
aerusso added a commit to aerusso/zfs that referenced this issue May 21, 2018
scripts/dkms.mkconf calls configure with

`--with-linux=${kernel_source_dir}`, but Debian puts it kernel source at
`/lib/modules/<version>/source`. This patch adds the same logic to the
DKMS file produced by `scripts/dkms.mkconf` that Debian has shipped in
its official ZFS packaging: at DKMS build time, it checks if the system
is a Debian system, and adjusts the path accordingly.

Signed-off-by: Antonio Russo <antonio.e.russo@gmail.com>
Closes openzfs#7358 openzfs#7540
@aerusso aerusso mentioned this issue May 21, 2018
12 tasks
@aerusso
Copy link
Contributor

aerusso commented May 23, 2018

@Serphentas @Ryushin Could you confirm that PR #7554 fixes this problem for you?

@Ryushin
Copy link

Ryushin commented May 24, 2018

@aerusso I'm afraid the error still exists.
config.log

The problem occurs on Jessie but not Sid (Devuan Ceres). I have not tested Stretch (Devuan Ascii) but probably I should.

@aerusso
Copy link
Contributor

aerusso commented May 24, 2018

Can I get the output of

# ls -l /lib/modules/4.9.0-0.bpo.6-amd64
# ls -l /lib/modules/4.9.0-0.bpo.6-amd64/build
# lsb_release -is

from the failing machine, please?

@Ryushin
Copy link

Ryushin commented May 24, 2018

@aerusso Sure:

ls -l /lib/modules/4.9.0-0.bpo.6-amd64
total 4652
lrwxrwxrwx 1 root root 42 May 13 13:27 build -> /usr/src/linux-headers-4.9.0-0.bpo.6-amd64
drwxr-xr-x 4 root root 4 May 23 07:32 extra
drwxr-xr-x 12 root root 12 May 20 08:51 kernel
-rw-r--r-- 1 root root 1015074 May 23 07:32 modules.alias
-rw-r--r-- 1 root root 973683 May 23 07:32 modules.alias.bin
-rw-r--r-- 1 root root 4018 May 13 13:27 modules.builtin
-rw-r--r-- 1 root root 5327 May 23 07:32 modules.builtin.bin
-rw-r--r-- 1 root root 399060 May 23 07:32 modules.dep
-rw-r--r-- 1 root root 549988 May 23 07:32 modules.dep.bin
-rw-r--r-- 1 root root 402 May 23 07:32 modules.devname
-rw-r--r-- 1 root root 133512 May 13 13:27 modules.order
-rw-r--r-- 1 root root 523 May 23 07:32 modules.softdep
-rw-r--r-- 1 root root 494053 May 23 07:32 modules.symbols
-rw-r--r-- 1 root root 610649 May 23 07:32 modules.symbols.bin
lrwxrwxrwx 1 root root 43 May 13 13:27 source -> /usr/src/linux-headers-4.9.0-0.bpo.6-common

ls -l /lib/modules/4.9.0-0.bpo.6-amd64/build
lrwxrwxrwx 1 root root 42 May 13 13:27 /lib/modules/4.9.0-0.bpo.6-amd64/build -> /usr/src/linux-headers-4.9.0-0.bpo.6-amd64

lsb_release -is
Devuan

@aerusso
Copy link
Contributor

aerusso commented May 24, 2018

@Ryushin You're building on Devuan (not Debian). I'll update the logic in that patch to support that as well. In the future, please be very clear about what distribution you are building.

EDIT: @Ryushin Is Devuan reversing Debian's decision to divide build and source? I think the logic I just pushed should be good enough, but you're going to need to retest it on all versions.

aerusso added a commit to aerusso/zfs that referenced this issue May 24, 2018
scripts/dkms.mkconf calls configure with

`--with-linux=${kernel_source_dir}`, but Debian puts it kernel source at
`/lib/modules/<version>/source`. This patch adds the same logic to the
DKMS file produced by `scripts/dkms.mkconf` that Debian has shipped in
its official ZFS packaging: at DKMS build time, it checks if the system
is a Debian system, and adjusts the path accordingly.

Signed-off-by: Antonio Russo <antonio.e.russo@gmail.com>
Closes openzfs#7358 openzfs#7540
@Ryushin
Copy link

Ryushin commented May 25, 2018

@aerusso The problem is still occurring with Devuan Ceres, Devuan Jessie and Devuan Ascii.

@Serphentas is running Debian Stretch so I don't think there is an issue between Devuan or Debian.

Running a find command for mmzone.h results it nothing being found:
find /lib/modules/4.9.0-0.bpo.6-amd64 -name "mmzone.h"

locate for mmzone.h shows the following:
locate mmzone.h
/usr/src/linux-headers-3.16.0-6-common/arch/x86/include/asm/mmzone.h
/usr/src/linux-headers-3.16.0-6-common/include/linux/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/alpha/include/asm/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/arm64/include/asm/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/m68k/include/asm/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/mips/include/asm/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/mips/include/asm/mach-ip27/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/mips/include/asm/mach-loongson64/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/parisc/include/asm/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/powerpc/include/asm/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/s390/include/asm/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/sh/include/asm/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/sparc/include/asm/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/arch/x86/include/asm/mmzone.h
/usr/src/linux-headers-4.9.0-0.bpo.6-common/include/linux/mmzone.h

Odd that it is not picking up the correct kernel source directory. I made a quilt patch for your changes in scripts/dkms.mkconf and I've verified that the patch has been applied. Strange that this is happening with 0.7.9-2 and not 0.7.6-1.

New config log:
config.log

@aerusso
Copy link
Contributor

aerusso commented May 25, 2018

@Ryushin Does (in a cleanly unpacked source directory with #7554 applied) ./autogen.sh ; ./configure --with-config=user ; make deb-dkms, and then installing that deb give you that error?

If you are experiencing a problem with a particular distribution's packaging of ZFS, you should report it on their bugtracker.

tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Aug 15, 2018
scripts/dkms.mkconf calls configure with
`--with-linux=${kernel_source_dir}`, but Debian puts it kernel source at
`/lib/modules/<version>/source`. This patch adds the same logic to the
DKMS file produced by `scripts/dkms.mkconf` that Debian has shipped in
its official ZFS packaging: at DKMS build time, it checks if the system
is a Debian system, and adjusts the path accordingly.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Antonio Russo <antonio.e.russo@gmail.com>
Closes openzfs#7358 
Closes openzfs#7540 
Closes openzfs#7554
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Aug 23, 2018
scripts/dkms.mkconf calls configure with
`--with-linux=${kernel_source_dir}`, but Debian puts it kernel source at
`/lib/modules/<version>/source`. This patch adds the same logic to the
DKMS file produced by `scripts/dkms.mkconf` that Debian has shipped in
its official ZFS packaging: at DKMS build time, it checks if the system
is a Debian system, and adjusts the path accordingly.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Antonio Russo <antonio.e.russo@gmail.com>
Closes openzfs#7358 
Closes openzfs#7540 
Closes openzfs#7554
tonyhutter pushed a commit to tonyhutter/zfs that referenced this issue Sep 5, 2018
scripts/dkms.mkconf calls configure with
`--with-linux=${kernel_source_dir}`, but Debian puts it kernel source at
`/lib/modules/<version>/source`. This patch adds the same logic to the
DKMS file produced by `scripts/dkms.mkconf` that Debian has shipped in
its official ZFS packaging: at DKMS build time, it checks if the system
is a Debian system, and adjusts the path accordingly.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Antonio Russo <antonio.e.russo@gmail.com>
Closes openzfs#7358 
Closes openzfs#7540 
Closes openzfs#7554
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Building Indicates an issue related to building binaries
Projects
None yet
Development

No branches or pull requests

5 participants