Package Details: zfs-utils

Git Clone URL: (read-only)
Package Base: zfs-dkms
Description: Kernel module support files for the Zettabyte File System.
Upstream URL:
Licenses: CDDL
Conflicts: zfs-utils-git, zfs-utils-lts
Submitter: isiachi
Maintainer: isiachi
Last Packager: isiachi
Votes: 20
Popularity: 2.122057
First Submitted: 2015-08-31 12:01
Last Updated: 2016-09-20 20:44

Dependencies (2)

Required by (3)

Sources (4)

Latest Comments

lilydjwg commented on 2016-11-04 12:28

You left out a "&" here:

seschwar commented on 2016-10-23 19:31

You can find fixes for my complaints at

There's also support for GRUB's root=ZFS=mypool/myfs kernel command line syntax.

seschwar commented on 2016-09-22 21:34


You updated the initcpio hook to mount all child data sets of the dataset mounted on /. See line 59 in /usr/lib/initcpio/hooks/zfs.

This is quite problematic since the script completely ignores the canmount property. Therefore datasets with canmount=off and canmount=noauto get mounted as well. This completely breaks the semantics of these properties.

The manual page of the zfs command has the following sentence in it:

> Setting this property [canmount] to off allows datasets to be used solely as a mechanism to inherit properties.

I had a dataset for /var with canmount=off for exactly this purpose. Imagine my surprise when this empty dataset got mounted leaving me with an almost empty /var. Quite the breaking change you introduced there.

I'm not quite sure about the motivation behind this. It could be useful for boot environments. Something similar was discussed recently on a FreeBSD mailing list: However they should be careful when repurposing an established setting of property. Changing how the mounting of datasets work would break backwards compatibility.

isiachi commented on 2016-09-20 19:45

| Upgrading this package from the previous version does not work, you have to remove it and readd to your system.
| The issue is some kind of dependency circle between this package and the spl-dkms:

This is because you have to build all the packages on your own and install all of them together.

Otherwise you have to install the spl packages with the -d option.

# pacman -Ud spl-dkms### spl-utils###

This is a AUR helper problem. It's not my fault. Stop saying things that have no sense and learn how to use pacman.

isiachi commented on 2016-09-20 19:36


We are talking of a filesystem and this is a stable branch. I've already said that I wasn't going to add a single commit from the master branch, too much things were changed.

Unfortunately I wasn't able to lock the package to a specific kernel version because the kernel is not a dependecy.

And also take a breath and calm down.

RubenKelevra commented on 2016-09-20 19:34

@utsi just use a conflict constraint for such cases:

conflict linux>4.6.xx etc. :)

RubenKelevra commented on 2016-09-20 19:31

Upgrading this package from the previous version does not work, you have to remove it and readd to your system.

The issue is some kind of dependency circle between this package and the spl-dkms:

Sorry that it is in german:

Fehler: Konnte den Vorgang nicht vorbereiten (Kann Abhängigkeiten nicht erfüllen)
:: zfs-dkms: das Installieren von spl-dkms ( löscht ein benötigtes Packet von 'spl-dkms='

utsi commented on 2016-09-19 08:49

@RubenKelevra Ah, so sorry I misunderstood the issue! As far as accepting the patch I can understand why he would not accept it, only official releases. As for limiting to kernels <4.7, which kernels specifically? linux? linux-lts? linux-ck?

RubenKelevra commented on 2016-09-19 07:12

@babarnescocke I actually dislike if I hit update and my
system does not boot up again. This is not a stable behaviour,
this is just a broken dependency. This maintainer does not
want to fix this or add the 4.7 patch which was provided
several weeks ago.

If he wants only to support LTS-Kernels he should create a
LTS-ZFS package and this is fine, else I would expect more
than just a I-dont-like-to-patch behaviour, without fixing the
actually dependency issue.

utsi commented on 2016-09-18 23:26


It took quite a bit of time for for ZOL to be ready for 4.7.
Taking that into account is waiting a few more days for the AUR package to get updated _that_ bad?

As babarnescocke said, this is a freaking filesystem, of all the things that should not bug out, this is probably the most important next to the kernel itself.

Also thanks to the maintainer, been enjoying your DKMS packages for a while now without issues! :)

All comments