Arch Linux User Repository

OpenZFS currently supports Linux kernel versions 4.18 - 6.14, as declared in the META file.

Options if your Linux kernel's version is not within that range:

1) Switch to another Linux kernel, such as linux-lts.

2) Prevent your kernel package from upgrading to an unsupported version until OpenZFS increases the maximum supported kernel version.

3) Modify this package to support your kernel by patching it on your local machine.

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)

@eblau: the idea (which has other problems) would be to use conflicts to flag the package if we know for a fact that the ZFS version it contains is not compatible with a specific kernel version (for instance that it fails to build against that kernel), preventing headaches for some users. If we don't yet know whether it builds or not against an upcoming kernel, then we would not include it in conflicts.

You're right that having to do a DKMS rebuild because the AUR package updated just to change the conflicts field is somewhat undesirable (I don't think we had considered that). But it still may be a price worth paying to prevent system breakage for some users. I mean, package re-builds caused solely because a related package / dependency changed happen all the time.

@meithan the timing in this specific case is close. When a linux 6.3 compatible version of zfs-dkms is released, do you add a conflicts line for 6.4, 6.5, ... or not? What if zfs-dkms doesn't change in several kernel release cycles?

AUR packages can be (and are) updated separately. For dkms packages, it doesn't make sense to release a new version just to update the conflicts line.

@eblau: Linux 6.3 was released on 23 April, and as the new kernel started being deployed in particular distros and people tried to build ZFS against it, we quickly knew for a fact that the latest ZFS release doesn't work with it. This package's maintainer, kstolp, reported so on 3 May. In fact, we knew of the incompatibility even before 6.3 came out from the project development issue tracker. And, officially, the latest ZFS release does not support 6.3 (and it would be wise to stick to official support). There's no future prediction at all involved here.

@Vrakfall: what kstolp said earlier is that this could lead to problems in cases where people have multiple kernels installed, such as people inadvertently uninstalling their mainline linux kernel (>= 6.3) as a result of the conflicts. But I'll let kstolp further elaborate on your argument.

@Vrakfall how is the packager supposed to know that zfs-dkms 2.1.11-1 is incompatible with Linux 6.3? zfs-dkms 2.1.11-1 was released before linux 6.3. The packager would have to be able to predict the future.

Often the older zfs-dkms package is compatible with newer kernel versions so blindly adding a restriction to the most recent kernel isn't a good solution.

I don' t understand what's wrong with using conflicts=('linux>=6.3'). We know for a fact this specific version doesn't work with those kernels. All it does is generate a clearer error message during pacman -Syu, aka: :: linux and zfs-dkms are in conflict. Remove zfs-dkms? [y/N] at what point the user would think they really don't want that.

Then pacman -Qi would include Conflicts With : linux>=6.3 and it'll be clear in a quick fashion. It still allows people using multiple kernels to keep a 6.2 kernel on the side and just not update it (or make a package that follows the 6.2 branch updates). There wouldn't be any point of having a newer kernel installed when it wouldn't work anyway.

That said, other kernels don't use any provides or replaces fields that interact with the main kernel, so it'd be hard to include all potential kernels. Also, with a fix in the pipes, this isn't too important anymore as a new version is hopefully very soon™; this is more relevant for when this problem appears again.

Thanks all for your input and suggestions. This has been a great exercise in exploring potential ways to prevent errors due to incompatible kernel versions. Due to the way PKGBUILD works and different users' use cases, none of the proposed solutions seem satisfactory. Therefore, I will not be making any changes related to kernel version checking.

As always, I appreciate the the thought and effort people put towards this package. If anyone has any suggestions in the future, please comment them here with detailed and specific solutions.

OpenZFS issue #14622, implementing compatibility with kernel 6.3, has been marked as closed on the master (dev) branch.

Now we have to wait for a new release to be published (2.1.12?) including these changes.

@artodeto: there already are such packages! See zfs-linux, zfs-linux-lts, zfs-linux-zen.

This package, zfs-dkms, is for the kernel-version-agnostic DKMS packaging of OpenZFS. It wouldn't make sense to have kernel-specific version of it. By its nature, DKMS versions are more experimental than kernel-specific ones.

I don't like to rely on "users should be responsible" either if we can help it through smarter software, but it's not an unreasonable thing either. This is Arch, after all. Some level of maturity and responsibility is expected, specially if one is using DKMS versions (which is why most of them are in the AUR).

And the main obstacle to ZFS becoming a more common filesystem is the OpenZFS - Linux kernel licensing conflict. I do wish it could magically go away.

@kstopl

thanks for your feedback. Creating dedicated packages for linux, linux-lts and linux-zen would be to complicated, or?

Personally, I don't like the idea of "user has to take care of zfs because zfs users do know better". With this attitude, we zfs users will never move zfs to a more common filesystem.

If possible, I would prefer having a check before upgrading the kernel which could be deactivated by using a flag like "--force" or even have a dedicated package named zfs-dkms-latest (or -git).