ZFS 0.7.12-1-mx17+1 Wont Build

[Viking73]

The latest set of upgrades (within the last week) broke ZFS on my MX-17 system. I had been running the previous version of MX ZFS (0.7.6-1-mx17+1) without issue but now ZFS won't build due to an error in the zfs-dkms 0.7.12-1-mx17+1 configure script. Somebody else hit this (probably on Debian) and filed bug 915886 in the Debian bug tracking system. (See https://bugs.debian.org/cgi-bin/bugrepo ... bug=915886). I added some additional data to that bug describing the failure on my MX-17 virtual machine.

I'd like to revert back to the previous version of ZFS (0.7.6-1-mx17+1) but it is no longer offered as an Available Version in Synaptic on MX-17. Could you roll back to 0.7.6 or add it as another supported additional version until bug 915886 against ZFS 0.7.12 is fixed? Right now, the MX version of ZFS is just useless.

My other option is reverting all the way back to the ZFS provided by Debian stable. That is version 0.6.5.9-5 and I'm afraid that the 0.7 series of ZFS may have on-disk metadata that is not forward compatible with 0.6.5.9. I would hate to blow up my zpool by reverting back from 0.7.6 to 0.6.5.9.

[timkb4cq]

The zfs-linux 0.7.9 is still available in the MX-17 Test repository. You should be able to enable Test and force downgrade in Synaptic. Just make sure to disable Test afterwards.

[Stevo]

0.7.12 builds are also successful on 4.19 kernels, at least in my tests, so that's another option.

[Viking73]

Thanks, but neither of those solutions worked for me.

• Synaptic had fits with Broken Dependencies when I tried to roll back to version 0.7.9. There are about 8 packages associated with ZFS and I couldn't get all of them to roll back at once. Don't know why and don't have patience to figure it out.
• I had previously tried 4.19, and I tried again, but neither attempt worked. In both cases ZFS failed during 'configure'. I think this makes sense because the configuration script, which I think is broken, is delivered with ZFS-DKMS and not with the kernel. ZFS 0.7.12 won't build against 4.13, 4.14, and 4.19 on my system.

I'm going to attempt to roll back to the Debian Stable version of ZFS. I can then check ZFS metadata version and feature flags against 0.7.6 on my primary server to see if rolling back that server will break my zpools.

Please excuse a rant, but I'm confused and a bit annoyed that ZFS 0.7.12 was released to the MX stable repository when the testing repository was still back at 0.7.9. That seems like a pretty big process error. Why would a newer, and untested version (0.7.12) leapfrog an older version (0.7.9) in testing and find its way to stable? ZFS version 0.7.9 should have been promoted into MX stable and then 0.7.12 could have been tested in MX testing. Isn't that what the testing repository is for?

Is there a better forum for me to point this out and for me to request someone revert this (IMHO) mistake?

-Ben

[Viking73]

I found a solution on the ZoL githib site (https://github.com/zfsonlinux/zfs/issue ... -379465591). The configure script fails because it can't find the Linux include files, apparently because Debian split the include files include CPU independent and dependent subdirectories. (These are named 'common' and 'amd64'). The 'build' link created by DKMS points amd64 and hence can't find any of the files in 'common'.

If you create a symlink under 'amd64' over to 'include/linux' under 'common' then the build succeeds. This is a complete hack but it gets the job done:

cd /usr/src/linux-headers-${kernel_ver}-amd64
ln -s /usr/src/linux-headers-${kernel_ver}-common/include/linux .

With this in place, zfs-0.7.12 compiles and (with very cursory testing) appears to work.

FWIW, my other MX-17 machine, which hasn't been upgraded to ZFS 0.7.12, does not have this hack. I don't know why ZFS 0.7.6 builds successfully there but it does...

-Ben

[Stevo]

We updated to 0.7.12 from stretch-backports because it is the only version that will build on our new MX 18 default 4.19 kernel, and built without any problems in my testing with that kernel. It "just worked" in my test.

I'm not sure what the "common" package you're referencing is--I can't find anything related to zfs like that. The Recommended packages for zfs-dkms, installed by default in Debian but not in MX, are

Code: Select all

Recommends: zfs-zed, zfsutils-linux (>= 0.7.12-1~mx17+1), linux-libc-dev (<< 4.20~)

if those make any difference. If it's the new linux-libc-dev, I can switch that to a hard dependency.

[Viking73]

Sorry, I should have been more clear about 'common'. 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' headers. That breaks the zfs-dkms build when 'dkms' runs the 'configure' command.

The fix links /usr/src/linux-headers-4.14.0-3-common/include/linux under linux-headers-4.14.0-3-amd64 so the configure script can find the files it needs. This creates the symlink:

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.