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)

This information is outdated, your best bet is to follow the discussion on github as nobody is really sure at the moment.

Finding out exactly what got corrupted seems to be difficult/impossible. Active discussions:

https://github.com/openzfs/zfs/issues/15526
https://github.com/openzfs/zfs/issues/15554

All of this requires coreutils v9+ (not sure of the exact version), which you almost certainly have.
The second requirement is that you have either:

1. Run zpool upgrade after upgrading to 2.2.0, or manually enabled feature@block_cloning.

2. Created a pool while on 2.2.0 as it was enabled by default.

You can check if the feature is enabled at all with something like:

zpool get all | grep block_cloning

If it's disabled, you are not affected by this.
If it's enabled, there seems to be a solution mentioned in the discussions linked above, but I haven't looked into it. If nothing works, temporarily downgrading coreutils may be a solution.

A good rule of thumb is to avoid upgrading your pool or enabling features that you don't really need or want.
Enabling features is a one-way street, and it is not really possible to roll back.

Thanks a lot for the 2.2.1 update! I am currently reading things about a really serious data corruption bug (WHOOPS!) in the 2.2.0 version with the new Block Cloning feature.

So I am switching back from the archzfs source (https://github.com/archzfs/archzfs) to this one here, because that one is still on 2.2.0.

No idea if I am affected by problems already. I have not been super active on my fileserver last month so maybe I am lucky.

Update (2023-11-27): I never ran zpool upgrade after the upgrade to 2.2.0. Problems are less likely in my case.

Personally I am going to wait with the running the command for a bit longer, at least until 2.2.2 and when they have actually figured out the entire problem. Just to be sure.

ZFS 2.2.1, with official Linux 6.6 support, has been released:

https://github.com/openzfs/zfs/releases/tag/zfs-2.2.1

@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.