Package Details: zfs-dkms 0.7.9-1

Git Clone URL: (read-only)
Package Base: zfs-dkms
Description: Kernel modules for the Zettabyte File System.
Upstream URL:
Licenses: CDDL
Conflicts: zfs-git, zfs-lts
Provides: zfs
Submitter: isiachi
Maintainer: isiachi
Last Packager: isiachi
Votes: 60
Popularity: 1.715602
First Submitted: 2015-08-31 12:01
Last Updated: 2018-05-15 10:58

Dependencies (5)

Required by (11)

Sources (4)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

minextu commented on 2018-09-10 09:07

@Kaedo As far as I know dkms-sorted is no longer necessary, since dkms in extra has this functionality now (

About the kernel panic: We recently changed the hook a bit which might cause your boot problems. Please open an issue at with more details (This AUR package is not archzfs).

Kaedo commented on 2018-09-10 08:46

Yesterday I installed:

  • archzfs/zfs-dkms 0.7.10-1
  • archzfs/spl-dkms 0.7.10-1
  • core/linux 4.18.6.arch1-1
  • core/linux-headers 4.18.6.arch1-1

I got an failed build when build dkms with version 2.5-3 due to Missing Dependencies.

I resolved the build issue with dkms-sorted 2.5-2, but on reboot I got the problem that my zfs pool could not be imported by the mkinitcpio zfs hook.

Always got kernel panic.

With live USB stick there were no problem during import of the zfs pool.

After checking every possible config mistag I downgraded to:

  • core/linux 4.17.13.arch1-1 (base)
  • core/linux-headers 4.17.13.arch1-1
  • archzfs/spl-dkms 0.7.9-3 (archzfs-dkms)
  • archzfs/spl-utils-common 0.7.9-2 (archzfs-linux)
  • archzfs/zfs-utils-common 0.7.9-2 (archzfs-linux)
  • archzfs/zfs-dkms 0.7.9-3 (archzfs-dkms)

Now every thing works fine. I guess the root cause of the problem is: - archzfs/zfs-dkms 0.7.10-1.

Does anybody else encountered the same problem?

pgoetz commented on 2018-09-09 12:23

0.7.10 was just released and appears to fix this problem.

ultdev commented on 2018-08-18 01:39

This package is likely to fail on 4.18 kernels due to the change in timespec. There's currently an open pull request for a compatibility fix on the zfsonlinux github page:

sylveon commented on 2018-08-06 03:40


The tarball update was done silently, so it could have taken a while of users thinking the source is compromised in some way for the package maintainer to notice and update.

sudoBash418 commented on 2018-08-04 06:25

@sylveon Wouldn't a tarball update like that justify a pkgrel bump and updated checksums?

sylveon commented on 2018-06-10 16:39

The zfs maintainers once had to update the tarballs on an existing release, so using the signature is a better idea than using a checksum.

Achelous commented on 2018-06-09 17:04

I agree with @RubenKelevra that checksums should be used.

@Eschwartz: security wasn't mentioned in his comment, but if he had mentioned it, he would have been right to.

A checksum would ensure that the source hasn't changed since the package maintainer downloaded it. This:

(1) Protects users against targeted MitM attacks (e.g. an oppressive government pretending to be GitHub), and

(2) Protects against an attacker taking over the zfsonlinux GitHub account, and pointing the existing tag at some malicious code (as long as the breach happens after the AUR maintainer downloads the source).

That sounds like a security improvement to me!

As @RubenKelevra notes, there's also a PGP signed .asc file available, and there's no good reason why this shouldn't be used.

As for the pointless whatabout-ism, yes there may be other (higher-profile) packages which make the same mistake, but that's no reason not to fix it here. It shouldn't be necessary to comment on every single one to be allowed the privilege of commenting here.

eschwartz commented on 2018-05-06 17:02

Checksums don't add security, that's why they're the "integrity check", not the "security check". Do you know how many [core] packages don't have PGP signatures available at all? Those are used on far more devices.

Granted, using PGP when available is always nice. But I don't see you screeching at the non-dkms package maintainer to fix his packages...

Edit: to clarify, I even like strong integrity checks myself, because they're definitely better than nothing and it can only help. But you're going about this totally the wrong way and you should also consider the old saying about people who live in glass houses.

RubenKelevra commented on 2018-05-05 13:41

Please add some kind of checksum checking to this package. Currently, the source integrity fully relies on a valid https certificate and the server behind it returning the right data. This doesn't sound right for a kernel module used in thousands of devices.

You can switch to a download link of the release, instead of a git clone (which also reduces the download time and the server load) like this:

Then you can just add a checksum for this archive.

Since they also provide a .asc file, it should be loaded and used to verify the sources too.