fails to build on kernel 5.16, rocky linux, standard kernel-ml package

[syleishere]

CC [M] /var/lib/dkms/zfs/2.0.7/build/module/zfs/vdev_raidz_math_avx2.o
CC [M] /var/lib/dkms/zfs/2.0.7/build/module/zfs/vdev_raidz_math_avx512f.o
CC [M] /var/lib/dkms/zfs/2.0.7/build/module/zfs/vdev_raidz_math_avx512bw.o
/var/lib/dkms/zfs/2.0.7/build/module/zfs/../os/linux/zfs/zvol_os.c: In function 'zvol_os_create_minor':
/var/lib/dkms/zfs/2.0.7/build/module/zfs/../os/linux/zfs/zvol_os.c:1075:3: error: ignoring return value of 'add_disk', declared with attribute warn_unused_result [-Werror=unused-result]
add_disk(zv->zv_zso->zvo_disk);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[5]: *** [scripts/Makefile.build:287: /var/lib/dkms/zfs/2.0.7/build/module/zfs/../os/linux/zfs/zvol_os.o] Error 1
make[5]: *** Waiting for unfinished jobs....
LD [M] /var/lib/dkms/zfs/2.0.7/build/module/zstd/zzstd.o
make[4]: *** [scripts/Makefile.build:549: /var/lib/dkms/zfs/2.0.7/build/module/zfs] Error 2
make[3]: *** [Makefile:1846: /var/lib/dkms/zfs/2.0.7/build/module] Error 2
make[3]: Leaving directory '/usr/src/kernels/5.16.5-1.el8.elrepo.x86_64'
make[2]: *** [Makefile:49: modules-Linux] Error 2
make[2]: Leaving directory '/var/lib/dkms/zfs/2.0.7/build/module'
make[1]: *** [Makefile:898: all-recursive] Error 1
make[1]: Leaving directory '/var/lib/dkms/zfs/2.0.7/build'
make: *** [Makefile:759: all] Error 2

router:/usr/src/zfs-2.0.7 # uname -a
Linux router 5.16.5-1.el8.elrepo.x86_64 #1 SMP PREEMPT Mon Jan 31 19:03:05 EST 2022 x86_64 x86_64 x86_64 GNU/Linux
router:/usr/src/zfs-2.0.7 # cat /etc/redhat-release
Rocky Linux release 8.5 (Green Obsidian)
router:/usr/src/zfs-2.0.7 #

[rincebrain]

#13042 #12971, to pick two - tl;dr 5.16 is not supported at the moment.

[Moerten]

I have the same problem. On "dnf update" Fedora wants to remove the zfs/zfs.dkms packages. What is the preffered action now. Will this kernel ever be supported or is it skipped? It feels not good not being able to install updates.

[rincebrain]

The "dnf update" thing is because they updated the zfs-fuse package, I believe.

There are updates that support 5.16 in git tip. A release with them is being prepared, but there's always going to be a time delay between "latest software breaks build" and "stable release branch gets updates for latest software".

If you dislike the kernel updates randomly breaking you, my suggestions would be either hold off on installing them for a while after they come out, or perhaps use a distro that doesn't regularly ship breaking kernel changes during a release's lifetime. (You could also run OpenZFS git tip, but that's just going to shorten the delay, not eliminate it.)

(This isn't meant as shade at Fedora - my advice would be the same for any distro that has that level of churn but forbids maintaining their own OpenZFS package (where a maintainer could cherrypick and test fixes like this in their environment faster) by policy (they forbid having any out of tree modules in their repos).)

[syleishere]

The real issue is most people are going to be stuck using last kernel 5.15 kernel-ml package if using zfs, meaning a lot of systems are going to remain exploitable as there was a security issue released. 5.17 is currently main development branch, 5.16 was branched off months ago now still leaving people vulnerable unless they compiling their own 5.15 kernels from scratch as kernel-ml branch is now 5.16.

[hvdijk]

In 5.18 kernels, CONFIG_WERROR is enabled in X86 make defconfig, making it much more likely for this to be an issue (see https://lore.kernel.org/all/YjwsUT%2F6PkRPjnHE@gmail.com/). zfs 2.1.5 cannot be built with Linux 5.18 in defconfig builds because of this.

[hvdijk]

Actually... Looking into the code, this is meant to be handled already now. There's a configure-time check, "checking whether add_disk() returns int...", and there is code to address the warning that prompted this bug. The reason I'm still seeing this in 5.18 is that for me, this configure-time check returns "no", when the correct answer is "yes", which is a separate issue. I suggest closing this one, assuming it truly is supposed to be fixed. For the incorrect configure-time check, I will open a new issue later (unless I can find that the reason for the incorrect configure-time check is a local problem).

[rincebrain]

If you're using clang, it might be that 2.1.5 is missing 9884319, but yeah, sounds like a different issue now.

[szubersk]

@hvdijk @syleishere both the original issue and the configure-time check were fixed in 9884319, feel free to cherry-pick the fix.

I think this issue can be closed.