Package Details: zfs-utils 2.1.4-1

Git Clone URL: (read-only, click to copy)
Package Base: zfs-utils
Description: Userspace utilities for the Zettabyte File System.
Upstream URL:
Licenses: CDDL
Submitter: eschwartz
Maintainer: eschwartz (jonathon)
Last Packager: jonathon
Votes: 37
Popularity: 2.05
First Submitted: 2018-10-28 22:49 (UTC)
Last Updated: 2022-03-23 22:03 (UTC)

Pinned Comments

eschwartz commented on 2020-12-27 22:43 (UTC)


This package doesn't support people who have failed to read the wiki page, or cannot interpret error messages.

eschwartz commented on 2019-10-16 03:49 (UTC)

aarch64 is not an officially supported architecture for this PKGBUILD, since I don't exactly test it on such architectures. It failing to work is therefore not very surprising.

I guess you can do any necessary followup in that upstream bug report, hopefully upstream can get it into a state of "working out of the box" so that makepkg --ignorearch works. But I'm not investing any of my own time in this...

Latest Comments

delx commented on 2022-03-12 00:15 (UTC)

Hi there, thanks for the package.

I was browsing my file system and was surprised to see that I had files in /usr/var/run!

I fixed this by adding --localstatedir=/var to the configure options.

UweSauter commented on 2022-03-11 15:00 (UTC) (edited on 2022-03-11 15:49 (UTC) by UweSauter)

Possibly consider adding "libaio" as (build) dependency. The configure script has checks for libaio.h.

Edit: Never mind. Seems like libaio is only used for test cases. Sorry for the noise.

wjlafrance commented on 2021-10-04 23:43 (UTC)

@pizzatoole: Check out eschwartz's pinned comment beginning "This package doesn't support people who have failed to read".

pizzatooie commented on 2021-10-04 22:51 (UTC) (edited on 2021-10-05 00:05 (UTC) by pizzatooie)

I get this when trying to makepkg:

==> Verifying source file signatures with gpg...

⁤ ⁤ ⁤ ⁤ ⁤zfs-2.1.1.tar.gz ... FAILED (unknown public key 0AB9E991C6AF658B)

==> ERROR: One or more PGP signatures could not be verified!

Edit: Thanks @wjlafrance. I've used makepkg before without signature problems, so I mistakenly thought it was a package issue. I was a little concerned at first as harmful AUR packages have existed before (albeit very uncommon). I now know this isn't the case with this version.

tachyon_84 commented on 2021-10-02 13:18 (UTC)

Looks like the repository is broken.

remote: Not Found fatal: repository '' not found

jstrom commented on 2021-10-02 09:13 (UTC)

Would be nice if maintainer can update inticpio hook to be the same as the one in archzfs repo, as the one from this package does NOT support root volume encryption. See

vond commented on 2021-10-01 00:06 (UTC)

There's a pull request open on the source repo which you can use to build 2.1.1 with

tachyon_84 commented on 2021-09-30 23:50 (UTC)

Is this repo still maintained?

gregbert commented on 2021-09-29 15:59 (UTC)

Where is 2.1.1 ? zfs-linux-lts depends on zfs-utils 2.1.1 as of 2021-09-29

eschwartz commented on 2021-06-08 02:04 (UTC) (edited on 2021-06-08 02:06 (UTC) by eschwartz)

Use of the "which" program is an inexcusable sin, and must be replaced in source with portable command -v. No dependencies, optional or otherwise, needed.

But as it happens, upstream removed the check from git master:

Repentinus commented on 2021-06-08 01:45 (UTC)

Eli, can you please add optdepends=('which: Dracut support') to this package?

The test on line 12 otherwise causes Dracut to fail to include the zfs module in the generated initramfs. I have spent two days figuring this out.


bsdice commented on 2021-04-23 15:43 (UTC)


I use ZFS in production using this package. Not for root fs, as that requires really alot more dilligence in setup and usage. I plan to, using the excellent Right now, a small NVME boot/system drive seems easier.

Incidentally for the kernel I use also from AUR. Updates from upstream will be made until the end of 2025. I am using this kernel with DKMS to limit breakage from API changes happening in 5.10+. So far nothing has broken. I always keep a history of known-good kernel installation files around though, in case the current kernel breaks.

I can also recommend excluding a known-working base repository linux-lts kernel from updates through pacman.conf IgnorePkg, and through systemd-boot make sure that you can boot from it as last resort. Kind of a really last fallback, also using its -fallback ram disk. Also of note, I stopped applying intel-ucode willy nilly when they come out. Bad ucode from Intel trying to fix the next 0day in their CPUs really caught me by surprise. It is my impression that ZFS is more demanding of the whole system and will bring out ucode bugs easier than vanilla Linux installations.

hseara commented on 2021-04-23 12:49 (UTC)

@eschwartz and @krzyszto. Thank you for your answers and nice suggestions. I will now do my homework, and if something arises, I will come back to ask. Kind regards.

eschwartz commented on 2021-04-23 11:38 (UTC) (edited on 2021-04-23 11:41 (UTC) by eschwartz)

ZFS packages are provided by the third-party archzfs repository. You can use it as follows.

"OpenZFS developers have their own pacman repository" -- I think not. It's just as trustworthy as any other completely unofficial thing.


I refuse to refrain from opinions!

Here is my opinion: there is nothing wrong with using Arch in production. :)

You'll want to do your sysadmin homework though (this applies to any distro, but with Arch-specific quirks), which means don't do system updates the normal way -- first, do the update in a staging environment, verify it works, and then roll out the same packages to production. This applies to more than just the kernel + zfs, but will take care of those for you too.

(e.g. run a custom mirror and update from there to ensure packages only get upgraded after testing. The custom mirror might only include the actual repo .db files.)

Kernel updates that cause zfs failures will:

  • be noticeable on your staging server

  • not cause errors until the modules get unloaded and fail to reload, which typically happens only on the next reboot, so you have time to downgrade, you just need to watch the output of pacman.

In my experience, it is not GCC updates that cause failure to rebuild -- it is incompatibilities with the next major.minor mainline kernel releases (patch releases on the stable branch are generally fine).

Generally, you don't want to constantly update kernels without rebooting, and you don't want to constantly reboot a server. Seblu has some advice on that too. The simplest solution is to pacman.conf -> HoldPkg and schedule kernel updates for a maintenance window -- you might also want to use the LTS kernel to make upstream regressions less likely to hit you, which also means... that the ZFS modules are less likely to break on new versions, because you're not using those new versions, only the security updates for an old version.

If you have any further questions, feel free to ask them.

krzyszto commented on 2021-04-23 11:16 (UTC)

@hseara Please also see - OpenZFS developers have their own pacman repository which provides various flavors of ZFS modules.

hseara commented on 2021-04-23 10:11 (UTC)

@eschwartz I am planning to install zfs in an arch-based production storage server (please refrain from opinions). I have been reading about the multiple options to install zfs existing on arch and I am slightly confused :).

In our centos servers, we use dkms, but for arch, we are not sure. We are afraid of dmks failing after some gcc update. I am using the officially supported arch kernels (stable and lts). My question is easy zfs-linux-dkms+zfs-utils (Same maintainer @eschwartz) or zfs-linux-stable+zfs-linux-lts+zfs-utils (different maintainers). When using arch and official kernels I would go for the last option but there are some comments about issues regarding not in sync maintainers. I would appreciate a comment from @eschwartz.

aphirst commented on 2021-03-20 19:02 (UTC) (edited on 2021-03-20 19:03 (UTC) by aphirst)

I can confirm that it works fine on my newly set-up rpi4 (aarch64), and on my older ODROID-XU4 (armv7h). I use the AUR through aurutils so at least I can keep manually adding the architecture to the PKGBUILD each time I do an aur update, but it would definitely be more convenient to not need to. That said, perhaps aurutils lets me pass a similar "ignore arch" flag like makepkg -a ...

Thanks for all your work maintaining this PKGBUILD, even if you do intend to focus on i686/x86_64 support!

eschwartz commented on 2021-03-03 22:34 (UTC)

Because that's not how the arch array works, what you actually want is for it to include armv7h. See the PKGBUILD(5) documentation...

aphirst commented on 2021-03-03 22:17 (UTC)

Is there any reason this PKGBUILD isn't set to "any" architecture? I'm running it on my armv7h (archlinux-ARM) box along with zfs-dkms (which DOES use "any" architecture) without any issues.

krzyszto commented on 2021-02-07 11:20 (UTC)

zfs.initcpio.hook is missing load-key support.

initcpio hook from the official zfs-utils package has stuff like:

zfs_decrypt_fs() {

    # check if 'zfs load-key' is available
    zfs 2>&1 | grep load-key > /dev/null || return 0

    # check if dataset is encrypted
    [ "$(zfs get -H -o value encryption "${dataset}")" != "off" ] || return 0

    # check if key is already loaded
    [ "$(zfs get -H -o value keystatus "${dataset}")" != "available" ] || return 0

    # get the encryption root
    encryptionroot=$(zfs get -H -o value encryptionroot "${dataset}")

    # export encription root to be used by other hooks (SSH)
    echo "${encryptionroot}" > /.encryptionroot

    # loop until we get the correct password or key is unlocked by another vector (SSH for instance)
    while [ "$(zfs get -H -o value keystatus "${encryptionroot}")" != "available" ] &&
      ! eval zfs load-key "${encryptionroot}"; do
        sleep 2

    if [ -f /.encryptionroot ]; then
        rm /.encryptionroot

and they call this function just before mounting every dataset.

defab67 commented on 2021-01-18 07:35 (UTC)

@ipickering I ran into the same issue a few days ago. It turns out that the maintainers of the zfs-linux-lts package maintain their own unofficial zfs-utils package for situations like this. See this comment for the link:

It worked for me. Not sure if/how it differs from this one. Maybe you can compare the PKGBUILDs.

ipickering commented on 2021-01-18 07:27 (UTC)

Is this going to be updated to 2.0.1? I upgraded my system and got stuck because I can't reinstall ZFS after removing it because now it has a dependency on 2.0.1, which doesn't exist.

jaybeavers commented on 2021-01-10 03:45 (UTC)

Will confirm that adding aarch64 works great with the current PKGBUILD @eschwartz.

RPi4, especially the 8 GB model, makes for a pretty decent personal NAS.

eschwartz commented on 2020-12-27 22:43 (UTC)


This package doesn't support people who have failed to read the wiki page, or cannot interpret error messages.

Win8Error commented on 2020-12-27 21:54 (UTC) (edited on 2020-12-27 21:54 (UTC) by Win8Error)

==> Verifying source file signatures with gpg... zfs-2.0.0.tar.gz ... FAILED (unknown public key 0AB9E991C6AF658B)

==> ERROR: One or more PGP signatures could not be verified!

==> ERROR: Could not download sources.

JLSalvador commented on 2020-11-23 10:30 (UTC)

This package requires "core/which" to support the dracut module check. @eschwartz can you add it, please?

j0b314 commented on 2020-10-19 05:36 (UTC)

zfs and zfs-utils are running here on Raspberry Pi 4 (4GB) (aarch64) without any issues. To build it, just replace PKGBUILD line:

arch=("i686" "x86_64")


arch=("i686" "x86_64" "aarch64")

DustVoice commented on 2020-08-08 18:09 (UTC) (edited on 2020-08-09 14:14 (UTC) by DustVoice)


Normally segfaults using gcc occur either if the compiler has some weird bug, or if you don't have enough RAM. I didn't think it could be the RAM, because I had 64G installed in my system. After trying 6-7 times to brute-force it (if it throws an error just try compiling again), it finally succeeded in compiling. Turns out one stick of RAM was faulty. So I would advise you that upon receiving a similar error, you try brute-forcing it a couple of times and double-checking with a memtest, just for good measure. Shoutout to the #archlinux IRC for the help.


Unfortunately, this package doesn't compile for me. In the directory zfs-utils/src/zfs-0.8.4/lib/libzpool, the compiler throws the following error:

/bin/sh: line 2: 68193 Segmentation fault      (core dumped) /bin/sh ../../libtool --silent --tag=C
run\" -DSBINDIR=\"/usr/bin\" -DSYSCONFDIR=\"/etc\" -UDEBUG -DNDEBUG -D_FORTIFY_SOURCE=2 -std=gnu99
-Wframe-larger-than=4096 -DLIB_ZPOOL_BUILD -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -MT lsta
make[3]: *** [Makefile:1216: lstate.lo] Error 139

I'm currently on the 5.7.12-zen1-1 kernel. I've also tried with the 5.7.12-arch1-1 kernel, just for good measure, but even after re-cloning, the compiler still throws the same error.

Regarding the big picture, I'm trying to build the zfs-dkms package from the AUR, where zfs-utils is logically a dependency.

eschwartz commented on 2020-07-19 18:25 (UTC)

makepkg --ignorearch would allow it to be built on unsupported architectures. However, previous comments indicated that would not even work because of e.g. configure: error: cannot guess build type; you must specify one.

jaybeavers commented on 2020-07-13 17:34 (UTC)

Thank you for your contributions Eli. Submitted a PR on github to add armv7h to the supported arch, I have tested this on arch for raspberry pi 4 and have a clean compile. Light manual testing has shown no issues so far.

This is a necessary dependency to add zfs-dkms to arch on rpi 4. Note that other distros (Ubuntu aarch64) support zfs-utils.

I have not tested on a aarch64 kernel for the RPi4.

fluke commented on 2020-07-13 07:35 (UTC)

zfs-utils package from has better initcpio zfs hooks. For example it has the ability to unlock encrypted volumes at boot (zfs load-key). Would it be possible to implement this here?

eschwartz commented on 2020-06-19 19:12 (UTC) (edited on 2020-06-19 19:17 (UTC) by eschwartz)

Can you look up what the word "arch" means in the PKGBUILD(5) man page?


EDIT: I'm guessing your comment is due to the desire to have this work out of the box on ARM arches. Obviously, the difference matters, or you would not be asking! And no, I've previously had comments indicate that this package didn't build on ARM, so I don't feel comfortable listing support for something I don't test which maybe doesn't work.

dlp commented on 2020-06-19 18:59 (UTC)

Can the arch be changed to any to match the zfs-dkms package?

eschwartz commented on 2020-05-27 17:39 (UTC)

I independently figured that out and filed as I'm not sure whether systemd should be in clean chroot builds, but it used to be and that assumption has actually changed now.

It has ramifications for more than just the availability of the systemctl utility -- it also affects the passwd database.

So systemd needs to either be added as a makedepends, or re-added to base-devel. Since you were the one who added systemd to base-devel a few years ago, maybe you have an opinion or two to share on that bug report? :)

seblu commented on 2020-05-27 17:29 (UTC) (edited on 2020-05-27 17:30 (UTC) by seblu)

I have the same issue than @PedroHLC when building with extra-x86_64-build on my aurbot builder.

There is some hints in the build log:

checking for systemd support... no

Calling systemctl in the PKGBUILD produce the following error:

==> Starting build()...
/startdir/PKGBUILD: line 38: systemctl: command not found
==> ERROR: A failure occurred in build().

systemctl is packaged inside systemd. So you need to add systemd as a makedepends.

What about moving it on community? ;)

PedroHLC commented on 2020-05-22 00:07 (UTC)

@eschwartz Sorry, you were right, compared two BUILDINFO, at some point my containers removed systemd and stayed just with systemd-libs.

eschwartz commented on 2020-05-21 23:59 (UTC)

Well, if systemctl --version succeeds in your container environment I'm at a loss for words as to how zfs's --enable-systemd=check default could incorrectly analyze systemd as not being there:

As always, I have built this package and zfs-dkms using extra-x86_64-build, entered the build container using arch-nspawn, installed linux/linux-headers, and ensured that dkms install correctly builds the modules for the default kernel. Then I uploaded the resulting packages to

So I'm quite positive this can correctly work. You cannot argue with experimental results, and I have experimented, it did correctly work, and the results are freely available for download, right there; you may inspect the .BUILDINFO from those package tarballs and see how I've built it, with what installed packages, what makepkg.conf options, and what $PWD, try to reproduce it using makerepropkg (part of devtools) and so on.

If I had a better understanding of how your build differs from my build, then perhaps we could determine why your build failed with such disastrous results and ended up missing parts.

PedroHLC commented on 2020-05-21 23:40 (UTC)

systemd 245 (245.5-2-arch)

I actually build from a clean systemd-nspawn container with just base-devel installed. Pretty much how I've been building ZFS since 2018 on my repository...

eschwartz commented on 2020-05-21 23:23 (UTC)

It should autodetect systemd support and install both.

It does, in fact, autodetect systemd support and install both. On my machine.

Does systemctl --version not succeed in your environment? It is part of base-devel, so this really should work...

PedroHLC commented on 2020-05-21 23:18 (UTC)

@eschwartz Not sure if it's something that changed with 0.8.4, but building this (without the rm *modules-load.d line) doesn't install a zfs-mount.service anymore...

PedroHLC commented on 2020-05-21 21:18 (UTC)

With the latest PKGBUILD

rm: cannot remove '/home/main-builder/pkgwork/pkg/zfs-utils/usr/lib/modules-load.d': No such file or directory

RandomChars commented on 2020-05-21 10:50 (UTC)

this version no longer compiles, please update the package

enricop commented on 2020-05-21 09:20 (UTC)

@eschwartz : when this will be updated to 0.8.4?

Gooberslot commented on 2020-05-21 06:31 (UTC)

This won't build for me. Give me this error:

CCLD /usr/bin/ld: ../../lib/libshare/.libs/libshare.a(smb.o):(.bss+0x0): multiple definition of `smb_shares'; ../../lib/libshare/.libs/libshare.a(libshare.o):(.bss+0x0): first defined here collect2: error: ld returned 1 exit status make[3]: [Makefile:694:] Error 1 make[3]: Leaving directory '/home/gooberslot/tmp/zfs-utils/src/zfs-0.8.3/lib/libzfs' make[2]: [Makefile:562: all-recursive] Error 1 make[2]: Leaving directory '/home/gooberslot/tmp/zfs-utils/src/zfs-0.8.3/lib' make[1]: [Makefile:730: all-recursive] Error 1 make[1]: Leaving directory '/home/gooberslot/tmp/zfs-utils/src/zfs-0.8.3' make: [Makefile:599: all] Error 2

StayFrosty commented on 2020-02-13 02:55 (UTC)

This package builds fine on arm64 if the config.guess is updated or the config.guess provided on the system is used instead of the one included with the package.

francoism90 commented on 2020-01-27 17:53 (UTC) (edited on 2020-05-21 08:43 (UTC) by francoism90)

This PKG looks like it is missing a lot of stuff. I really recommend to use instead.

hoodie commented on 2020-01-03 14:51 (UTC)

Hi there! I get a this: ==> Verifying source file signatures with gpg... zfs-0.8.2.tar.gz ... FAILED (unknown public key 6AD860EED4598027)

has anything changed about that signature of the packages?

xiaoliniess commented on 2019-12-27 11:54 (UTC) (edited on 2019-12-27 11:57 (UTC) by xiaoliniess)

A small fix for zfs.initcpio.hook suggested:

  • if ! zpool list -H "${pool}" 2>&1 > /dev/null ; then

  • if ! zpool list -H "${pool}" > /dev/null 2>&1 ; then

From bash reference:

Note that the order of redirections is significant. For example, the command

ls > dirlist 2>&1

directs both standard output (file descriptor 1) and standard error (file descriptor 2) to the file dirlist, while the command

ls 2>&1 > dirlist

directs only the standard output to file dirlist, because the standard error was made a copy of the standard output before the standard output was redirected to dirlist.

andrius4669 commented on 2019-11-29 23:11 (UTC) (edited on 2019-11-29 23:20 (UTC) by andrius4669)

I've successfully built on aarch64 after adding ./ before ./configure.

For x86 and x86_64 that could be skipped, but I guess for most other archs it needs to be done, at least until upstream updates automake version they build configure scripts with.

alpine for example does autoreconf -vif in prepare:

zfs-dkms is unaffected by this issue because it does autoreconf -fi in prepare:

maybe add something like [ "$CARCH" != "x86" -a "$CARCH" != "x86_64" ] && autoreconf -vif in prepare(), also adding aarch64 to arch var would be nice as it built fine for me with that fix.

edit: fixed suggested autoreconf condition

chungy commented on 2019-11-16 00:46 (UTC)

Needs to be updated for Python 3.8

QDesjardin commented on 2019-10-28 19:50 (UTC)

I don't know if this is the right place, when I tried switching over to this zfs-utils package (from the one provided on archzfs), my system would not boot properly -- it would complain about being unable to import the zpools (was in use by another system with the hostid=0).

When I switched back over to the zfs-utils from archzfs, my system works once again.

eschwartz commented on 2019-10-16 03:49 (UTC)

aarch64 is not an officially supported architecture for this PKGBUILD, since I don't exactly test it on such architectures. It failing to work is therefore not very surprising.

I guess you can do any necessary followup in that upstream bug report, hopefully upstream can get it into a state of "working out of the box" so that makepkg --ignorearch works. But I'm not investing any of my own time in this...

isgar commented on 2019-10-15 11:12 (UTC)

To build on aarch64, config.sub and config.guess have to be updated:

ArchGalileu commented on 2019-10-02 18:59 (UTC)

Can't build on aarch64 :(


configure: error: cannot guess build type; you must specify one

any help?

Best regards ArchGalileu

freswa commented on 2019-09-27 14:58 (UTC)

Since dracut is in the official Arch repo, could we please include the dracut files here? Line 60 just needs to be deleted.

1k5 commented on 2019-09-14 14:01 (UTC)

Could we please have zfs_decrypt_fs functionality? (See shamer's comment.) It would be much appreciated!

kswt commented on 2019-07-02 20:13 (UTC)

mount.zfs does not work:

mount -t zfs zroot/data/default /mnt/ filesystem 'zroot/data/default' cannot be mounted at '/mount' due to canonicalization error 2.

eschwartz commented on 2019-06-03 20:30 (UTC)


Thank you. I've submitted an upstream fix as

ColdCanuck commented on 2019-06-03 18:55 (UTC)

The addition of the python3-fake soft link to /bin/true causes the utility program arc_summary not to be included in the package file. I assume this is because the upstream configurator needs to determine if a python3 or python2 version should be used and can't do that with the fake python.

There are other python scripts in the package so some version of python is a "soft" dependency., if not on the build at least on the programs themselves.

New to Arch, so sorry if this the the wrong way to notify you; I'm open to gentle education if there is a more correct way.

shamer commented on 2019-05-28 22:18 (UTC)

zfs.initcpio.hook does not yet have zfs_decrypt_fs functionality that is present in

This can prevent being able to boot into an encrypted root.

solenskiner commented on 2019-05-24 19:55 (UTC)

I've found a problem, zfs.initcpio.hook does not seem to honor canmount=off on datasets.

patch is something like

    canmount=$(zfs get -H -o value canmount "${dataset}")
    if [ "${canmount}" = "off" ] ; then

at line 61

milaxnuts commented on 2019-03-29 06:06 (UTC) (edited on 2019-03-29 06:07 (UTC) by milaxnuts)

please use "git shallow clone" to save traffic.

81.64 MiB :full clone
  5.56 MiB :shallow clone

--> less by factor 15

sample call:

git clone --depth=1 --recurse-submodules -b zfs-0.7.13

eschwartz commented on 2018-10-30 14:09 (UTC)

Valid point, but this should then be in zfs-dkms which provides the module and depends on the utils.

I removed it from spl-dkms too, because namespacing: is already a package and it sure isn't a kernel module. Didn't consider that zfs wouldn't have the same problem.

solnce commented on 2018-10-30 13:51 (UTC)

Thanks for putting this up. Unfortunately, this breaks some dependencies, because the PKGBUILD should include provides=zfs. Otherwise I can't have zfs-auto-snapshot installed.