Package Details: zfs-dkms-git 2:2.0.0rc1.r38.gcd80273909-1

Git Clone URL: (read-only, click to copy)
Package Base: zfs-dkms-git
Description: Kernel modules for the Zettabyte File System.
Upstream URL:
Licenses: CDDL
Conflicts: spl-dkms, zfs-dkms
Provides: SPL-MODULE=2.0.0rc1.r38.gcd80273909, ZFS-MODULE=2.0.0rc1.r38.gcd80273909, spl-dkms, zfs, zfs-dkms=2.0.0rc1.r38.gcd80273909
Replaces: spl-dkms-git
Submitter: isiachi
Maintainer: eschwartz
Last Packager: eschwartz
Votes: 23
Popularity: 0.000132
First Submitted: 2014-06-04 15:15
Last Updated: 2020-09-04 05:19

Dependencies (3)

Required by (19)

Sources (2)

Latest Comments

1 2 3 4 Next › Last »

65a commented on 2020-08-23 06:52

That's precisely what I did, and precisely when I encountered the dependency mismatch (perhaps yay's cache is causing the breakage).

Another thing I noticed is that the hooks provided by this package substantially differ from the old zfs-dkms-head-git. This definitely broke me coming from that package, since the hooks provided in this package have no support for loading keys.

Agreed that they should be separate packages, since one is kernel and the other is userland. There may be situations where only one or the other is needed (e.g. userland in a container).

eschwartz commented on 2020-08-23 02:16

When you update one, you should probably update the other at the same time. Just makepkg both of them and then pacman -U them together. No, nothing is "broken".

I'm not sure the dependency versioning should be lifted -- both packages build from the same repo and API updates to one might break if the other doesn't get updated together.

This might be less tricky to update the packages using makepkg -i if they were one single PKGBUILD with split packages, but then that would inconvenience people using packages which build the binary modules for one kernel, and only want zfs-utils-git.

65a commented on 2020-08-23 01:17

This package seems quite fragile with the version dependency on zfs-utils-git. Currently broken because of a mismatched version number != 1:0.8.0.r932.g317dbea17 when zfs-utils-git is compiled from AUR.

eschwartz commented on 2020-08-21 19:05

mindstormer, thanks for the report. I've deleted the -head package since it's a duplicate and breaks the rules of submission.

mindstormer commented on 2020-08-21 18:44

How does this compare to zfs-dkms-head-git? Which is recommended?

kerberizer commented on 2020-02-18 12:44


thieh commented on 2020-02-15 00:58

Hm....I got the following issue while trying to build the kernel module:

FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol '__rcu_read_lock'

kernel version is 5.5.3-arch1-1 / gcc 9.2.1 20200130

Anyone mind to enlighten me on this one?

JohnyPea commented on 2019-08-13 08:32

Hi, i was trying to use this package on linux53 with errors and found a discussion where the problem was identified: I have used the suggestion and with this patch: and PKGBUILD update: it builds and works. Tested on Manjaro 5.2.8 and 5.3-rc4 kernels.

javashin commented on 2019-07-08 20:58

this pkg install old zfs zpool --version zfs-0.8.0-116_g1086f5421 zfs-kmod-0.8.0-1

eschwartz commented on 2018-12-02 05:16

Hmm, using the date of the latest commit is at least sort of reasonable once you know where it actually comes from. (Nevertheless, I personally consider dates to be inelegant, and they introduce potential inconsistencies given that git does not enforce monotonically increasing dates, and depending how you format it, timezone differences can cause it to decrease anyway.)

That being said, and while this is obviously somewhat subjective, I'm not sure I see the reasoning anyway -- it's a git package being run from git master, why would the existence of maintenance releases on some other branch matter?