Arch Linux User Repository

When requesting changes, please include detailed reasoning for the change.

If you receive this error when trying to build, it is because you have not imported the GPG keys used for verification.

==> ERROR: One or more PGP signatures could not be verified!

You have two options:

1) Import the two keys into your keyring. ArchWiki article. You can find the key IDs in the PKGBUILD file, in the validpgpkeys array. (recommended)

2) Alternatively, you can skip this verification by passing the --skippgpcheck argument to makepkg when building. (not recommended)

The zfs stuff is not cleanly uninstalled when I remove a kernel. There are leftovers in /usr/lib/modules/KERNEL/build. See also this issue for zfs: https://github.com/openzfs/zfs/issues/16221 This seems to be an issue with automake as explained by the dksm developers: https://github.com/dell/dkms/issues/418 The solution should be to add "no-dependencies" into configure.ac https://www.gnu.org/software/automake/manual/automake.html#Dependencies Is that something that could be added to the PKGBUILD?

@sphere101 - keep an eye on zfs releases for kernel support

Hello, Any update on when zfs-dkms will be updated to support kernel 6.9.x? Thank you.

@sausix: in the past you could compile zfs for a non supported kernel and if the compilation was successful you could use zfs for the unsupported kernel and eventually end up with data corruption. Thats the reason why the devs have implemented a check that prevents compilation for unsupported kernel version. You have seen this message when you tried to compile for kernel 6.9. zfs is always lagging behind kernel version support. This lies in the nature of the out-of-tree development process. There is nothing to be frightend about. Love it or leave it.

@mabod I've read about the warning yesterday. Some people call it "danger zone" and I picked the term up here (subconciously): https://github.com/openzfs/zfs/pull/15931 Someone had a corruption already. The kernel devs probably don't care for breaking changes to ZFS. And they won't break it on purpose.

@itoffshore linux-lts sounds reasonable. linux-hardened is on 6.9.5 too and exceeds the maximum kernel version: Linux-Maximum: 6.8

Most people will use ZFS with older kernels because of lts or just having an old kernel on their NAS boxes I guess.
I know. Always have a backup. But it still may corrupt my new unbackupped data. I want to try RaidZ expansion which is experimental enough.

I definitely will use linux-lts but I'm still wondering it isn't recommended here at least. The warning and the huge kernel version difference is frightening enough for me.

@sausix - I run linux-lts & linux-hardened (built with arch-sign-modules so the zfs modules are signed) - I find that linux-lts always builds & never needs a rebuild when gcc changes to a new major version.

As I build my own kernels & add them to IgnorePkg in /etc/pacman.conf, needing to stick on a minor version of my preferred (non LTS) kernel is not an issue. This has worked well for at least 5 years. When zfs-dkms changes, the first thing I check is the zfs release on Github - this shows the supported kernel versions.

@sausix: zfs ist not in "danger zone" ;-) What you see here is the typical scenario for zfs to catch up with the changes in the newest kernel. This is normal and can take a while. If you use zfs you should consider to use an LTS kernel.

==> dkms install --no-depmod zfs/2.2.4 -k 6.9.5-arch1-1
configure: error: 
        *** Cannot build against kernel version 6.9.5-arch1-1.
        *** The maximum supported kernel version is 6.8.

So ZFS is in danger zone because of the developers can't follow the Kernel's release frequency. Am I correct? Should at least be pinned here.

@FrederickZh Thanks for the accurate analysis. I've appended ?full_index=1 to the source URL for that patch.

Folks, the last commit here in this package was committed on 2 May. The commit that added 2b481b5477d3a95d0eab723c6639f7114e146ae1.patch was even older.

What happened was that https://github.com/openzfs/zfs/commit/2b481b5477d3a95d0eab723c6639f7114e146ae1.patch started returning index hashes with 11 characters, while it used to return 12 characters, e.g. index 000000000000..ffb4997e8b14 instead of index 00000000000..ffb4997e8b1.

To avoid such issues, it's better to use https://github.com/openzfs/zfs/commit/2b481b5477d3a95d0eab723c6639f7114e146ae1.patch?full_index=1. It has nothing to do with not running updpkgsums.