Bug#915886: zfs-dkms: module FTBFS for 4.18.0-3-amd64: NR_FILE_PAGES in either node_stat_item or zone_stat_item: NOT FOUND
Hi anbe, Do you still have any idea about the way to reproduce this failure? I've added an autopkgtest script to zfs to test the dkms build against linux-headers-$(dpkg --print-architecture), and it seems that I cannot reproduce this issue in a clean and minimal chroot. http://debomatic-amd64.debian.net/distribution#unstable/zfs-linux/0.7.12-2/autopkgtest
Bug#915886:
Ben, I'm pretty sure you're not having the same problem as the original person. They were reporting getting a Perl error out of the enum-extract script, you're reporting that it's passing the wrong location to the enum-extract script to try and find the header. - Rich
Bug#915886: enum-extract.pl output
This script fails because the include file passed to it doesn't exist: cd /var/lib/dkms/zfs/0.7.12/build sudo ./scripts/enum-extract.pl node_stat_item /lib/modules/4.19.0-1-amd64/build/include/linux/mmzone.h Can't open /lib/modules/4.19.0-1-amd64/build/include/linux/mmzone.h: No such file or directory at ./scripts/enum-extract.pl line 26. The include (mmzone.h in this case) doesn't exist because 'build' points to the CPU specific include directory and not the 'common' include directory: ls -l /lib/modules/4.19.0-1-amd64/build lrwxrwxrwx 1 root root 37 Dec 11 21:24 /lib/modules/4.19.0-1-amd64/build -> /usr/src/linux-headers-4.19.0-1-amd64 ls -l /lib/modules/4.19.0-1-amd64/build/include total 44 drwxr-xr-x 715 root root 36864 Dec 19 21:13 config drwxr-xr-x 3 root root 4096 Dec 19 21:13 generated I don't think the extraction script is the problem. It appears the problem is in the 'zfs-dkms' configure script because it doesn't look for include files under '/lib/modules/4.19.0-1-amd/*source*.
Bug#915886: Workaround
So, yes, the workaround Ben posted will work, but that's fixing the symptom, not the problem. I'd still like to know what the enum-extract.pl script says for you (Ben) if you try invoking it (or what's in config.log when it fails). Because the problem with the common/amd64 headers location should be fixed already [1], it's possible you're having a separate problem; that error output is just what happens when enum-extract.pl doesn't output what's expected. - Rich [1] - https://github.com/zfsonlinux/zfs/issues/7358
Bug#915886: Probable work-around
The issue is that Debian delivers Linux headers in two directories, each of which is linked under /lib/modules. On my system, with 4.14, these symlinks are under /lib/modules/4.14.0-3-amd64: cd /lib/modules/4.14.0-3-amd64 ls -ld build source lrwxrwxrwx 1 root root 37 Jan 25 2018 build -> /usr/src/linux-headers-4.14.0-3-amd64 lrwxrwxrwx 1 root root 38 Jan 25 2018 source -> /usr/src/linux-headers-4.14.0-3-common The zfs-dkms 'configure' script assumes the Linux include files are accessible via the 'build' symlink but that only provides access to amd64 CPU dependent files. All the rest of the linux header files are accessible via 'source' which points to the 'common' header files. That breaks the zfs-dkms build when 'dkms' runs the 'configure' command. The work-around creates a symlink to /usr/src/linux-headers-4.14.0-3-common/include/linux under linux-headers-4.14.0--amd64 so the configure script can find the files it needs: cd /usr/src/linux-headers-4.14.0-3-amd64 ln -s /usr/src/linux-headers-4.14.0-3-common/include/linux . Now 'build/include/linux' points to the linux headers: ls -l /lib/modules/4.14.0-3-amd64/build/include/ total 76 drwxr-xr-x 698 root root 69632 Dec 19 09:54 config drwxr-xr-x 3 root root 4096 Dec 19 09:54 generated lrwxrwxrwx 1 root root 52 Dec 19 11:22 linux -> /usr/src/linux-headers-4.14.0-3-common/include/linux Substitute your kernel version du jour for 4.14.0-3. I've only tested this with 4.14 so YMMV with other kernel versions.
Bug#915886: NR_FILE_PAGES is present
I checked the Linux headers and each kernel defines NR_FILE_PAGES as a member of the node_stat_item enumeration in include/linux/mmzone.h. I'm running on MX-17, which is derived from Debian Stable, and the headers are in: /usr/src/linux-headers-4.14.0-3-common (using 4.14.0-3 as my current kernel). So, the kernel include files appear to be correct. As a point of reference, I still have ZFS 0.7.6 running on my primary server and the older ZFS doesn't check for NR_FILE_PAGES at all in its configure scripts. That's new behavior that's been introduced later and is now in 0.7.12. (I saw the added code while grepping for NR_FILE_PAGES). Seems like that logic is the place to look for this bug. Please LMK if I can help run experiments or try solutions. I have the broken ZFS 0.7.12 on a VM, also running MX-17, that I use to test major upgrades before putting them on my main machine. Thanks, Ben
Bug#915886: Additional Debug Data
I'm also hitting this bug so I've collected the data requested by Rich: b@mx17:~$ dpkg -l | egrep '^ii perl-' ii perl-base 5.24.1-3+deb9u5 amd64minimal Perl system ii perl-modules-5.24 5.24.1-3+deb9u5 all Core Perl modules ii perl-openssl-defaults:amd64 3 amd64version compatibility baseline for Perl OpenSSL packages b@mx17:~$ ls -l /usr/share/perl/5.24*/Getopt/Std.pm -rw-r--r-- 1 root root 8790 Nov 29 06:11 /usr/share/perl/5.24.1/Getopt/Std.pm -rw-r--r-- 1 root root 8790 Nov 29 06:11 /usr/share/perl/5.24/Getopt/Std.pm As you can see, my box has GetOpt and yet it has the same dkms error: checking global_page_state enums are sane... no NR_FILE_PAGES in either node_stat_item or zone_stat_item: NOT FOUND configure needs updating, see: config/kernel-global_page_state.m4 configure: error: in `/var/lib/dkms/zfs/0.7.12/build': configure: error: SHUT 'ER DOWN CLANCY, SHE'S PUMPIN' MUD! See `config.log' for more details -Ben McCann
Bug#915886:
Well, the PUMPIN MUD just means enum-extract.pl didn't do the right thing. config.log.gz says: configure:26532: ./scripts/enum-extract.pl zone_stat_item /lib/modules/4.18.0-3-amd64/source/include/linux/mmzone.h | egrep -qx NR_SLAB_RECLAIMABLE Can't locate Getopt/Std.pm in @INC (you may need to install the Getopt::Std module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/ share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at ./scripts/enum-extract.pl line 13. BEGIN failed--compilation aborted at ./scripts/enum-extract.pl line 13. So that is claiming it doesn't think you have Getopt/Std.pm, which should be provided by perl-modules-$(PERL_MAJOR_MINOR_VERSION) (e.g. in your case, 5.28). What do dpkg -l | egrep '^ii perl-' and ls -l /usr/share/perl/5.28*/Getopt/Std.pm have to say? (Regardless of what they have to say, there should definitely be an explicit perl dep in zfs-dkms now, since that definitely won't work without it.) - Rich
Bug#915886: zfs-dkms: module FTBFS for 4.18.0-3-amd64: NR_FILE_PAGES in either node_stat_item or zone_stat_item: NOT FOUND
Package: zfs-dkms Version: 0.7.12-1 Severity: serious Hi, # dkms build -k 4.18.0-3-amd64 zfs/0.7.12 Kernel preparation unnecessary for this kernel. Skipping... Running the pre_build script: checking for gawk... no checking for mawk... mawk checking metadata... META file checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking whether to enable maintainer-specific portions of Makefiles... no checking whether make supports nested variables... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking whether make sets $(MAKE)... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of gcc... none checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for a working dd... /bin/dd checking how to truncate binary pipes... /bin/dd bs=4096 count=1 checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking dependency style of gcc... none checking whether to build with code coverage support... no checking zfs author... OpenZFS on Linux checking zfs license... CDDL checking zfs config... kernel checking for -Wno-unused-but-set-variable support... yes checking for -Wno-bool-compare support... yes checking whether host toolchain supports SSE... yes checking whether host toolchain supports SSE2... yes checking whether host toolchain supports SSE3... yes checking whether host toolchain supports SSSE3... yes checking whether host toolchain supports SSE4.1... yes checking whether host toolchain supports SSE4.2... yes checking whether host toolchain supports AVX... yes checking whether host toolchain supports AVX2... yes checking whether host toolchain supports AVX512F... yes checking whether host toolchain supports AVX512CD... yes checking whether host toolchain supports AVX512DQ... yes checking whether host toolchain supports AVX512BW... yes checking whether host toolchain supports AVX512IFMA... yes checking whether host
