Arch Linux User Repository

OpenZFS currently supports Linux kernel versions 4.18 - 6.17, 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)

Can't build against linux-hardened, even though 6.16 is supported. Something about CONFIG_MODULES being disabled even though it is enabled in that kernel. Any idea?

checking whether CONFIG_MODULES is defined... no
configure: error: 
                *** This kernel does not include the required loadable module
                *** support!
                ***
                *** To build OpenZFS as a loadable Linux kernel module
                *** enable loadable module support by setting
                *** `CONFIG_MODULES=y` in the kernel configuration and run
                *** `make modules_prepare` in the Linux source tree.
                ***
                *** If you don't intend to enable loadable kernel module
                *** support, please compile OpenZFS as a Linux kernel built-in.
                ***
                *** Prepare the Linux source tree by running `make prepare`,
                *** use the OpenZFS `--enable-linux-builtin` configure option,
                *** copy the OpenZFS sources into the Linux source tree using
                *** `./copy-builtin <linux source directory>`,
                *** set `CONFIG_ZFS=y` in the kernel configuration and compile
                *** kernel as usual.

supported kernel version has been updated in the 2.3.4 release to 4.18 - 6.16 https://github.com/openzfs/zfs/blob/zfs-2.3.4/META

From comment by @dkadioglu in aur/vmware-workstation:

Maybe you can add one small fix for a deprecated dkms feature, according to https://github.com/dell/dkms/pull/514#issuecomment-2821267860

Replace CLEAN="make clean" with CLEAN=true in scripts/dkms.mkconf.

Thanks!

Sorry, I didn't realize I was only reading the pinned comments a while ago. Also yeah, I didn't know it was a staging branch it was building. I do realize they do not have a whole lot of testing, but I've been through it before.

I also keep relatively well backed up. I wish I'd known about the staging branch the last time I was using ZFS on Arch, as then, I was using the dang -git package every major kernel version bump. I also didn't use a chroot based building process, so upgrading was painful.

@kode54 to be completely fair 99% of the times there is absolutely no need to apply any patches on top of the staging branch (the branch where the fixes for the next minor release end up piling) to make it work with latest upstream kernel. I had to backport compatibility fixes mainly during the transitioning period to the next major release (2.2.x -> 2.3.x).

I would not call zfs-dkms-staging-git inherently safe (there is definitely a risk of data loss due to how little testing newer kernel versions received) but it's not that bad either (or at least I trust it with my main laptop's fs). For sure it's much, MUCH safer than using zfs-dkms-git as LUKS2 users can testify.

I mean, if you absolutely need it, there is also zfs-dkms-staging-git, which takes the current stable release, and applies enough upstream patches to get it working with the current latest linux package. Naturally, no support from upstream if something goes wrong when you do that.

Edit: Bonus points to that package for not working from a clean chroot, because it uses the git command at such a root stage of processing the script, that it is needed before makepkg can evaluate it to find that it requires git as a makdepend. Nice race there!

During the post-transaction hook for my most recent update, I saw this message in the output:

==> dkms install --no-depmod zfs/2.3.1 -k 6.12.29-1-lts
Deprecated feature: CLEAN (/usr/src/zfs-2.3.1/dkms.conf)
==> depmod 6.12.29-1-lts

It looks like '0001-only-build-the-module-in-dkms.conf.patch' from this AUR package is responsible for adding the "CLEAN" line.

See: https://github.com/dell/dkms/issues/502

Thoughts?

I do not understand your point, and may be you do not understand my point.

Yes, I think we may not understand each other. But I think it's not productive to keep debating here whether "depends" or "conflicts" is semantically more correct.

Since conflicts won't be added here, my suggestion was to put the conflicts in a separate metapackage, for those of us who want to prevent incompatible kernels.

@snackattack wrote: No, zfs doesn't depend on linux<=6.14, you can use zfs-dkms without linux installed (for example, with linux-lts). However, you cannot use zfs-dkms at the same time as linux=6.15, therefore it conflicts. For gtk, it's perfectly possible to use gtk3 and gtk4 apps at the same time, but you can't use zfs-dkms at the same time as linux=6.15 -- you have to reboot to a non-conflicting kernel.

I do not understand your point, and may be you do not understand my point.

I have multiple kernel installed linux, linux-lts, linux-tkg 6.12 and 6.14 etc. If we would follow your recommendation and add a conflict to zfs-dkms it would mean that I could not install linux 6.15 without removing zfs-dkms. Which would remove the zfs module from all the other kernels as well. That does not make sense.

you can use zfs-dkms without linux installed

You can use zfs-dkms with an unsupported linux installed. I am. I also have linux-lts installed and boot that by default, but sometimes I need to boot the freshest linux kernel. Then I don't mount zfs and I'm aware of the fact. Having an unsupported linux package installed is not a conflict (as it has been pointed out in this thread), because it does not make it impossible to use zfs-dkms.

The thing with the kernel incompatibility is pretty much documented at this point and Arch isn't Ubuntu to make decisions on part of the (power) user. There are workarounds to the issue, because the obvious fix (zfs always supporting the latest mainline kernel) isn't an option.

What is the point you're trying to make, what do you seek to achieve? Prohibit users from having an incompatible kernel installed? That is an unjustified limitation to impose upon them. If you want to prevent updating to an unsupported linux on your system, you are free to do so, you have been supplied with plenty of options just in this comment section. So what's your point, why limit everyone who know what they are doing?