Consider switching CONFIG_PREEMPT to allow zfs module compilation with default kernel8.img

[satmandu]

zfs doesn't compile on arm64 with CONFIG_PREEMPT=y due to an issue mentioned here openzfs/zfs#8545 with the GPL-only symbol 'preempt_schedule_notrace'

The workaround mentioned here openzfs/zfs#8545 (comment) is to have CONFIG_PREEMPT_VOLUNTARY=y set instead.

Compiling arm64 zfs-dkms from ubuntu gives this error:

Building module:
cleaning build area...
make -j4 KERNELRELEASE=5.4.29-v8+................................................................(bad exit status: 2)
ERROR (dkms apport): kernel package linux-headers-5.4.29-v8+ is not supported
Error! Bad return status for module build on kernel: 5.4.29-v8+ (aarch64)
Consult /var/lib/dkms/zfs/0.8.3/build/make.log for more information.
...

FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'preempt_schedule_notrace'
make[4]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make[3]: *** [Makefile:1607: modules] Error 2
make[3]: Leaving directory '/usr/src/rpi-linux'
make[2]: *** [Makefile:30: modules] Error 2
make[2]: Leaving directory '/var/lib/dkms/zfs/0.8.3/build/module'
make[1]: *** [Makefile:807: all-recursive] Error 1
make[1]: Leaving directory '/var/lib/dkms/zfs/0.8.3/build'
make: *** [Makefile:676: all] Error 2

Expected behaviour
The zfs module compiles successfully. (It does with the default ubuntu focal kernel.)

[satmandu]

Compilation steps on an ubuntu system to show error:

#!/bin/bash
# Assumption that one is running on the current kernel8.img 5.4 series kernel.
kver=$(uname -r)
src_temp=$(mktemp -d rpi_src_XXXi -p /tmp)
FIRMWARE_REV=$(git ls-remote "https://github.com/Hexxeh/rpi-firmware" refs/heads/next | awk '{print $1}')
cd $src_temp && curl -OLf https://github.com/Hexxeh/rpi-firmware/raw/next/git_hash
KERNEL_REV=$(cat $src_temp/git_hash)
cd $src_temp
curl -L https://github.com/raspberrypi/linux/archive/${KERNEL_REV}.tar.gz >rpi-linux.tar.gz
curl -OLf https://github.com/Hexxeh/rpi-firmware/raw/${FIRMWARE_REV}/Module8.symvers
cd /usr/src && ( sudo mv rpi-linux rpi-linux.old || true)
cd /usr/src && sudo mkdir rpi-linux
cd /usr/src && (sudo rm -rf rpi-linux.old || true)
cd rpi-linux && sudo tar --strip-components 1 -xf ${src_temp}/rpi-linux.tar.gz
sudo cp $src_temp/Module8.symvers Module.symvers
rm -rf $src_temp
sudo modprobe configs
sudo gunzip -c /proc/config.gz |sudo tee /usr/src/rpi-linux/.config
cd /usr/src/rpi-linux && sudo make modules_prepare
sudo rm -f /usr/lib/modules/$(uname -r)/build || true
sudo ln -sv /usr/src/rpi-linux /usr/lib/modules/$(uname -r)/build
sudo dkms build zfs/0.8.3 -k 5.4.29-v8+ --kernelsourcedir=/usr/src/rpi-linux --no-prepare-kernel

Yes please. I would need to move my main Pi 4B to Ubuntu 20.04 if this doesn't get changed on Raspbian.

Test version of 5.4.35 available via rpi-update still shows the same issue. So my combined NAS and network music player is getting switched over to Ubuntu 20.04. I will need to deploy another Pi running Raspbian for Kodi - hopefully won't waste too much power.

[JamesH65]

Note that 5.4 has not yet been released for the Pi (still under testing), so things might change. @popcornmix @pelwell Thoughts? No idea of the implications of this.

[popcornmix]

We're not going to change the pre-emption method of the kernel which has the potential to change behaviour for all users, for a non-upstream kernel module that has difficulty building.

I had a feeling that would be the case - thanks for confirming. That certainly makes sense given that would be a pretty major change to the whole kernel, from what little I know about such things.

Gives me an excuse to dust off another spare Pi 🙃

[satmandu]

Thanks for the constructive feedback, all!

It looks like this may be a moot issue though due to the upcoming zfs 0.8.4 which appears to work around this as per discussion here: openzfs/zfs#10209 (comment)

I'm looking forward to trying a newer 0.8.4 based zfs-dkms at some point soon with a stock kernel 5.4 based kernel8.img...

Thanks for the constructive feedback, all!

It looks like this may be a moot issue though due to the upcoming zfs 0.8.4 which appears to work around this as per discussion here: openzfs/zfs#10209 (comment)

I'm looking forward to trying a newer 0.8.4 based zfs-dkms at some point soon with a stock kernel 5.4 based kernel8.img...

Oooh, interesting. 🐧

[satmandu]

FYI The 0.8.4 patches do not resolve this issue.

The quickest way to fix this is on your personal system to modify the license in the META file in /usr/src/zfs-0.8.* to say GPL instead of CDDL like so;

License:       GPL

And then run ./autogen.sh in that folder, and have dkms rebuild the module.
I have confirmed that with this change you can get zfs-0.8.3 to work with the rpi rpi-5.6.y branch kernels, and also with the released rpi-5.4.y kernels.

Also FYI, if you need a kernel/header package installed of the official kernels, so you can easily install RPI kernels on non-raspbian systems, this script might help: https://gist.github.com/satmandu/a507c59d84737f6d29ff353395819d51

FYI The 0.8.4 patches do not resolve this issue.

The quickest way to fix this is on your personal system to modify the license in the META file in /usr/src/zfs-0.8.* to say GPL instead of CDDL like so;

License:       GPL

And then run ./autogen.sh in that folder, and have dkms rebuild the module.
I have confirmed that with this change you can get zfs-0.8.3 to work with the rpi rpi-5.6.y branch kernels, and also with the released rpi-5.4.y kernels.

Also FYI, if you need a kernel/header package installed of the official kernels, so you can easily install RPI kernels on non-raspbian systems, this script might help: https://gist.github.com/satmandu/a507c59d84737f6d29ff353395819d51

Thanks for the info. I've already switched to Ubuntu 20.04 aarch64 on my Pi-based NAS / music player 😷😁