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)

Works fine for me indeed. Builds for both kernels.

The archzfs version is still having the issues (forgot to mention, but I have been using that one for quite while now, but I switched back and forth more than once), so now we are back on this one on AUR again. :)

There was an update to this package on 2022-05-25 to handle kernel 5.18.

For anyone having issues with updating their kernel, make sure you update your zfs packages (aur) as well.

Currently working for me with:

zfs-dkms 2.1.4+65.r05147319b0-2

zfs-utils 2.1.4+65.r05147319b0-1

linux 5.18.1.arch1-1

@bazzawill - I set the ignore option in /etc/pacman.conf to not update my kernels with:

IgnorePkg = linux-lts* linux-hardened*

(I build & update my kernels manually with arch-sign-modules in AUR)

As @jongeduard mentioned if a build fails I just downgrade the kernel with pacman -U /path/to/kernel.pkg.zst /path/to/kernel-headers.pkg.zst if the zfs modules do not build.

The zfs modules mostly build without problems for me as linux-lts & linux-hardened are not bleeding edge like linux-zen. Rarely when there is major version change in gcc I have to rebuild a whole kernel as all modules fail to build with a differing gcc major version & a kernel built with a previous gcc.

@bazzawill I am using ZFS with Arch Linux for roughly a year now. I have had build failures view times now, but they should not be a problem if you do a view things right.

Most of them where during a new kernel version release, while ZFS was indeed not ready the newest kernel version. And with a version I mean like this upgrade from 5.17 to 5.18, not the revision/build number for each regular kernel update.

My main solution: I have simply both the regular kernel and the LTS kernel installed. Most of build failures I have had where with the regular kernel, while the build for the LTS version failed only 1 time.

And since the LTS kernel is still more stable an reliable in general, I can also recommend you to boot the LTS kernel by default, when it comes to a NAS / file server with ZFS like I built at home. Unless your hardware really modern that it requires the new kernel with the newest drivers. But the 5.15 LTS version is fine for me now. Actually the 5.10 (which was the previous of the LTS) was already perfect.

Another thing I can recommend: preserve your cached packages in /var/cache/pacman/pkg/ up to a view versions (don't clean your packages with pacman -Sc, but use paccache for this, which let's you selectively remove the oldest versions), such that you can downgrade your kernel if needed.

From within that folder you can simply run a downgrade like: sudo pacman -U linux-5.17.9.arch1-1-x86_64.pkg.tar.zst linux-headers-5.17.9.arch1-1-x86_64.pkg.tar.zst

Don't forget to also downgrade nvidia or wifi drivers or other kernel modules if you have them too, they each install into a specific /lib/modules/<kernel-version>/ folder, which needs to be of a matching version.

And finally: also permanently keep your locally stored zfs-dkms and zfs-utils that you cloned from git in a folder, in which you also keep your built packages, such that you can reinstall these when needed as well.

So I just switched from the zfs-linux kernel to the dkms package and then I get hit with this. Just wondering how often this might occur. The issue is my system auto updates and because I had a power outage my system restarted and then my drives did not mount. Yes I know running a rolling release distro this can happen and some oversight when upgrading is wise but...

@fryfrog

Thanks for the link. Basically they fixed a NULL referencing pointer-to-a-struct by actual defining the struct and giving that to the pointer (if you have ever learned some C programming you'll probably know what I mean).

I really like their statement "Ah yes, the fun of compilers getting smarter and noticing when we did something foolish.", because that's so true.

And these things are indeed a good thing, it helps getting a thing like ZFS getting more safe and stable.

Not being able to build something has often very good reasons.

There are a number of commits in github issue #13463, hopefully they'll make a new release soon that supports it.

Looks like 5.18 isn't supported yet so I had to downgrade my kernel in order to not break my system outright.

==> dkms install --no-depmod zfs/2.1.4 -k 5.18.0-zen1-1-zen
Deprecated feature: REMAKE_INITRD
configure: error: 
        *** None of the expected "blk_queue_discard" interfaces were detected.
        *** This may be because your kernel version is newer than what is
        *** supported, or you are using a patched custom kernel with
        *** incompatible modifications.
        ***
        *** ZFS Version: zfs-2.1.4-1
        *** Compatible Kernels: 3.10 - 5.17

Error! Bad return status for module build on kernel: 5.18.0-zen1-1-zen (x86_64)
Consult /var/lib/dkms/zfs/2.1.4/build/make.log for more information.
==> WARNING: `dkms install --no-depmod zfs/2.1.4 -k 5.18.0-zen1-1-zen' exited 10

@daemonjax - https://unix.stackexchange.com/a/364920/93470 (add unknown public key for makepkg)

building the snapshot from this page works ok

==> Leaving fakeroot environment.
==> Finished making: zfs-dkms 2.1.4-1 (Tue 26 Apr 2022 21:59:20 BST)

I had trouble making this package...

ERROR: 0001-only-build-the-module-in-dkms.conf.patch was not found in the build directory and is not a URL.

So I get the patch file from the Sources list on this page, and I still can't build it...

0001-only-build-the-module-in-dkms.conf.patch ... FAILED

ERROR: One or more files did not pass the validity check!

Then I figured if I just cut out some of the junk in the patch file (it looks like a simple copy-paste of an entire email someone got), then it would accept the patch... nope (but I kept my changes). So, then I figured out I need to run makepkg -g >> PKGBUILD to update the hash for the patchfile. Ok... I do that, then I get a new error:

Verifying source file signatures with gpg... zfs-2.1.4.tar.gz ... FAILED (unknown public key 6AD860EED4598027) ERROR: One or more PGP signatures could not be verified!

So, then I figure out I have to add that gpg key to my key ring blindly (which defeats the purpose of using gpg, but whatever -- who is Tony Hutter and why should I trust him? Whose gpg key should I expect? No idea, but I have no choice if I want to continue EDIT: There IS a line about him in PKGBUILD file, so my bad) using the command as the non-root user I'm using the build the package:

gpg --receive-keys 6AD860EED4598027

And now finally I can build the package.

Thoughts:
1) The patch is required to make the package, and it's from the year 2018... so it should probably just be included at this point, right? Can't it be set up to auto-download the file at least? 2) Why I should dis/trust Tony Hutter's GPG key for the zfs-2.1.4.tar.gz file should probably be included in the PKGBUILD file. EDIT: There is a comment line in the PKGBUILD about trusting Tony Hutter, so that's fine. I didn't see it while using a standard tty terminal.