| Git Clone URL: | https://aur.archlinux.org/zfs-dkms.git (read-only, click to copy) |
|---|---|
| Package Base: | zfs-dkms |
| Description: | Kernel modules for the Zettabyte File System. |
| Upstream URL: | https://zfsonlinux.org/ |
| Licenses: | CDDL |
| Provides: | SPL-MODULE, zfs, ZFS-MODULE |
| Submitter: | isiachi |
| Maintainer: | kstolp |
| Last Packager: | kstolp |
| Votes: | 188 |
| Popularity: | 1.28 |
| First Submitted: | 2015-08-31 12:01 (UTC) |
| Last Updated: | 2025-06-21 08:42 (UTC) |
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?
What you describe is a "dependency" and not a "conflict". There are plenty of packages in the AUR and the Arch repos which have a dependency on a specifc version of another package. E.g. There are packages with a dependency on gtk3 but you can still have gtk4 installed in parallel. zfs-dkms has a dependency on linux<=6.14. But you can still have linux 6.15 installed in parallel. This is not possible if you declare a conflict.
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.
@snackattack wrote: I disagree. If you wish to use zfs with linux, then you need to uninstall linux=6.15 and downgrade to linux=6.14. Therefore, zfs conflicts with linux=6.15.
What you describe is a "dependency" and not a "conflict". There are plenty of packages in the AUR and the Arch repos which have a dependency on a specifc version of another package. E.g. There are packages with a dependency on gtk3 but you can still have gtk4 installed in parallel.
zfs-dkms has a dependency on linux<=6.14. But you can still have linux 6.15 installed in parallel. This is not possible if you declare a conflict.
Pinned Comments
kstolp commented on 2025-04-29 16:56 (UTC) (edited on 2025-06-21 08:43 (UTC) by kstolp)
OpenZFS currently supports Linux kernel versions 4.18 - 6.15, 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.
kstolp commented on 2023-09-29 00:34 (UTC)
When requesting changes, please include detailed reasoning for the change.
kstolp commented on 2023-01-07 09:31 (UTC)
If you receive this error when trying to build, it is because you have not imported the GPG keys used for verification.
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
validpgpkeysarray. (recommended)2) Alternatively, you can skip this verification by passing the
--skippgpcheckargument tomakepkgwhen building. (not recommended)