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)

@fryfrog, thank you for the suggestion, but I built zfs-utils as well. I have a script that builds both because of that "this version conflicts" issue (can't find the right error now).

So both zfs-dkms and zfs-utils are freshly built.

@dhathaway: I'd try rebuilding zfs-utils, that is the package that owns libzfs.so on my system (though I use archzfs repo, not aur).

I froze my kernal at 6.4.12-arch1-1 and had zfs 2.2.0 running since it came out.

Yesterday, my power went out, and when the machine came back on, my zfs pool wasn't mounted. I used:

sudo zpool import -a -d (etc)

I receive:

Failed to initialize the libzfs library

I get the same error with zfs set.

I rebuilt the package and reinstalled, with the same result.

What is the solution?

I've been running a version of 2.2.0 patched with the PR linked by @mabod, https://github.com/openzfs/zfs/pull/15263, with the linux-zen 6.6 kernel for the last few days without issue.

For anyone else feeling adventurous:

diff --git a/PKGBUILD b/PKGBUILD
index bd16b02..f5a0e10 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -4,7 +4,7 @@

 pkgname=zfs-dkms
 pkgver=2.2.0
-pkgrel=1
+pkgrel=2
 pkgdesc="Kernel modules for the Zettabyte File System."
 arch=('any')
 url="https://zfsonlinux.org/"
@@ -13,12 +13,15 @@ provides=("ZFS-MODULE=${pkgver}" "SPL-MODULE=${pkgver}")
 # ambiguous, provided for backwards compat, pls don't use
 provides+=('zfs')
 source=("https://github.com/zfsonlinux/zfs/releases/download/zfs-${pkgver}/zfs-${pkgver}.tar.gz"{,.asc}
+        "https://patch-diff.githubusercontent.com/raw/openzfs/zfs/pull/15263.patch"
         "0001-only-build-the-module-in-dkms.conf.patch")
 sha256sums=('42035fd059faa25a09cd511b24a57b8ad1285cb69127f2a0043b98562c5ec690'
             'SKIP'
+            'c2da9ec5d15335fa35b3380d66ff1da1f1cb2e173ac7eb8fb0c9205de8d1fad0'
             '8d5c31f883a906ab42776dcda79b6c89f904d8f356ade0dab5491578a6af55a5')
 b2sums=('80d94cd5ef0bbeaa570853c10f480e3cd64cb852b53aced2e7d382d097130fcf8f94060126a04321f913bca5d9158813a74e97f1dd0f110359d911a33e4a0d77'
         'SKIP'
+        '055cbcc9ba68323b48bf4fb9763fd24f5a865d3976237d744371fd6cfe5b8f9faf7d04e16e8a21f9366af19b6f322164869f7c6b0192c838f4d9bfa72ca8f7b9'
         '58dc2494e71b50833d44c126b72acad52e9817626542afbc245b7ba82009e8c8252ebde6023592aac42d9942207e7655c0a421da9067fbdd619746ebc372d791')
 validpgpkeys=('4F3BA9AB6D1F8D683DC2DFB56AD860EED4598027'  # Tony Hutter (GPG key for signing ZFS releases) <hutter2@llnl.gov>
               'C33DF142657ED1F7C328A2960AB9E991C6AF658B') # Brian Behlendorf <behlendorf1@llnl.gov>
@@ -26,6 +29,7 @@ validpgpkeys=('4F3BA9AB6D1F8D683DC2DFB56AD860EED4598027'  # Tony Hutter (GPG key
 prepare() {
     cd "${srcdir}"/${pkgname%-dkms}-${pkgver}

+    patch -p1 -i ../15263.patch
     patch -p1 -i ../0001-only-build-the-module-in-dkms.conf.patch

     # remove unneeded sections from module build

@meithan - thanks for your articulate summary, which I hope newer ZFS users find useful. Agreed on using linux-lts as an interim solution, especially for those concerned about maintaining system security while we wait for 6.6-x support.

simply not doing kernel (and system) upgrades

Yeah, that's what I'm usually doing: not upgrading kernel.

@Lernry: It just means that the module hasn't been properly tested with that newer kernel, so the ZFS devs can't guarantee that it will work. From my experience, it is usually the case that ZFS will compile and "work fine" with a newer, not officially supported kernel.

The problem is that "usually" means "not always", as I recently learned personally. Sometimes the newer kernel does introduce changes that break ZFS compatibility. And if you have root on ZFS like me, or simply really need a particular ZFS filesystem, that can be a real pain.

My recommendations from personal experience, and I've tried quite a bit of options (using ZFS with an unsupported kernel anyway if it compiles, simply not doing kernel (and system) upgrades, using plain zfs-linux or zfs-dkms or zfs-dkms-git):

• Don't use ZFS with an unsupported kernel; it may even compile and seem to work, but you're playing with fire (I recently put myself in quite a pickle by toying with this).

• If you can, simply delay kernel (and system) upgrades until a compatible ZFS module is released; in this case, just use zfs-linux since it will "automatically" block upgrades ("accidentally" upgrading your kernel and having ZFS fail to compile will brick your system if root on ZFS).

• If you really don't want to hold back other package upgrades while waiting, switch to the linux-lts kernel until a ZFS module compatible with the new kernel is released; this is the strategy I'm currently following.

I'm not complaining to anyone

@Lenry, what are you talking about? This is not about "believe". This is about compilation errors with newer kernel versions. They are real. And if you do not "believe" that, you can follow zfs upstream and check the pull requests which introduces kernel 6.6 compatibility: https://github.com/openzfs/zfs/pull/15263

By the way, this is not the right place to discuss your zfs complains. If you want to complain , you better complain directly to the zfs developers (https://github.com/openzfs/zfs)

Pretty much every other month the kernel bumps to a new "major" version. It's hard to believe they modify something related to ZFS all the time