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)

@FrederickZh, could you please create a patch with your hook integration in this package that @kstolp can easily apply if he doesn't mind? I think it will be the best option.

It only makes sense if we split zfs-dkms to zfs-dkms-mainline, zfs-dkms-lts, zfs-dkms-zen, etc. IMO.

This is a good point I hadn't realized.

This is exactly how archzfs works AFAIK. It appears to me that you switched from archzfs and now are frustrated that zfs-dkms, which is different in its nature, does not work similarly.

Anyway, if you agree that

1. Others may legitimately have setups where it doesn't require zfs-dkms to compile against the LTS kernel, and it's not our place to tell them how to manage their own systems
2. How conflicts should be used is, to a degree, 'a matter of interpretation'; and adding conflicts can cause confusion and unwanted side effects in some scenarios
3. The Pacman hook I posted worked for you -- it's just that it doesn't come with zfs-dkms by default

I believe you'll also have to agree that adding conflicts here isn't the right choice.

We can also have a look at *-dkms packages in the official repo, especially packages like nvidia-dkms which does not always compile against / work with the latest kernel and will (more) often lead to unbootable systems when it doesn't, they never added conflicts either:

$ pkgctl repo clone --protocol https nvidia-utils && cd nvidia-utils  # nvidia-dkms shares the same source PKGBUILD
$ git log -G 'conflicts.*linux'  # prints nothing

I've been using zfs-dkms for quite some time and tbh this conversation feels terribly familiar. I reckon this idea had indeed been explored in depth, and people reached the conclusion that to make zfs-dkms suitable for the wider crowd, it shouldn't (ab)use conflicts and users were expected to put in a bit effort for their own needs. But newcomers sometimes find out about this in the hard way (arguably. If you use ZFS, isn't it actually easier to roll back and mkinitcpio to recover?), and then wonder if there's anything we can still do about it.

Well, one thing we can actually do about it, is that if people find my script useful, I can put it in the ArchWiki. It obviously doesn't work for everyone but can at least make people aware of this potential issue if they run root-on-ZFS or something, and that's about the most 'Arch way' to tackle this IMHO.

I want to share my 2 cents on this topic: zfs-dkms does not have a conflict with linux>=6.15, it has a dependency on linux<=6.14. That is a big difference. Please read how a "conflict" is defined in the arch/pacman space to understand that.

That said, I do not believe that zfs-dkms should add a conflict statement in the PKGBUILD. That would prevent installation of zfs-dkms as soon as a kernel >=6.15 is installed. And that is not desired. At least not in my case.

There are people whose machines require zfs to boot, there are also people who only need it to occasionally mount some external drives.

Fair point.

According to https://wiki.archlinux.org/title/PKGBUILD#conflicts:

conflicts: An array of packages that conflict with, or cause problems with the package, if installed. Since the kernel itself just runs happily without zfs, zfs-dkms itself also builds normally for compatible kernels even if you have other incompatible ones installed, I don't think semantically conflicts is the right choice, at least not for everyone.

It's partially a matter of interpretation, but the way I read it, I think it's fair to say zfs conflicts with linux >= 6.15 currently, both for the common meaning of "conflicts" or the meaning above (it does cause problems with the package -- if you try to use them together).

It only makes sense if we split zfs-dkms to zfs-dkms-mainline, zfs-dkms-lts, zfs-dkms-zen, etc. IMO.

This is a good point I hadn't realized. It seems that the linux-lts PKGBUILD doesn't have a provides=("linux=6.12"). Which means a separate conflicts would be needed for each of linux, linux-lts, linux-zen, etc, which is not nice.

If having a working LTS kernel with ZFS is important to you, why not simply write a Pacman hook (or use archzfs)?

I did use archzfs in the past, but had a lot of problems with it (most recently, this), and found zfs-dkms much more reliable.

Thanks for sharing the Pacman hook, very useful. Though I still feel like this would be ideally be handled by pacman's built-in conflict handling...

Maybe a reasonable compromise would be to just add a conflicts=("linux-lts>6.14"). Then users who want to have an incompatible linux installed can still do so, but for the common use case of just using zfs-dkms with linux-lts, we can be protected against breakage whenever LTS updates.

I believe the idea around not adding a conflicts was so the user could have the freedom to keep a conflicting linux installed and switch to it whenever zfs catches up, and otherwise use linux-lts. But does it really make sense to support this use case?

There are people whose machines require zfs to boot, there are also people who only need it to occasionally mount some external drives.

According to https://wiki.archlinux.org/title/PKGBUILD#conflicts:

conflicts: An array of packages that conflict with, or cause problems with the package, if installed.

Since the kernel itself just runs happily without zfs, zfs-dkms itself also builds normally for compatible kernels even if you have other incompatible ones installed, I don't think semantically conflicts is the right choice, at least not for everyone. (It only makes sense if we split zfs-dkms to zfs-dkms-mainline, zfs-dkms-lts, zfs-dkms-zen, etc. IMO.)

If having a working LTS kernel with ZFS is important to you, why not simply write a Pacman hook (or use archzfs)? Here's mine:

[Trigger]
Operation = Install
Operation = Upgrade
Type = Path
Target = usr/lib/modules/*-lts/vmlinuz

[Action]
Description = Avoid ZFS-incompatible LTS kernels
When = PreTransaction
Exec = /usr/local/bin/zfs-dkms-guard.sh
AbortOnFail
NeedsTargets

#!/usr/bin/env bash

set -eo pipefail
shopt -s inherit_errexit

# https://stackoverflow.com/a/4025065/2487227
function vercomp() {
    if [[ "$1" == "$2" ]]; then
        printf '0'
        return
    fi
    local i
    IFS='.' read -r -a ver1 <<<"$1"
    IFS='.' read -r -a ver2 <<<"$2"
    # fill empty fields in ver1 with zeros
    for ((i = ${#ver1[@]}; i < ${#ver2[@]}; i++)); do
        ver1[i]=0
    done
    for ((i = 0; i < ${#ver1[@]}; i++)); do
        if [[ -z ${ver2[i]} ]]; then
            # fill empty fields in ver2 with zeros
            ver2[i]=0
        fi
        if ((10#${ver1[i]} > 10#${ver2[i]})); then
            printf '1'
            return
        fi
        if ((10#${ver1[i]} < 10#${ver2[i]})); then
            printf -- '-1'
            return
        fi
    done
    printf '0'
}

zfs_meta_file="$(rg '/META\b' < <(pacman -Qql zfs-dkms))"
zfs_linux_min="$(awk '/Linux-Minimum/ { print $2 }' "$zfs_meta_file")"
zfs_linux_max="$(awk '/Linux-Maximum/ { print $2 }' "$zfs_meta_file")"

while read -r target_path; do
    kernel_version="$(rg -o '/lib/modules/(\d+\.\d+)' -r '$1' <<<"$target_path")"
    if [[ "$(vercomp "$kernel_version" "$zfs_linux_min")" -lt 0 ]]; then
        printf 'Kernel version %s is below ZFS minimum compatible version %s!\n' "$kernel_version" "$zfs_linux_min" >&2
        exit 1
    fi
    if [[ "$(vercomp "$kernel_version" "$zfs_linux_max")" -gt 0 ]]; then
        printf 'Kernel version %s is above ZFS maximum compatible version %s!\n' "$kernel_version" "$zfs_linux_max" >&2
        exit 1
    fi
done

I temporarily modified the maximum version in /usr/src/zfs-2.3.2/META to 6.10, then:

$ sudo pacman -S linux-lts
warning: linux-lts-6.12.27-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (1) linux-lts-6.12.27-1

Total Installed Size:  138.25 MiB
Net Upgrade Size:        0.00 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring  100%
(1/1) checking package integrity  100%
(1/1) loading package files  100%
(1/1) checking for file conflicts  100%
(1/1) checking available disk space  100%
:: Running pre-transaction hooks...
(1/3) Avoid ZFS-incompatible LTS kernels
Kernel version 6.12 is above ZFS maximum compatible version 6.10!
error: command failed to execute correctly
error: failed to commit transaction (failed to run transaction hooks)
Errors occurred, no packages were upgraded.

I believe the idea around not adding a conflicts was so the user could have the freedom to keep a conflicting linux installed and switch to it whenever zfs catches up, and otherwise use linux-lts.

But does it really make sense to support this use case? Right now this is forcing the users to manually keep track of conflicts. IMO letting the package manager keep track of conflicts is one of the benefits of modern civilization, that is worth giving up a little freedom for ;)

Also, zfs-dkms-staging-git exists now for anyone wanting to use zfs with mainline linux.

It seems most of us just use linux-lts so we don't need to worry about this -- typically ZFS will support the latest LTS kernel 1-2 months before linux-lts actually updates. But I don't believe OpenZFS makes any formal guarantee that it will always be compatible with the latest LTS kernel. If there ever is a period of time where zfs isn't yet compatible with the latest LTS -- or if the user gets busy and forgets to update in this 1-2 month period -- the lack of conflicts could lead people to accidentally break their systems.

(Also wanted to add -- thanks to the maintainers for their hard work. I realize it isn't always possible to make a decision that pleases everyone)

@angelodalzotto: The previous discussion that @yurikoles refers to can be found around here.

The tl;dr is that there was a concern that introducing kernel version restrictions through the PKGBUILD's conflicts variable could potentially result in unresolvable conflicts for users that have multiple kernels installed.

However, I feel that this possibility was not explored to its full depth back then, and it could be beneficial to look into it again.

The idea would be to set, e.g. for the current ZFS release that supports up to kernel 6.14, something like conflicts=('linux>=6.15'), and similar entries for the other Arch officially supported kernels (linux-lts, linux-zen, etc.). That way, when linux 6.15 gets released for Arch, the zfs-dkms package would block its upgrade, until the ZFS project releases a new version that supports 6.15.

From what I understand, the worry was that this could lead to problems for users with multiple kernels. Consider the following situation. Say that in the current state I install linux 6.15, realize that ZFS doesn't build against it, and switch to linux-lts (which is compatible) in the meantime. Then, the zfs-dkms package with the new conflicts=('linux>=6.15') variable gets pushed. What happens then? It sounds like I'd have to choose between having either zfs-dkms or linux installed, but not both, or else the conflict would prevent me from doing any package upgrade. Forcing me to uninstall linux to keep using ZFS with linux-lts sounds like a bad situation.

But this is admittedly a bit beyond my PKGBUILD knowledge. Can anyone with more experience weigh in?

@angelodalzotto

Please review previous discussion, your question was raised many times.

Can't this package be modified to require linux<unsupported version? So we can still use linux non-LTS and this package without adding the kernel to IgnorePkg

@fryfrog thank you for the clue, in my case I actually needed to uninstall zfs-dkms to allow zfs-utils to install successfully and then I was able to rebuild zfs-dkms