Package Base Details: zfs-linux

Git Clone URL: (read-only, click to copy)
Submitter: demizer
Maintainer: minextu (archzfs-bot)
Last Packager: archzfs-bot
Votes: 250
Popularity: 1.96
First Submitted: 2016-04-21 08:45 (UTC)
Last Updated: 2022-07-03 22:21 (UTC)

Pinned Comments

Latest Comments

idimitro commented on 2022-06-20 16:43 (UTC)

Thanks for the info.

JLSalvador commented on 2022-06-20 06:48 (UTC)

@idimitro OpenZFS has some problems at upstream (FreeBSD, Dacrut, Debian, etc). These errors needs to be fixed in order to publish the OpenZFS version 2.1.5, that supports kernel 5.18.x and 5.19.x:

idimitro commented on 2022-06-20 06:25 (UTC)

Hi, any hope of getting the builds working? The zfs kernel has never been that slow.

brickstonedog commented on 2022-03-06 21:04 (UTC)

I just wanted to let you know, that Buildbot wasn't able to push the latest build to the AUR.

tripleo commented on 2022-03-03 10:32 (UTC)

Cannot build even in a chroot.

BruceR commented on 2021-12-27 07:16 (UTC)

@Egns if you want to build the zfs-linux package yourself you can use a chroot jail to perform the actual build. Update the kernel in the chroot to the version required by the build.

From there you can copy the package file to a custom local repository and add the repository to your /etc/pacman.conf.

tki commented on 2021-09-15 08:43 (UTC) (edited on 2021-09-15 08:44 (UTC) by tki)

There seems to be a bug where zfs mount/mount of encrypted datasets/zvols fail silently ( The upstream bug report doesn't seem to have gotten any attention in two months; does anyone know if it's an issue local to Arch?

francoism90 commented on 2021-09-14 07:04 (UTC) (edited on 2021-09-14 07:05 (UTC) by francoism90)

FYI: this doesn't compile with kernel 5.14, seems a new release is coming soon:

ginger commented on 2021-09-14 03:28 (UTC)

@Kevdog, Because this package is compiled against the specific Kernel package version currently in the Arch repos, whenever a kernel update gets posted to the Arch repos (which happened a couple of days ago), this package goes out-of-date until a new version is compiled, tested, and posted to the arch-zfs repo that corresponds to the correct kernel version.

Kevdog commented on 2021-09-14 03:24 (UTC)

Why was this package flagged out of date?

Egns commented on 2021-07-27 17:57 (UTC)

Thanks @ginger and @dmp1ce for your comments.

I was not using archzfs repo and did not add any mirrors for zfs-linux installation. I am installing it directly from AUR by yay. I will try to add mirrors for archzfs repo.

dmp1ce commented on 2021-07-27 15:04 (UTC)

Yes, I'm using the archzfs repo and I just wait until the zfs-linux and zfs-linux-lts is in sync so Pacman can update. Subscribing to the email updates here helps me time the updates.

ginger commented on 2021-07-27 12:45 (UTC)

@Egns Are you using one of the zfs-linux mirrors? If you are, I think you likely are upgrading just inside the mirror update time. There is a lag between when a new version is pushed to the zfs-linux master and when it gets percolated out to all the mirrors. For instance, my mirror updates on a random minute every hour, so there is some lag between when a package gets pushed by the maintainer and when the package is available on the mirror pacman/yay are looking at.

Egns commented on 2021-07-27 10:50 (UTC) (edited on 2021-07-27 10:54 (UTC) by Egns)

Sorry for a noob question.

How do you upgrade your system when a new kernel is released and zfs-linux was just updated to depend on that new kernel version?

So, like in this case:

(1) Previously installed version of zfs-linux depends on linux=5.13.4.arch1-1

(2) New kernel 5.13.5.arch1.1-1 is released

(3) zfs-linux's PKGBUILD gets updated to depend on the latest kernel version 5.13.5.arch1.1-1

(4) Now, when trying to upgrade the system by running yay, the following error is thrown

error: failed to prepare transaction (could not satisfy dependencies)
:: installing linux (5.13.5.arch1-1) breaks dependency 'linux=5.13.4.arch1-1' required by zfs-linux

So, what do you do in this case? Do you delete zfs-linux and upgrade the system and install it back? Or there is some other way to upgrade kernel and zfs-linux at the same time?

ozkan.kirik commented on 2021-07-27 04:10 (UTC)

linux kernel 5.13.5.arch1-1 was released on 26 Jul

francoism90 commented on 2021-07-03 07:19 (UTC)

Seems a lot of improvements have been made. Will wait with flagging as Linux 5.13 hasn't been released yet in the main repo. :)

francoism90 commented on 2021-01-21 18:02 (UTC) (edited on 2021-01-22 13:55 (UTC) by francoism90)

@tsj I'm using the zfs repo for this reason:

zfs-utils has a different maintainer as isn't in sync with this one.

tsj commented on 2021-01-09 23:47 (UTC)

At the time of this writing, PKGBUILD depends on zfs-utils-2.0.1 which does not exist in AUR. zfs-linux-git has the autoconf error mentioned by @minextu, installing aur/autoconf-git resolves build issue on this system. Switched back to core/autoconf after zfs build.

There are other unrelated warnings during the zfs build that look worrisome, this is the first time I have used zfs so cannot comment on functionality.

minextu commented on 2021-01-01 14:40 (UTC)

@tachyon_84 ZFS doesn't build with the autoconf 2.70 ( Just pushed an update with a workaround

tachyon_84 commented on 2020-12-31 21:27 (UTC)

New kernel version! Anything I can do to help add support?

mjevans commented on 2020-10-09 07:31 (UTC)

It is unfortunate, but on the very date this was updated archlinux updated to linux=5.8.14.arch1-1

-> Could not find all required packages: linux-headers=5.8.13.arch1-1 (Wanted by: zfs-linux)

archplayer commented on 2020-07-20 16:59 (UTC)

@Perseids Thank you.

Perseids commented on 2020-07-20 07:25 (UTC)

@archplayer See for details. I solved it via

# [ Optionally verify the downloaded key has the same fingerprint as the one you already have in your pacman keyring ]
sudo pacman-key -a archzfs.gpg

archplayer commented on 2020-07-20 04:06 (UTC) (edited on 2020-07-20 16:59 (UTC) by archplayer)

@minextu I'm getting an error with the signature:

error: archzfs: signature from "ArchZFS Bot <>" is unknown trust
error: failed to update archzfs (invalid or corrupted database (PGP signature))

air-g4p commented on 2020-04-22 16:37 (UTC) (edited on 2020-04-22 16:38 (UTC) by air-g4p)

@minextu I noticed that today (21 April) marks the zfs-linux AUR 4th anniversary - so congrats! However, I also noticed it took from 15 April until 21 April to add support for linux=5.6.5.arch3-1.

During that interim, 5.6.6-arch1-1 was released and has already been out for a few days, so I still cannot install zfs-linux and zfs-linux-headers on my main system due to the kernel version incompatibilities.

Is it possible to automate the zfs-linux AUR rebuild process on your end, so that zfs-linux automatically gets rebuilt upon a new Arch kernel hitting the repos?

Thank you for all your efforts! Cheers

minextu commented on 2020-04-07 12:51 (UTC)

@francoism90 Yes they are in the git repo ( and, so they should be stable.

francoism90 commented on 2020-04-07 07:19 (UTC)

@minextu Thanks for updating to Linux 5.6. :)

Is this upgrade stable and safe for daily use? Are these patches already in the git repo?

minextu commented on 2020-04-06 21:11 (UTC)

I added the necessary patches to make it work with linux 5.6

alem0lars commented on 2020-03-31 21:02 (UTC)

New version of Linux kernel has been released ( core/linux 5.5.13.arch2-1 ) making this version uncompatible

francoism90 commented on 2020-03-30 09:40 (UTC)

Will this be compatible with Linux 5.6? :)

minextu commented on 2020-03-01 21:08 (UTC)

@francoism90 There used to be a separate package for that. See the discussion on why it got removed:

francoism90 commented on 2020-03-01 13:53 (UTC)

@minextu Thanks for the update!

Could you please add your zfs-utils PKG as dep to AUR (e.g. zfs-linux-utils) instead? Current differs a lot and is being provided by someone else, causing issues.

yaogen commented on 2020-02-28 21:41 (UTC)

A fix to the 5.5 build issues has been merged. Updates should hopefully be coming soon.

francoism90 commented on 2020-02-06 09:51 (UTC)

@minextu Thanks for blocking Linux 5.5 and posting the upstream link. :)

To my understanding, even building the kernel with the patch, it may cause issues later on because it wasn't tested with Linux 5.5? Switching to linux-lts isn't a solution for everyone as it may cause other issues (AMD Zen2, Intel, etc.), unless things have been backported.

pasque commented on 2020-02-05 19:22 (UTC)

@minextu your PKGBUILD file still says linux 5.5.1.arch1-1 is a dependancy. Should it be linux 5.4.15.arch1-1 since ZFS is broken on 5.5?

minextu commented on 2020-02-05 00:09 (UTC) (edited on 2020-02-29 14:54 (UTC) by minextu)

ZFS is broken on linux 5.5 right now, so this won't build. For more information see

Edit: A patch has been implemented

minextu commented on 2020-01-27 18:32 (UTC)

@francoism90 using the repo definitely makes it easier to upgrade. If you want faster updates you can try the archzfs-testing repo. It automatically updates once per day but it's untested. That said, I didn't have any issues so far and I'm actually thinking about using the testing repository as the main one at some point.

Server =$repo/x86_64

francoism90 commented on 2020-01-27 08:43 (UTC) (edited on 2020-01-27 08:46 (UTC) by francoism90)

@minextu Should one use the repo instead when using linux as kernel?

However it doesn't always sync with the latest version in core:

warning: cannot resolve "linux=5.4.14.arch1-1", a dependency of "zfs-linux"
warning: cannot resolve "linux=5.4.14.arch1-1", a dependency of "zfs-linux-headers"
:: The following packages cannot be upgraded due to unresolvable dependencies:
      zfs-linux  zfs-linux-headers

ipickering commented on 2020-01-26 17:47 (UTC)

@minextu Thanks, this worked for me.

minextu commented on 2020-01-26 05:28 (UTC)

@ipickering I don't maintain the aur version of zfs-utils, so I don't have any control over this. You can use this PKGBUILD in the meantime:

ipickering commented on 2020-01-26 02:28 (UTC)

I can no longer install this package, because it requires zfs-utils 0.8.3, but only 0.8.2-2 is in the AUR. Normally I uninstalled zfs-linux to get around the fact that I can't do pacman -Syu because of the kernel dependency but this leaves me stuck without ZFS. Will zfs-utils be updated soon?

CoolGenie commented on 2020-01-19 19:57 (UTC)

@torben thank you for the suggestion! I think linux-lts and zfs-linux-lts is the best option here.

minextu commented on 2020-01-18 20:21 (UTC)

@CoolGenie zfs-linux is in sync with arch core right now. The error you are getting happens because you have an old version of zfs-linux installed. So you need to remove the old one first before updating.

If this is too much effort, you can also use the archzfs repository ( or zfs-dkms.

PS: There is a variable called _kernelver in the PKGBUILD, which you can adjust and rebuild if the aur version is out of date.

dmp1ce commented on 2020-01-18 19:43 (UTC)

Right! In your account settings "Notify of package updates" needs to be checked too. It was unchecked for me. Now I'll probably get way more emails than I want!

torben commented on 2020-01-18 19:36 (UTC)

qdmp1ce: Just klick on "Enable notifications" in the "Package Actions" box on the top right. IIRC you have to create an account to do so.

dmp1ce commented on 2020-01-18 15:03 (UTC)

@torben, how do you subscribe to zfs-linux updates?

torben commented on 2020-01-18 10:36 (UTC)

@CoolGenie: The problem here is, that current Arch is a moving target, that's difficult to follow at times. For me personally I've tried a few options you might try as well:

a) Switch to the ZFS Kernel LFS branch (zfs-linux-lts), this is what I use. You'll less frequent kernel updates, I haven't had much of a problem with the LTS branch and ZFS since I switched to it. Works well and using the LTS kernel might actually be preferrably on servers. On cutting edge desktops/notebooks this might not be an option though; but since ZFS is more of a server technology, this shouldn't be that much of a point. I'd recommend this approach.

b) Subscribe to zfs-linux package updates and do your pacman update right after the ZFS upgrade is out. This worked for me most of the time I was quick enough, I just didn't see any advantage over the LTS branch so I stopped doing so.

c) Use the DKMS version, which custom-builds the modules on your box, I've tried this once but didn't get it to run, however, as far as I understand this should work in principle (probably I missed something when I tried it).

CoolGenie commented on 2020-01-18 05:35 (UTC)

I understand the pains of open source development and much appreciate the work everyone is doing at Arch, however I've been unable to upgrade for over a month now with the error:

error: failed to prepare transaction (could not satisfy dependencies) :: installing linux (5.4.12.arch1-1) breaks dependency 'linux=5.4.1.arch1-1' required by zfs-linux

I think it's important to follow the upstream kernel because this blocks any security updates from the upstream Arch. And, when having migrated important data to ZFS, I can't just uninstall zfs-linux :)

WhiteKnight commented on 2019-12-13 09:08 (UTC)

@CoolGenie you need to wait until the zfs-linux package gets updated with the current kernel as dependency.

CoolGenie commented on 2019-12-13 06:58 (UTC)

Anyone know why I'm getting: installing linux (5.4.2.arch1-1) breaks dependency 'linux=5.4.1.arch1-1' required by zfs-linux

Hetsh commented on 2019-10-19 08:21 (UTC)

Root on encrypted ZFS can be decrypted during boot when adding "zfs load-key -a" around line 54 in the mkinitcpio hook "/usr/lib/initcpio/hooks/zfs". @minextu maybe consider as permanent patch?

minextu commented on 2019-09-21 23:09 (UTC)

@dawnofman It didn't break anything but it's fixed now, thanks!

dawnofman commented on 2019-08-18 23:49 (UTC)

dunno whether this is relevant or not but: --libexecdir=/usr/lib/zfs-${zfsver} should be: --libexecdir=/usr/lib/zfs-${_zfsver} it is not the same variable; it is being built as: --libexecdir='/usr/lib/zfs-'

chungy commented on 2019-07-24 06:41 (UTC)

It's likely to be part of 0.8.2, but could e5db31349484e5e859c7a942eb15b98d68ce5b4d be cherry-picked to be included in this package? It restores SIMD compatibility on the latest 4.14.x/4.19.x/5.x kernels. Debian is already including this patch in their 0.8.1 package :)

minextu commented on 2019-05-26 15:05 (UTC) (edited on 2019-05-26 15:06 (UTC) by minextu)

@andybz zfs-utils and zfs-dkms have a different maintainer and I don't have access to update.

You can use and in the meantime or update using the archzfs repo (

andybz commented on 2019-05-26 07:06 (UTC)

I moved from zfs-dkms to this package to get ZFS 0.8.0, but I had trouble with no package actually providing zfs-utils=0.8.0.

I ended up just bumping the pkgver on the zfs-utils package to 0.8.0 and I'm OK again but I haven't worked out yet whether there's a packaging issue here or what.

ShaunPC commented on 2019-05-05 00:18 (UTC) (edited on 2019-05-05 00:18 (UTC) by ShaunPC)

The reason this happens with both the archzfs repo and the AUR package is because the non-dkms package is compiled against a specific version of the Linux kernel. When the Arch kenel gets updated, this package falls out of date. This is only ever the case for 1-2 days. As I understand it there is a certain amount of automation involved. Just be patient and wait for a day before trying to update again. No manual process is needed.

Ruli commented on 2019-05-05 00:17 (UTC)

Got it. Thanks again! It's been a while since I encountered this problem, I've somehow forgotten about it... sorry for the hassle!

dmp1ce commented on 2019-05-05 00:08 (UTC)

I think what described is also the case for archzfs repository. I also use archzfs and I get the same error often. I just wait until the packages get updated with working dependencies. Flagging the package as out-of-date might help the maintainers become aware of the issue.

Ruli commented on 2019-05-05 00:04 (UTC)

Hi @dmp1ce, thanks for your reply! Sorry, I should have clarified before that I'm using the archzfs repo. I remember in the past that I would have to manually update the dependencies, but ever since using the archzfs repo I didn't have to do this anymore. Anyway, I will do a manual update first then. Thank you once again!

dmp1ce commented on 2019-05-04 23:49 (UTC)

@Ruli that is typical with this package. The reason is because of a dependency on a specific linux version. I don't know the reason for the specific linux version but I assume it is for a good reason. I think there has been some work on automating the new releases when new linux kernels comes out but I'm not sure about the details.

Someone please correct me where I am wrong.

Ruli commented on 2019-05-04 23:38 (UTC)

Hi, when I tried to do pacman -Syu today, I got the following message:

resolving dependencies... warning: cannot resolve "linux=5.0.10.arch1-1", a dependency of "spl-linux" warning: cannot resolve "linux=5.0.10.arch1-1", a dependency of "spl-linux-headers" warning: cannot resolve "linux=5.0.10.arch1-1", a dependency of "spl-linux" warning: cannot resolve "linux=5.0.10.arch1-1", a dependency of "zfs-linux" warning: cannot resolve "linux=5.0.10.arch1-1", a dependency of "spl-linux" warning: cannot resolve "linux=5.0.10.arch1-1", a dependency of "zfs-linux-headers" :: The following packages cannot be upgraded due to unresolvable dependencies: spl-linux spl-linux-headers zfs-linux zfs-linux-headers

Is anyone else seeing this as well? Thanks in advance!

ozkan.kirik commented on 2018-11-10 16:45 (UTC)

Dependency zfs-utils-common is missing. So package couldn't be compiled

minextu commented on 2018-07-21 04:04 (UTC) (edited on 2018-07-22 07:34 (UTC) by minextu)

Hi everyone, as you might know: I'm the new Maintainer of archzfs ( As soon as I get access to the domain, I will update all packages. I've implemented an automated build system to help update packages faster in the future. The new gpg key for the repo is F75D9D76 ArchZFS Bot <>. If you are using the archzfs repo, you will need to add this key to pacman's trusted key list.

pacman-key -r F75D9D76
pacman-key --lsign-key F75D9D76

Edit: Packages are now up to date on The temporary domain is no longer needed

whitesnow commented on 2018-07-19 16:41 (UTC)

I'm not the person, to answer that. But what I read here:

sounds very positive. There is even a temporary domain set up now. Read yourself there.

sonix07 commented on 2018-07-19 14:02 (UTC)

I'm aware of the maintainer change, but will this package get an update in the near future or is the dkms version the way to go now?

jgerecke commented on 2018-06-02 17:55 (UTC) (edited on 2018-06-02 18:12 (UTC) by jgerecke)

May I suggest modifying the PKGBUILD and zfs.install script to make it both easier to update and easier to verify that new updates (e.g. through aurman) aren't malicious? The following patch puts the ZFS and kernel versions into variables that we reuse rather than hardcoding strings in a half-dozen places. It also has the install script determine the kernel version automagically from the version string passed in by pacman. Similar modifications could/should be made to other packages (e.g. spl).

diff --git a/PKGBUILD b/PKGBUILD
index 6f1a8a3..5369240 100644
@@ -17,24 +17,26 @@
 pkgname=("zfs-linux" "zfs-linux-headers")

+pkgver="${zfsver}.$(echo ${kernelver} | tr '-' '.')"
-makedepends=("linux-headers=4.16.11-1" "spl-linux-headers")
+makedepends=("linux-headers=${kernelver}" "spl-linux-headers")
-depends=("kmod" "spl-linux" "zfs-utils-common=0.7.9" "linux=4.16.11-1")
+depends=("kmod" "spl-linux" "zfs-utils-common=${zfsver}" "linux=${kernelver}")

 build() {
-    cd "${srcdir}/zfs-0.7.9"
+    cd "${srcdir}/zfs-${zfsver}"
     ./configure --prefix=/usr --sysconfdir=/etc --sbindir=/usr/bin --libdir=/usr/lib \
                 --datadir=/usr/share --includedir=/usr/include --with-udevdir=/lib/udev \
-                --libexecdir=/usr/lib/zfs-0.7.9 --with-config=kernel \
-                --with-linux=/usr/lib/modules/4.16.11-1-ARCH/build \
-                --with-linux-obj=/usr/lib/modules/4.16.11-1-ARCH/build
+                --libexecdir=/usr/lib/zfs-${zfsver} --with-config=kernel \
+                --with-linux=/usr/lib/modules/${kernelver}-ARCH/build \
+                --with-linux-obj=/usr/lib/modules/${kernelver}-ARCH/build

@@ -45,7 +47,7 @@ package_zfs-linux() {
-    cd "${srcdir}/zfs-0.7.9"
+    cd "${srcdir}/zfs-${zfsver}"
     make DESTDIR="${pkgdir}" install
     cp -r "${pkgdir}"/{lib,usr}
     rm -r "${pkgdir}"/lib
@@ -56,9 +58,9 @@ package_zfs-linux() {
 package_zfs-linux-headers() {
     pkgdesc="Kernel headers for the Zettabyte File System."
     conflicts=('zfs-archiso-linux-headers' 'zfs-archiso-linux-git-headers' 'zfs-linux-hardened-headers' 'zfs-linux-hardened-git-headers' 'zfs-linux-lts-headers' 'zfs-linux-lts-git-headers'  'zfs-linux-git-headers' 'zfs-linux-vfio-headers' 'zfs-linux-vfio-git-headers' 'zfs-linux-zen-headers' 'zfs-linux-zen-git-headers' )
-    cd "${srcdir}/zfs-0.7.9"
+    cd "${srcdir}/zfs-${zfsver}"
     make DESTDIR="${pkgdir}" install
     rm -r "${pkgdir}/lib"
     # Remove reference to ${srcdir}
-    sed -i "s+${srcdir}++" ${pkgdir}/usr/src/zfs-*/4.16.11-1-ARCH/Module.symvers
+    sed -i "s+${srcdir}++" ${pkgdir}/usr/src/zfs-*/${kernelver}-ARCH/Module.symvers
diff --git a/zfs.install b/zfs.install
index eda162b..cc32a25 100644
--- a/zfs.install
+++ b/zfs.install
@@ -1,20 +1,21 @@
 post_install() {
-    check_initramfs
+    check_initramfs "$1"

 post_remove() {
-    check_initramfs 'remove'
+    check_initramfs "$1" 'remove'

 post_upgrade() {
-    check_initramfs
+    check_initramfs "$1"

 check_initramfs() {
+    KERNELVER=$(echo "$1" | rev | cut -d'-' -f2 | cut -d'.' -f1-4 | sed 's/\./-/' | rev)
     echo ">>> Updating ZFS module dependencies"
-    depmod -a 4.16.11-1-ARCH
+    depmod -a ${KERNELVER}-ARCH
     MK_CONF=$(grep -v '#' /etc/mkinitcpio.conf | grep zfs >/dev/null; echo $?);
-    if [[ ${MK_CONF} == '0' && $1 == 'remove' ]]; then
+    if [[ ${MK_CONF} == '0' && $2 == 'remove' ]]; then
         echo '>>> The ZFS packages have been removed, but "zfs" remains in the "hooks"'
         echo '>>> list in mkinitcpio.conf! You will need to remove "zfs" from the '
         echo '>>> "hooks" list and then regenerate the initial ramdisk.'

minextu commented on 2018-05-01 18:04 (UTC)

@robguinness You need to set the kernel version on multiply places (See

robguinness commented on 2018-04-29 17:32 (UTC)

I am new to AUR. I am running kernel 4.16.5-1-ARCH, but this package requires 4.16.4-1. Is fixing this package for 4.16.5-1 as simple changing the version numbers in PKGBUILD, or does something else in the source files need to be changed, too?

commented on 2018-04-19 19:16 (UTC)

linux 4.15.15 left Arch repositories!

demizer commented on 2018-04-09 22:21 (UTC)

Got an email 0.7.8 is being worked on and will be released shortly. If it does not come out in the next day, I will revert to 0.7.6. Thanks!

NoSuck commented on 2018-04-09 18:57 (UTC) (edited on 2018-04-09 18:59 (UTC) by NoSuck)

A confirmed regression in 0.7.7 results in data loss during copy operations. So far, the issue has not been reported as reproducible on Arch Linux. The steps to reproduce are simple:

# mkdir SRC
# for i in $(seq 1 10000); do echo $i > SRC/$i ; done
# cp -r SRC DST
cp: cannot create regular file `DST/8442': No space left on device
cp: cannot create regular file `DST/2629': No space left on device

For more discussion, see GitHub:

webdawg commented on 2018-02-26 02:56 (UTC)

looks like more then three days hossbeast

hossbeast commented on 2018-02-26 00:18 (UTC)

linux has moved to 4.15.5 - when will this package be updated?

justinkb commented on 2018-02-06 04:48 (UTC)

Looks like my issue was caused by a critical bug in 4.15. I'm now on 4.15.1 with some patches and it works fine with the patch below

severach commented on 2018-02-01 00:48 (UTC)

There's nothing to fear. I've run zfs-git for 3 years and there has never been a data loss event. The only event was a performance problem that was fixed in 4 hours.

justinkb commented on 2018-01-31 23:13 (UTC) (edited on 2018-01-31 23:19 (UTC) by justinkb)

I build three sets of out-of-tree kmods, just ZFS, Vbox (which I don't think were even used/inserted) and nvidia-drivers. The only one I can conceivably see taking down those kernel subsystems are the ZFS filesystem drivers. But I'll try to see if any of the other two were responsible later tonight. PS. I don't actually even use arch anymore, but the arch community remains a very valuable resource so I still come here ;) PPS. I'm not brave enough to use the ZFS git master packages... not by a long shot. I have many terabytes of data in my ZFS pool

minextu commented on 2018-01-31 22:58 (UTC)

I haven't had any issues on 4.15 so far. Did you try using the git packages with 4.15? If you get the same problem there, it might be an upstream issue

justinkb commented on 2018-01-31 21:59 (UTC) (edited on 2018-01-31 22:00 (UTC) by justinkb)

Tried zfs on 4.15 with just the patch linked below, definitely not ready for primetime. Huge issues with the filesystem and even block device subsystems totally borking out (luckily didn't lose any data, other than some small files getting corrupted because of unclean shutdowns). Stay on 4.14.x for now

severach commented on 2018-01-31 06:20 (UTC) (edited on 2018-01-31 06:21 (UTC) by severach)

Easy! Get Oracle to relicense away from the CDDL to be non hostile to the GPL.

You're not the first to want this.

webdawg commented on 2018-01-31 05:02 (UTC)

What do we have to do to push this as an official package and get your more support?

ZFS is an incredible filesystem, having it as a rootfs can set archlinux apart.

justinkb commented on 2018-01-30 00:11 (UTC)

Ah, you're right. For some reason I thought it had

minextu commented on 2018-01-29 23:42 (UTC)

Yep, it hasn't changed though

justinkb commented on 2018-01-29 23:29 (UTC) (edited on 2018-01-29 23:30 (UTC) by justinkb)

This looks like an updated version of that patch that actually got merged upstream, and signed-off by one of the main developers of zfs, are you aware of it?

minextu commented on 2018-01-29 22:25 (UTC)

SPL got already patched for 4.15, you just need to apply the patch like done here: There's also a pending pull request for archzfs (

justinkb commented on 2018-01-29 22:16 (UTC)

I can't find any info about linux 4.15 on any of the online resources available for openzfs, I've basically looked everywhere, support forums, github issues, the website, nobody is saying anything about it. Anyone got an ETA on when it'll be available? If it'll take long, I'll have to work out a workaround for my use case, that's why I'm asking.

pandascience commented on 2018-01-15 09:15 (UTC)

Please see ethan_nx's answer below for a workaround for fully upgrading your system. As far as I understood there is no better and still secure way at the moment, but you can help to minimize the lag between new kernel and zfs-linux releases by e.g. flagging the package out-of-date after you recognized it.

jamorton commented on 2018-01-13 06:40 (UTC) (edited on 2018-01-13 06:41 (UTC) by jamorton)

every time I check on this package, it has been updated, but it is still out of date because linux has subsequently also updated. Whenever this package is out of date, which is almost always, I cannot upgrade my sysem at all.

surely there's a better way?

timemaster commented on 2017-12-27 02:22 (UTC)

@francoism90, are you really sure you want to use zfs encryption as soon as it is released ? You want to beta test this ? I am interested in it too, but I will wait a little wait for it to get more stable before using it.

minextu commented on 2017-12-18 12:51 (UTC) (edited on 2017-12-18 12:51 (UTC) by minextu)

@francoism90 No, no yet. It might get included in zfs 0.8

francoism90 commented on 2017-12-18 12:46 (UTC)

Can someone please confirm if ZFS encryption now has been included in stable?

predmijat commented on 2017-12-14 12:08 (UTC)

After the latest update ZFS didn't start on boot. I had to re-enable and now it's fine.

minextu commented on 2017-12-03 21:16 (UTC)

Working on it (,

It's because the patch for linux 4.14 hasn't made it into a stable release yet

misanthropist commented on 2017-12-03 21:10 (UTC)

@eblau I have the exact same problem, both with this and the DKMS version.

eblau commented on 2017-12-03 21:04 (UTC) (edited on 2017-12-03 21:04 (UTC) by eblau)

I'm hitting errors booting from a root zfs filesystem after installing the latest (

modprobe: ERROR: could not insert 'zfs': Unknown symbol in module, or unknown parameter (see dmesg)

When I check dmesg, I see:

spl: Unknown symbol vfs_write (err 0)

spl: Unknown symbol vfs_read (err 0)

spl: Unknown symbol vfs_write (err 0)

spl: Unknown symbol vfs_read (err 0)

I checked both zfs and spl kernel modules with modinfo and they show the version as 0.7.3-1 and vermagic as 4.14.3-1-ARCH so it appears that I have the correct modules installed and loaded in the initramfs.

I downgraded to kernel 4.13.12 and everything works fine.

biax commented on 2017-09-28 10:24 (UTC)

4.13.3 kernel is released.

demizer commented on 2017-07-28 10:16 (UTC)

New packages with OpenZFS 0.7.0 support have been pushed to the archzfs repo for linux and linux-lts kernels However, the PKGBUILDs for spl-linux and zfs-linux have been changed to split packages and I cannot upload the updated PKGBUILDS to AUR until the (spl|zfs)-${KERNEL}-headers repos are removed by the admins.

chungy commented on 2017-07-27 00:39 (UTC)

0.7.0 released

predmijat commented on 2017-07-17 16:57 (UTC) (edited on 2017-07-18 18:10 (UTC) by predmijat)

@minextu thank you!

minextu commented on 2017-07-17 16:44 (UTC)

@predmijat Because every zfs package needed a separate zfs/spl-utils package that was basically the same on all kernels, there will be only one zfs/spl-utils-common package for all kernels going forward (see Pacman should just ask you to replace any old utils package with the new one, so you won't have to do anything special.

predmijat commented on 2017-07-15 09:38 (UTC)

Could you elaborate on "The second one changes the names of the packages in AUR."? What is the proper way to update the system when the name changes?

demizer commented on 2017-07-14 18:14 (UTC) (edited on 2017-07-14 18:14 (UTC) by demizer)

Hi everyone, thanks to @minextu have have some big updates in the works. I am currently testing the changes. * support for linux-hardened kernel * Support installing multiple archzfs package groups side by side * support for stable The second one changes the names of the packages in AUR.

khenderick commented on 2017-07-11 11:25 (UTC)

@demizer, just a heads up that is releases, which seems to address the gcc issues.

Enoid commented on 2017-06-25 21:50 (UTC)

As I upgraded from 4.10.13 to 4.11.6, I cannot use zfs-linux-git (rather I do not want to downgrade). zfs-dkms seems to work on my Linux.

severach commented on 2017-06-23 08:41 (UTC) (edited on 2017-06-23 08:41 (UTC) by severach)

I've used -git for a couple of years. The ZOL git repo is reliable. You can also run an LTS kernel.

NoSuck commented on 2017-06-23 07:21 (UTC)

Since first installing Arch three years ago, the longest I had gone without performing a system update was two weeks--until now. What's everyone doing? Are most of you using archzfs-git? It doesn't feel right running a kernel that's been publicly disclosed as insecure.

demizer commented on 2017-06-15 01:05 (UTC) (edited on 2017-06-15 01:05 (UTC) by demizer)

A new stable release of OpenZFS version is out, but it does not address the gcc 7.1.1 build errors. These packages will remain out-of-date until a stable release of OpenZFS is made fixing the gcc build issues. That might take some time. Until then, if anyone really needs to update their kernel, use the archzfs-git packages.

demizer commented on 2017-05-23 17:59 (UTC)

@eblau, some work has been done on this in this branch: Unfortunately, I have not had time to finish this yet. Thanks

demizer commented on 2017-05-23 17:55 (UTC)

The git packages have been updated to support kernel 4.11, but it looks like we're going to be waiting for another OpenZFS stable release for the archzfs stable packages: ==> Starting build()... autoreconf: Entering directory `.' autoreconf: not using Gettext autoreconf: running: aclocal --force -I config autoreconf: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'config'. libtoolize: copying file 'config/' libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'config'. libtoolize: copying file 'config/libtool.m4' libtoolize: copying file 'config/ltoptions.m4' libtoolize: copying file 'config/ltsugar.m4' libtoolize: copying file 'config/ltversion.m4' libtoolize: copying file 'config/lt~obsolete.m4' autoreconf: running: /usr/bin/autoconf --force autoreconf: running: /usr/bin/autoheader --force autoreconf: running: automake --add-missing --copy --force-missing installing 'config/compile' installing 'config/missing' cmd/ installing 'config/depcomp' autoreconf: Leaving directory `.' checking for gawk... gawk checking metadata... META file checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking whether to enable maintainer-specific portions of Makefiles... no checking whether make supports nested variables... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking whether make sets $(MAKE)... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for a working dd... /usr/bin/dd checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1 checking for mt... no checking if : is a manifest tool... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking spl author... OpenZFS on Linux checking spl license... GPL checking linux distribution... arch checking default package type... tgz checking whether rpm is available... no checking whether rpmbuild is available... no checking whether spec files are available... yes (rpm/generic/* checking whether dpkg is available... no checking whether dpkg-buildpackage is available... no checking whether alien is available... no checking spl config... kernel checking kernel source directory... /usr/lib/modules/4.11.2-1-ARCH/build checking kernel build directory... /usr/lib/modules/4.11.2-1-ARCH/build checking kernel source version... 4.11.2-1-ARCH checking kernel file name for module symbols... Module.symvers checking whether debugging is enabled... no checking whether basic kmem accounting is enabled... no checking whether detailed kmem tracking is enabled... no checking whether modules can be built... yes checking whether atomic types use spinlocks... no checking whether kernel defines atomic64_t... yes checking whether old 2-argument shrinker exists... no checking whether old 3-argument shrinker exists... no checking whether new 2-argument shrinker exists... no checking whether ->count_objects callback exists... yes checking whether struct ctl_table has ctl_name... no checking whether CONFIG_TRIM_UNUSED_KSYM is disabled... yes checking whether PDE_DATA() is available... yes checking whether set_fs_pwd() requires const struct path *... yes checking whether vfs_unlink() wants 2 args... no checking whether vfs_unlink() wants 3 args... yes checking whether vfs_rename() wants 4 args... no checking whether vfs_rename() wants 5 args... no checking whether vfs_rename() wants 6 args... yes checking whether vfs_fsync() wants 2 args... yes checking whether truncate_range() inode operation is available... no checking whether struct fs_struct uses spinlock_t... yes checking whether kuid_t/kgid_t is available... yes; mandatory checking whether __put_task_struct() is available... no checking whether fops->fallocate() exists... yes checking whether iops->fallocate() exists... no checking whether fops->fallocate() exists... no checking whether CONFIG_ZLIB_INFLATE is defined... yes checking whether CONFIG_ZLIB_DEFLATE is defined... yes checking whether zlib_deflate_workspacesize() wants 2 args... yes checking whether struct shrink_control exists... yes checking whether struct rw_semaphore member wait_lock is raw... yes checking whether struct rw_semaphore has member activity... no checking whether struct rw_semaphore has atomic_long_t member count... yes checking whether header linux/sched/rt.h exists... yes checking whether vfs_getattr() wants... configure: error: unknown ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Build failed, check /opt/chroot/x86_64/demizer/build Thanks!

eblau commented on 2017-03-17 13:13 (UTC)

Is it possible to install the zfs-linux and zfs-linux-lts family of packages side-by-side? Does anyone have a suggestion on how to do so? Currently there are file conflicts so this can't be done easily. You must choose one or the other set of packages. I had to revert to linux-lts recently due to bugs in the 4.10.x "stable" series for i915 that cause complete system hangs with no plans to supply fixes to 4.10.x. See: It would be great if the ZFS packages could live together on the same system just like linux and linux-lts can. It seems that if the ZFS version is the same, the packages could be restructured in such a way that the modules don't conflict and any headers or supplementary files from ZFS could live in one place. Am I oversimplifying the problem? Any suggestions on an approach to try to help with this? Do I need to move to the dkms packages?

gmtch commented on 2017-03-15 16:33 (UTC)

@ShaunPC thanks for the explanation. I reinstalled 23-1 and rebooted without any issue.

ShaunPC commented on 2017-03-15 12:52 (UTC)

@gmtch you can allow mkinitcpio generate the image and reboot using 23-1. The module that couldn't be found does exist in the kernel already. A commit to mkinitcpio will check for built-in modules like this one in a later update. The check was missing and as a result the error was produced when there wasn't really an error. I did the update with 23-1 and rebooted after the error was produced on the screen. No issues to report. It seems to be a non-error due to 23-1 not checking for built-in modules.

gmtch commented on 2017-03-15 12:44 (UTC)

I got the same error as ShaunPC at 2017-03-15 02:46 and downgraded to mkinitcpio-22-1 The initramfs built okay and box rebooted without problem.

ShaunPC commented on 2017-03-15 02:46 (UTC) (edited on 2017-03-15 03:01 (UTC) by ShaunPC)

When doing an update I got the following error: (21/21) upgrading zfs-linux [##########################################################################] 100% >>> Updating ZFS module dependencies >>> Generating initial ramdisk, using mkinitcpio. Please wait... ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default' -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img ==> Starting build: 4.10.2-1-ARCH -> Running build hook: [base] -> Running build hook: [udev] -> Running build hook: [autodetect] -> Running build hook: [modconf] -> Running build hook: [block] -> Running build hook: [keyboard] -> Running build hook: [zfs] ==> ERROR: module not found: `zlib_deflate' -> Running build hook: [filesystems] -> Running build hook: [shutdown] ==> Generating module dependencies ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img ==> WARNING: errors were encountered during the build. The image may not be complete. I'm not sure what I can do to fix this, if anything. Update: Found a related bug Module errors during build with mkinitcpio 23-1, however, it doesn't seem to break anything.

eblau commented on 2017-03-14 19:08 (UTC)

Thanks for the quick package update for linux-4.10.2_1-1!

NoSuck commented on 2017-03-12 11:36 (UTC)

Hi, everyone. Until now, I have waited at least 24 hours before updating ZFS, in order for you to be my guinea pigs. Starting today, that is no more. I'm moving to the front lines. Happy scrubbing.

ShaunPC commented on 2017-02-24 20:12 (UTC)

@Lindhe I had the same problem. I found that I got the 4.9.11-1 update by doing 'pacman -Syyu' instead of 'pacman -Syu'. This will force a refresh of the available packages, even if pacman thinks it has the latest. Hope that helps.

Lindhe commented on 2017-02-24 19:43 (UTC)

I see that on this page it says that it depends on linux=4.9.11-1, but pacman still says "zfs-linux: installing linux (4.9.11-1) breaks dependency 'linux=4.8.13'". Do I need to do some vodo witchcraft to make it work?

demizer commented on 2017-02-11 18:18 (UTC)

Hello everyone. Packages have not been updated in a while because I am working to switch them over to use "extramodules" so that they only need to be updated once for a major version. See

lockheed commented on 2017-02-09 09:24 (UTC)

@luc, if only it was that easy: :: spl-linux: installing linux (4.9.7-1) breaks dependency 'linux=4.8.13' :: zfs-linux: installing linux (4.9.7-1) breaks dependency 'linux=4.8.13' :: zfs-utils-linux: installing linux (4.9.7-1) breaks dependency 'linux=4.8.13'

luc commented on 2017-02-09 09:21 (UTC)

@lockheed You can download the matching linux package from:

lockheed commented on 2017-02-09 09:09 (UTC)

Damn it. I missed the one-day update window and now I am still stuck with kernel 4.8 and old ZFS package...

ShaunPC commented on 2017-02-08 12:22 (UTC)

@demizer Thank you for taking the time out of your day to make our lives a little easier.

predmijat commented on 2016-12-10 14:42 (UTC)

I've been using this package for a while now, and it did happen earlier. You were just lucky not to update until it got sorted out.

eblau commented on 2016-12-10 13:23 (UTC)

@predmijat Yeah, that's the way it has always worked for me as long as I've been using the zfs packages from demizer over the past year. It wouldn't update the linux kernel as long as the zfs packages were out-of-date. Maybe something changed in ?

predmijat commented on 2016-12-09 23:48 (UTC)

Why is this happening each couple of updates? Can it be set up so that it always requires a specific version? Is there a situation where you wouldn't want that?

eblau commented on 2016-12-09 11:36 (UTC)

This morning when I did a system upgrade, linux upgraded to linux-4.8.12-3-x86_64 but the zfs packages stayed at version When mkinitcpio ran, it failed: ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default' -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img ==> Starting build: 4.8.12-3-ARCH -> Running build hook: [base] -> Running build hook: [udev] -> Running build hook: [resume] -> Running build hook: [autodetect] -> Running build hook: [modconf] -> Running build hook: [block] -> Running build hook: [keyboard] -> Running build hook: [zfs] ==> ERROR: module not found: `zavl' ==> ERROR: module not found: `znvpair' ==> ERROR: module not found: `zunicode' ==> ERROR: module not found: `zcommon' ==> ERROR: module not found: `zfs' ==> ERROR: module not found: `zpios' ==> ERROR: module not found: `spl' ==> ERROR: module not found: `splat' -> Running build hook: [filesystems] -> Running build hook: [fsck] ==> Generating module dependencies ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img ==> WARNING: errors were encountered during the build. The image may not be complete. Just a warning to others. This could render systems unbootable. I downgraded to linux-4.8.12-2 and everything seems fine, but it seems that something is not right in the package dependencies.

ahyeadude commented on 2016-12-07 02:56 (UTC)

Point release versions of the kernel are bug/security fixes. No new features are added. I modified his packages to use the extramodules-* folder like the nvidia package and have been using zfs compiled all the way back at 4.8.4. Working great on 4.8.12 right now. I sent him these modifications. Hopefully he implements for 4.9. vermagic: 4.8.4-1-ARCH

z3ntu commented on 2016-11-17 17:05 (UTC) (edited on 2016-11-17 17:08 (UTC) by z3ntu)

Broken for linux 4.8.8-2... Please also add the pkgrel so linux=4.8.8-2 instead of linux=4.8.8 . Thanks

ethan_nx commented on 2016-11-16 23:14 (UTC)

For anyone stuck with a system-wide upgrade, here's the trick. Add these lines to /etc/pacman.conf: IgnorePkg=linux IgnorePkg=linux-headers IgnorePkg=spl-linux IgnorePkg=spl-utils-linux IgnorePkg=zfs-linux IgnorePkg=zfs-utils-linux Both kernel and ZFS-related updates will be ignored, the rest should upgrade just fine. When the new packages are available, just comment these lines. It works for me more than fine. @demizer, thank you for your packages!

sargasso commented on 2016-11-13 05:08 (UTC) (edited on 2016-11-13 23:56 (UTC) by sargasso)

@demizer Please keep up the good work. Release only when you have concluded it is "safe enough". @danlamanna, @ahyadude The NVidia driver is not comparable to a filesystem. I don't mind fiddling around to get a graphic interface. It has no bearing on the rest of the system/network. A corrupt filesystem on the other hand is pure agony. It takes much longer to determine the date and time the corruption occurred and to restore the correct backups. And during this time none of the clients can login.

danlamanna commented on 2016-11-10 15:47 (UTC)

+1 for pinning this to a kernel minor version (similar to nvidia) rather than a specific release.

predmijat commented on 2016-10-20 05:35 (UTC)

@lukewink - Just wait for an update of this package.

lukewink commented on 2016-10-20 04:17 (UTC)

I'm not sure how to update zfs-linux. When I run pacman -S zfs-linux, I get the error: warning: cannot resolve "linux=4.7.6", a dependency of "zfs-linux" When I attempt to upgrade linux, I get the following error: :: zfs-linux: installing linux (4.8.2-1) breaks dependency 'linux=4.6.4' The only way I can think of to update is to uninstall zfs-linux, then update linux, then re-install zfs-linux. Is that the correct workflow?

ahyeadude commented on 2016-10-04 22:08 (UTC)

Just a suggestion... Could you change the install requirement to the minor version number instead of the point release. A module built on 4.7.5 should work fine on 4.7.6. The nvidia ( package works this way. It would cut down on your work and the user complaints about being out of date. Thanks.

NoSuck commented on 2016-09-17 12:35 (UTC) (edited on 2016-09-17 12:36 (UTC) by NoSuck)

@demizer: Thank you not only for the testing and updates but also for addressing @butler360's answer to my inquiry. These past few weeks have been pretty crazy.

kerberizer commented on 2016-09-16 14:56 (UTC) (edited on 2016-09-16 14:57 (UTC) by kerberizer)

Those who are desperate to use the very latest and untested (!!!) code, may check my PKGBUILDs at But keep in mind that unlike @demizer, I'm afraid I cannot offer any support for them, since they are for my own use, and while I try from time to time to merge changes from here, they might not cover all possible ZFS use cases. The filesystem is something which you usually don't want to take any risks with, but again, if it's just for testing or reference or if you don't really care that much about your data, that might turn out helpful. P.S. It's exactly this critical importance of the filesystem support that requires extensive testing before pushing the changes to the general public. And this is why it's inevitable with carefully maintained packages that there is some lag (the kernel package itself usually stays several weeks in [testing], so we get the newly released kernels almost a month later). @demizer is thus doing what's right and is doing it well.

ackthet commented on 2016-09-16 11:50 (UTC)

Already out of date again! Def switching to the LTS kernel, since the mainline kernel turns around so much.

demizer commented on 2016-09-12 18:28 (UTC)

Hi everyone, I have building for the current kernel 4.7 package. Just doing some testing now. Should go out later today or tomorrow. @NoSuck, @butler360 is correct.

butler360 commented on 2016-09-11 05:30 (UTC)

@NoSuck: 1. It was flagged out of date probably just because it wasn't compatible with the current Arch kernel. 2. This wait was quite a bit more than normal.

bjin commented on 2016-09-10 17:36 (UTC) was released today, which supports linux kernel up to 4.8

jevonearth commented on 2016-09-09 14:57 (UTC)

Hi All, JFYI; zfsonlinux have cut a 0.7.0-rc1 release, so looks like we are getting closer. The zfs-0.7.0 release claims to support up to linux kernel 4.8. Jev

NoSuck commented on 2016-09-07 23:17 (UTC)

I have only used demizer's ZFS repos for a few months. The repos are great, but I have two questions about upgrades: 1. This package is currently flagged as out of date. Is that not incorrect? Upstream <> currently shows as the latest version, which is only compatible up to linux 4.6. Upstream is the one "out of date," not this package. 2. It has been almost two months Arch upgraded linux to 4.7, yet ZoL upstream has yet to release something compatible. Does this happen often? More than a month is a long time to go to hold off performing a system update...

onedr0p commented on 2016-08-22 16:42 (UTC)

@demizer: Looks like everything can be updated now. According to the comments in that thread you linked to, the AUR push bug has since been fixed. Quietly awaiting updates to support the 4.7 kernel.

demizer commented on 2016-08-14 18:30 (UTC) (edited on 2016-08-26 15:22 (UTC) by demizer)

All, The archzfs-linux packages will be out-of-date for an indefinite amount of time. * The archzfs-linux packages will remain out-of-date until upstream ( makes a stable release that supports the 4.7 kernel. * The archzfs-linux-git and archzfs-linux-lts packages are available as alternatives. * shows that linux 4.7 support is added, but a stable release has not yet been made. Thank you.

jerome2016 commented on 2016-08-04 01:22 (UTC) (edited on 2016-08-04 02:23 (UTC) by jerome2016)

i can not install zfs-linux it failed. here is the error: @NoSuck: all the kernel i installed are "original" ones. linux-vfio is the original linux-vfio kernel. I arrived to install and use zfs some month ago, but at each update time there is problem(s). It looks like the package build doesn't care anymore about other kernel than the one the maintainer is using. In my situation, remove all of theses packages and do install zfs-dkms and zfs-utils-dkms one resolve my problem and see zfs working back. hope this experience will help other by use same zfs-dkms packages.

NoSuck commented on 2016-06-29 04:14 (UTC)

@jerome2016, thank you for the warning. So does installation succeed from the original kernel?

jerome2016 commented on 2016-06-18 01:04 (UTC) (edited on 2016-06-18 01:05 (UTC) by jerome2016)

can install it for last linux kernel, but failed from linux-vfio last kernel. THe problem for me is that, when i'm running arch from vfio kernel (the last one, consider my system fresh updated), packages stop because it search in a directory who not exist (the directory where need to have the Module.symver and some other...) because it take the name of the vfio kernel, but after that, it's going to search in the default linux named directory. So, for reproduce the problem, just install a second kernel (vfio or other) and try from there to install zfs... in this situation, you can not install the package and dependencies. Before this update this problem did not exist.

severach commented on 2016-05-16 01:20 (UTC) (edited on 2016-05-16 03:06 (UTC) by severach)

patch: getting attribute system.posix_acl_access of system.posix_acl_access Definitely not ready for 4.5. Neither patch nor setfacl work. All works fine on 4.4.5. Never mind. It works fine with the new AUR packages. The old git packages are broken by being commit locked.

butler360 commented on 2016-05-09 17:48 (UTC)

Thanks, just got the update and my pool is back.

demizer commented on 2016-05-09 17:35 (UTC)

It should be fixed now. I actually forgot to push the updated archzfs repo, and none of my alarms went off. @butler360 zfs-linux is the ZFS package for the default arch linux package. Thanks

butler360 commented on 2016-05-09 17:21 (UTC)

I have to admit, I'm quite confused now. Is this the right package to use if I'm using the archzfs repo and the default Arch kernel? That's my current setup but yeah the kernel update has downed ZFS for me at this time.

skjnldsv commented on 2016-05-09 14:01 (UTC)

@demizer, so what should we do then? I upgraded my whole system, and if I downgrade linux and linux-headers, I got a lot of other modules failing. What Can I do to have zfs back?

demizer commented on 2016-05-08 17:21 (UTC)

le sigh I am going to have to remove the max version. People building straight from the PKGBUILD are going to have to first remove archzfs in order to upgrade it, or use the archzfs repo. I am going to have to document this someone because I get issues about this all the time. Sorry everyone.

predmijat commented on 2016-05-08 14:29 (UTC)

Yeah, it will not work with 4.5.2-1-ARCH. How do we handle this? Back when there demz-repo it wouldn't update unless it was ok to do so, but how can I achieve that with this setup?

jstenback commented on 2016-05-08 07:03 (UTC)

No, it appears to not be compatible with linux-4.5.2-1 :(

lnicola commented on 2016-05-07 21:00 (UTC)

Is this really compatible with linux-4.5.2-1?

techmunk commented on 2016-04-26 22:20 (UTC)

Hi, Can the linux-headers be moved to a make-depends instead of depends? They shouldn't be required on the target system, only for build. Thanks.

demizer commented on 2016-04-25 18:55 (UTC)

@GeorgP, fixed! Thanks for the tip!

GeorgP commented on 2016-04-25 13:16 (UTC)

Hello. Could you add "zfs" to the provides section? There are some packages ("zfs-snap-manager" among others) that require "zfs", which was provided by "zfs-git", but is no longer provided by this package. Or is there a specific reason why this was dropped? Thanks a lot for your work!

demizer commented on 2016-04-25 06:34 (UTC)

Hello, I have a number of breaking changes to report. The archzfs-git group is dead! It has been renamed to "archzfs-linux" See the comments on this page for an explanation as to why. also, the demz-repo-core repository has been moved to I am waiting for AUR volunteers to merge this the archzfs-git packages into the archzfs-linux packages. Sorry for the inconvenience these changes may have caused. I don't anticipate having to do this ever again. These changes will allow me to support more non-standard kernels in the future! Thanks

demizer commented on 2016-04-25 06:29 (UTC)

Hello, To use the archzfs repository, see Please Note: These packages and repos only support x86_64 architecture. Thanks

demizer commented on 2016-04-21 09:27 (UTC) (edited on 2016-04-21 09:30 (UTC) by demizer)

@Ibex So these "git" packages pull from git, but are tied to specific commit. The commits are usually the last tagged release. A few years ago the ZFSonLinux project did not have timely releases that included fixes for the latest kernel releases and the regular "zfs" packages could not be updated. So they were moved to the "zfs-git" packages so I could move the commit to where they would build successfully. Nowe that ZFSonLinux has stable releases before the new kernel comes out, we no longer have this problem. If you could rename the packages to the following it would be wonderful zfs-git -> zfs-linux zfs-utils-git -> zfs-utils-linux spl-git -> spl-linux spl-utils-git -> spl-utils-linux Thanks

demizer commented on 2016-04-21 09:23 (UTC) (edited on 2016-04-21 09:23 (UTC) by demizer)

Forgot to mention, the new PKGBUILDS contain ranged versioning for dependencies to hopefully remove the requirement of first having to remove the zfs packages to update when not using the archzfs repository.

khenderick commented on 2016-04-21 09:22 (UTC)

You have to excuse me @demizer, but I'm a bit confused about which package is moved/renamed to which one. If I was now using this package, do I have to change to another package to have the same content?

demizer commented on 2016-04-21 09:17 (UTC)

I have submitted requests to get these old zfs-git packages merged to new packages I have created in AUR: zfs-git -> zfs-linux zfs-utils-git -> zfs-utils-linux spl-git -> spl-linux spl-utils-git -> spl-utils-linux The new naming scheme includes the name of the kernel the package supports. I get many requests to make the package support multiple kernels from a single PKGBUILD, and this is not possible without greatly cluttering the PKGBUILD. So I have refactored the build tools to make it easier to compile PKGBUILDS for arbitrary kernels easily enough. ALso, these packages will track upstream stable releases. I hae added new packages that build using the latest revision from git.

demizer commented on 2016-04-21 09:17 (UTC)

I have submitted requests to get these old zfs-git packages merged to new packages I have created in AUR: zfs-git -> zfs-linux zfs-utils-git -> zfs-utils-linux spl-git -> spl-linux spl-utils-git -> spl-utils-linux The new naming scheme includes the name of the kernel the package supports. I get many requests to make the package support multiple kernels from a single PKGBUILD, and this is not possible without greatly cluttering the PKGBUILD. So I have refactored the build tools to make it easier to compile PKGBUILDS for arbitrary kernels easily enough. ALso, these packages will track upstream stable releases. I hae added new packages that build using the latest revision from git.

demizer commented on 2016-04-20 06:31 (UTC)

Folks, I merely updated the packages using the old method. The refactor is going to take a little longer. Thanks

demizer commented on 2016-04-19 18:12 (UTC)

Everyone, The latest update will come later tonight as I am in the process of moving the archzfs repo to Thanks.

kerberizer commented on 2016-04-18 20:00 (UTC) (edited on 2016-04-18 20:59 (UTC) by kerberizer)

Using ACLs on ZFS? Be warned: there was a relatively serious regression recently, which has been fixed by this commit... I still cannot confirm that it does fix the problem though. Note: This is the same problem already reported by @ukhippo. Edit: Those affected by the issue might want to follow the discussion here and possibly share their experience as well: For me, the problem seems to persist, but it's also possible that I have missed something important.

demizer commented on 2016-04-18 05:22 (UTC) (edited on 2016-04-18 05:22 (UTC) by demizer)

Hello again! Forgot to mention, in order to make things easier for me and to clean up the PKGBUILDS, I am dropping support for i686 kernels. The ZFSOnLinux maintainers do not recommend using ZFS with 32bit ARCH and supporting i686 complicates the PKGBUILDs: Also, I get about 2 hits per month for i686 files, while x86_64 gets about 400 per month. Sorry for the inconvenience this may cause at least two people that are still using 32bit. Thanks

demizer commented on 2016-04-17 17:23 (UTC) (edited on 2016-04-17 17:24 (UTC) by demizer)

Hello! Heads up everyone, I will be making some breaking changes in the next few days. 1. archzfs-git will track HEAD of A new package group "archzfs" (zfs,zfs-utils,spl,spl-utils) will be added that builds from source for the stock kernel since upstream has been reliably supporting the latest kernel as it is released for more than a year now. 2. The archzfs repo will move to I will be moving the repo to and renaming it to just "archzfs". The same signing key will be used. 3. Better support for multiple kernels. I will modify the PKGBUILDS so that multiple archzfs packages can be installed side by side. For example archzfs and archzfs-lts. Thanks

ukhippo commented on 2016-04-16 19:24 (UTC)

Anyone else having problems with ACLs? Just upgraded to kernel 4.5.0-1 and In my journal I now have a number of "ACL operation on /var/log/journal... Failed: invalid argument" errors. Trying to use getfacl errors with invalid argument for any file on the zfs fs, but works on my boot partition files (which is vfat). My pool does have "xattr=sa" and "acltype=posixacl" set, and mount shows it has been mounted with xattr,posixacl options.

IMcD23 commented on 2016-04-01 00:38 (UTC)

@abrilevskiy, try the zfs-dkms-git AUR instead.

severach commented on 2016-03-16 16:34 (UTC) I made a shell script. It applies uname -r or not, as desired to all 4 PKGBUILD.

irate.overlord commented on 2016-03-16 01:27 (UTC)

@techmunk : what file is this patch applied to?

techmunk commented on 2016-03-10 21:49 (UTC)

I use the patch below along with clean-chroot-manager ( Works a treat, and I don't have to wait for demizer to update for a new kernel version, but I should still get ZFS updates just fine. diff --git a/PKGBUILD b/PKGBUILD index 2848946..20e1114 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -12,21 +12,9 @@ pkgver= pkgrel=1 license=('CDDL') -# Used incase the i686 and x86_64 linux packages get out of sync with the -# PKGREL. This occurred on January 31, 2014 where i686 was versioned at -# 3.12.9-1 and x86_64 was versioned at 3.12.9-2. -_kernel_version_x32="4.4.3-1" -_kernel_version_x32_full="4.4.3-1" -_kernel_version_x64="4.4.3-1" -_kernel_version_x64_full="4.4.3-1" - -if [[ $CARCH == "i686" ]]; then - _kernel_version=${_kernel_version_x32} - _kernel_version_full=${_kernel_version_x32_full} -else - _kernel_version=${_kernel_version_x64} - _kernel_version_full=${_kernel_version_x64_full} -fi +_kernel_version="$(/usr/bin/pacman -Ss ^linux$ | /usr/bin/grep ^core/linux | /usr/bin/cut -d ' ' -f 2)" +_kernel_version_full="$_kernel_version" +pkgver="${pkgver%_*_*}_${_kernel_version//-/_}" pkgdesc="Kernel modules for the Zettabyte File System." depends=("spl-git" "zfs-utils-git" "linux=${_kernel_version}")

demizer commented on 2016-01-05 03:03 (UTC)

@abrilevskiy, I will make the requested changes soon. In the next week I am going to spend time clearing out issues in the archzfs issue tracker that have built up over the last year. However, the changes suggested for _kernel_version cannot be implemented because of the comment before that section of code in the PKGBUILD: I will test building against linux-vfio and linux-ck.

abrilevskiy commented on 2016-01-04 16:56 (UTC) (edited on 2016-01-04 17:05 (UTC) by abrilevskiy)

@demizer, Could you please: 1. use `uname -r` for dynamic kernel version detection? 2. replace kernel variable from: _kernel_version_x32="4.3.3-2" _kernel_version_x32_full="4.3.3-2" _kernel_version_x64="4.3.3-2" _kernel_version_x64_full="4.3.3-2" to something like: _kernel_version_x32="4.3.3-2" _kernel_version_x32_full=${_kernel_version_x32} _kernel_version_x64=${_kernel_version_x32} _kernel_version_x64_full=${_kernel_version_x32} 3. create new variable like kernel_ext that store "-ARCH" by default (kernel_ext="-ARCH") I am using custom kernel (linux-vfio. uname -r: 4.2.5-1-vfio) and each kernel updated I have to: 1. uninstall zfs* packages 2. install kernel 3. download zfs* packages 4. modify PKGBUILD files of zfs* packages 5. compile zfs* packages 5. install zfs* packages Could you please help me to reduce number of steps required to upgrade kernel. Thank you in advance, Andrei.

demizer commented on 2015-10-02 03:58 (UTC)

@justinkb, it's perfectly fine to flag out-of-date to notify me of a problem with the packages. If the reason is for a problem with the package itself (other than a kernel version upgrade), please state so in the comment area. I use google inbox so when the packages are flagged out-of-date it is immediately apparent. Thanks for asking!

justinkb commented on 2015-10-01 19:12 (UTC)

Just a little question to the package maintainer about etiquette. Are we supposed to use the "flag out of date" link to notify you of kernel updates or do you consider this rude/annoying?

severach commented on 2015-09-23 11:01 (UTC)

@Flubbadub Try for Manjaro. Turn enable downgrade option permanently. @demizer # sudo zpool import -d /dev/disk/by-partlabel zfsdata The ZFS modules are not loaded. Try running '/sbin/modprobe zfs' as root to load them. Does zpool not load the modules automatically any more?

graysky commented on 2015-09-20 11:01 (UTC)

@Flub - Manjaro != Arch so just use run a sed onliner in the build dir before you do it: sed 's/-ARCH/-MANJARO/' *

Flubbadub commented on 2015-09-20 10:25 (UTC)

@demizer would you consider a patch to use something like 'uname -r' to get the currently running kernel? This currently fails to build on my manjaro system due to the fact that the kernel is '4.1.6-3-MANJARO' so doesn't end in -ARCH as required by the PKGBUILD. It would save me having to manually change it for each update. Either way thanks for making this available!

demizer commented on 2015-09-19 23:31 (UTC)

@here - FYI there was a zvol corruption bug that affected some users using trim/discard mount options. See and and

ukhippo commented on 2015-09-15 13:31 (UTC)

@lockheed It seems like your hostid has changed. After force importing the pools, try exporting them and rebooting instead of continuing the boot

lockheed commented on 2015-09-14 16:57 (UTC)

I have zfs on root. Since two or three zfs versions back, after the zfs package updates and the system reboots, my pools are no longer mountable: I need to force import them and only then I can boot. But this is not a solution because it is a remote server to which I have rare physical access.

khenderick commented on 2015-09-14 13:57 (UTC)

I did on all my nodes. Seems to be working fine :).

graysky commented on 2015-09-14 13:52 (UTC)

So who has been brave enough to update their zpool? status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(5) for details.

timemaster commented on 2015-09-12 15:04 (UTC)

congratz to demizer for an express delivery like this one. zfs on root : we have now two new feature flag (filesystem_limits/large_blocks). According to my research (no test yet), grub-git support large_blocks with cad5cc0f5d3d3630ccfbe242552958b13f2120d6. I do not know however about filesystem_limits.

demizer commented on 2015-07-29 18:39 (UTC)

@lockheed, unfortunately the zfs modules are tied to the kernel they are compiled for. I only support the official kernel packages. For any other kernel, you will need to compile archzfs to target that kernel.

lockheed commented on 2015-07-29 18:03 (UTC)

Are the packages from demz-repo-core compatible with any other kernel than current "linux" package? Specifically, I mean linux-lts, linux-lts-ck, linux-ck. If not, then will this self-built aur package work with them? Or am I stuck with mainline Arch kernel if I want ZFS?

Rotaerk commented on 2015-07-21 23:28 (UTC)

@demizer, thanks, you were correct. It was a systemd problem, and I was able to fix it based on the suggestions within the thread you linked. I just had to prevent /usr/lib/tmpfiles.d/journal-nocow.conf from setting the nocow flag, which is apparently not supported by some filesystems, including zfs.

demizer commented on 2015-07-20 04:40 (UTC)

@Rotaerk, Seems like a problem with systemd. Users of all different types of filesystems are reporting this. Take a look at

Rotaerk commented on 2015-07-20 03:07 (UTC)

I recently performed a pacman -Syu, which included a kernel upgrade from 4.0.7-2 to 4.1.2-2, and zfs-git was upgraded to (using demz-repo-core). Since then, systemd-tmpfiles-setup.service fails to start, saying that it "cannot set file attribute for '/var/log/journal', value=0x00800000, mask=0x00800000: Operation not supported", along with a couple subdirectories. The error suggests that ACL is not enabled, but the mount output shows "puddle/var on /var type zfs (rw,noatime,xattr,posixacl)". (I have zfs set xattr=sa and acltype=posixacl.) Does anyone know what might be wrong, here?

justinkb commented on 2015-07-17 02:03 (UTC)

@onedr0p, kerberizer I usually just do pacman -Rdd linux, then pacman -Syu, then use my AUR helper program to upgrade the zfs packages (aura -Au). Of course, aura isn't updated to aur4 yet, so gonna have to do the upgrade manually this time

demizer commented on 2015-07-06 21:40 (UTC)

Please see on how to contribute changes to the archzfs project.

kerberizer commented on 2015-06-09 15:58 (UTC)

@onedr0p, that loop is expected. You have to either first remove the old spl/zfs packages, upgrade the kernel and then rebuild the new ones, or, __preferably__, build in a chroot in line with the instructions here... ...or using @graysky's clean-chroot-manager... ...or, as @Ibex suggested, simply use prebuilt packages.

khenderick commented on 2015-06-08 05:52 (UTC)

I see. To be honest, I don't manually build the zfs-git package, but I use demizer's repo with pacman so it can auto-resolve the dependencies. In my /etc/pacman.conf: [demz-repo-core] Server =$repo/$arch

onedr0p commented on 2015-06-08 05:12 (UTC)

Whoops, accidentally hit submit $ yaourt -S zfs-git error: failed to prepare transaction (could not satisfy dependencies) :: spl-git: requires linux=4.0.4-2 :: zfs-git: requires linux=4.0.4-2 ==> Restart building spl-git ? [y/N] ==> -------------------------------- ==> $ uname -a Linux serenity 4.0.4-2-ARCH #1 SMP PREEMPT Fri May 22 03:05:23 UTC 2015 x86_64 GNU/Linux As you can see it's stuck in a failed loop when trying to update one or the other.

onedr0p commented on 2015-06-08 05:08 (UTC)

@Ibex, I understand that, however, I cannot upgrade the linux package and (spl-git or zfs-git) because they complain about each other being a dependancy. # pacman -S Linux error: failed to prepare transaction (could not satisfy dependencies) :: spl-git: requires linux=4.0.4-2 :: zfs-git: requires linux=4.0.4-2 $ yaourt -S zfs-git

khenderick commented on 2015-05-22 16:37 (UTC)

That's normal sometimes. It means the kernel was updated on the main repo's, but that this package wasn't yet updated. The best thing to do is flag this package out-of-date and wait for the package to get updated. Demizer is usually incredibly quick :).

onedr0p commented on 2015-05-22 15:46 (UTC)

Hello, I get an error trying to update. Please help, thanks. $ uname -a Linux serenity 4.0.2-1-ARCH #1 SMP PREEMPT Thu May 7 06:47:54 CEST 2015 x86_64 GNU/Linux # pacman -Syu :: Starting full system upgrade... resolving dependencies... looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: spl-git: requires linux=4.0.2-1 :: zfs-git: requires linux=4.0.2-1

senorsmile commented on 2015-05-13 16:35 (UTC)

Definitely local network issue. Seems to be wifi related... yay, wifi troubleshooting :)

demizer commented on 2015-05-13 16:33 (UTC)

@senorsmile, seems like a local network issue. You could run curl to get a better idea of timings: curl -v -s -w "Total Time: %{time_total}\nName lookup: %{time_namelookup}\nStart transfer: %{time_starttransfer}\n" -o /dev/null Also checkout mtr

senorsmile commented on 2015-05-12 01:07 (UTC)

@demizer still erring out for me: error: failed retrieving file 'demz-repo-core.db' from : Resolving timed out after 10518 milliseconds error: failed to update demz-repo-core (download library error) with my pacman.conf having this at the end(same as I've had for a long time): [demz-repo-core] SigLevel = Never Server =$repo/$arch I AM able to download the db file manually: wget --2015-05-11 17:58:20-- Resolving ( Connecting to (||:80... connected. HTTP request sent, awaiting response... 200 OK Length: 7836 (7.7K) [text/plain] Saving to: ‘demz-repo-core.db’ demz-repo-core.db 100%[=====================================>] 7.65K --.-KB/s in 0.07s 2015-05-11 17:58:36 (107 KB/s) - ‘demz-repo-core.db’ saved [7836/7836] file demz-repo-core.db demz-repo-core.db: XZ compressed data I wget'd the file again with 'time', and saw it take about 15 seconds to download the file. Presumably, pacman is timing out, and since there are no more mirrors it just fails. I increased the connection timeout in pacman.conf and voila, problem solved. This must be a weird wifi issue that's only presenting itself with this custom repo.

billybigrigger commented on 2015-05-10 11:01 (UTC)

zfs-git builds fine if your NOT using llvm/clang

kerberizer commented on 2015-05-08 19:06 (UTC)

Folks, in an effort to more efficiently maintain the packages, the GitHub repo has been moved to a new, dedicated "archzfs" organization. The main code repo is now here: Please report problems and suggest improvements here: If you have patches, please open pull requests here: Once again, your active help and support will be much appreciated. :)

demizer commented on 2015-05-08 16:06 (UTC)

@kerberizer, thanks! This is exactly my sentiments. @billy, I am on the email list for new ZOL versions, but I guess the notifications don't include minor point releases. 0.6.4 ->, so I missed it completely. Also, my automated version checking scripts did not catch it because I had no idea the point releases went to version numbers that low. I don't have time to check the ZOL website every day, but if you would like to join the project and help out by making sure the version is current, from all sources, please step up. Also, to the community as a whole, if the version is out-of-date, just flag the package out-of-date.

kerberizer commented on 2015-05-08 15:48 (UTC)

It's probably worth mentioning that @demizer, like everyone else, is extremely busy in his day job. As a matter of fact, a while ago I pledged to relieve him a little bit by taking over the package maintainership from him, but unfortunately I've been having my own share of problems recently (well, at least you can put part of the blame on me as well). The point however is that the AUR maintainers are volunteers. Therefore, please be kind to them and help them whenever you can. Don't just ask: open an issue at when you encounter a problem, or better yet, if you can, debug the problem yourself, create a patch and open a pull request at @billybigrigger, if you're still facing the build problem, could you please also test with the PKGBUILDs from

billybigrigger commented on 2015-05-08 14:29 (UTC)

20 days?

demizer commented on 2015-05-06 20:42 (UTC)

@billybigrigger Oh Billy, these things take time. Sorry for the late response. Also, I hope your building using systemd-nspawn, or at least clean-chroot-manager. :)

demizer commented on 2015-05-06 20:35 (UTC)

@senorsmile: just checked the host and everything seems to be ok.

senorsmile commented on 2015-05-06 04:19 (UTC)

Using the binary repo no longer works: error: failed retrieving file 'demz-repo-core.db' from : Resolving timed out after 10518 milliseconds

billybigrigger commented on 2015-04-29 23:00 (UTC)

the new version doesn't build here....again like noiseless asked, why aren't we running the newest released zfs-git 0.6.4_r0_gd07a163_4.0.1_1-1 Packages i have installed are the newest spl-git zfs-utils-git and the newest 4.0.1-1 kernel ^ /tmp/zfs-git/src/zfs/module/zfs/../../module/zfs/vdev_disk.c:431:3: note: in expansion of macro 'PANIC' PANIC("dr == NULL, bio->bi_private == NULL\n" ^ /tmp/zfs-git/src/zfs/module/zfs/../../module/zfs/vdev_disk.c: In function '__vdev_disk_physio': /tmp/zfs-git/src/zfs/include/linux/blkdev_compat.h:318:33: error: 'struct bio' has no member named 'bi_sector' #define BIO_BI_SECTOR(bio) (bio)->bi_sector ^ /tmp/zfs-git/src/zfs/module/zfs/../../module/zfs/vdev_disk.c:567:3: note: in expansion of macro 'BIO_BI_SECTOR' BIO_BI_SECTOR(dr->dr_bio[i]) = bio_offset >> 9; ^ /tmp/zfs-git/src/zfs/include/linux/blkdev_compat.h:319:31: error: 'struct bio' has no member named 'bi_size' #define BIO_BI_SIZE(bio) (bio)->bi_size ^ /tmp/zfs-git/src/zfs/module/zfs/../../module/zfs/vdev_disk.c:576:17: note: in expansion of macro 'BIO_BI_SIZE' bio_ptr += BIO_BI_SIZE(dr->dr_bio[i]); ^ /tmp/zfs-git/src/zfs/include/linux/blkdev_compat.h:319:31: error: 'struct bio' has no member named 'bi_size' #define BIO_BI_SIZE(bio) (bio)->bi_size ^ /tmp/zfs-git/src/zfs/module/zfs/../../module/zfs/vdev_disk.c:577:17: note: in expansion of macro 'BIO_BI_SIZE' bio_offset += BIO_BI_SIZE(dr->dr_bio[i]); ^ /tmp/zfs-git/src/zfs/module/zfs/../../module/zfs/vdev_disk.c: At top level: cc1: warning: unrecognized command line option "-Wno-unknown-warning-option" scripts/ recipe for target '/tmp/zfs-git/src/zfs/module/zfs/../../module/zfs/vdev_disk.o' failed make[5]: *** [/tmp/zfs-git/src/zfs/module/zfs/../../module/zfs/vdev_disk.o] Error 1 make[5]: *** Waiting for unfinished jobs.... scripts/ recipe for target '/tmp/zfs-git/src/zfs/module/zfs' failed make[4]: *** [/tmp/zfs-git/src/zfs/module/zfs] Error 2 Makefile:1390: recipe for target '_module_/tmp/zfs-git/src/zfs/module' failed make[3]: *** [_module_/tmp/zfs-git/src/zfs/module] Error 2 make[3]: Leaving directory '/usr/lib/modules/4.0.1-1-ARCH/build' Makefile:16: recipe for target 'modules' failed make[2]: *** [modules] Error 2 make[2]: Leaving directory '/tmp/zfs-git/src/zfs/module' Makefile:684: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/tmp/zfs-git/src/zfs' Makefile:555: recipe for target 'all' failed make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... The build failed.

noiseless commented on 2015-04-29 21:51 (UTC)

What about

demizer commented on 2015-04-19 19:21 (UTC)

Hello everyone, For the last few weeks I have been working on (when I can) automated regression testing for archzfs. If you would like to track progress, or make a comment, the issue is at Please take a look when you have a chance and make a comment! Also, I am planning to rename the repo back to archzfs (from demz-repo-core) in the future. See

lockheed commented on 2015-04-17 19:11 (UTC)

@kerberizer, the problem persists. I created the thread on forum:

Rogge commented on 2015-04-14 18:35 (UTC)

Good to know speed went down for you too. Still faster for me than network can deliver, so no problem here as well.

demizer commented on 2015-04-14 18:22 (UTC)

I have 6 3tb 7200rpm disks in a raid-z2 configuration and I did notice my scrub time went from 4 hours to 5 hours. Since this runs at 3am, it doesn't affect me at all.

Rogge commented on 2015-04-14 18:14 (UTC)

@kerberizer: It's a pool of two raid-z2 with 10x Seagate NAS 4TB 5900rpm drives each, so 20 disks in total.

kerberizer commented on 2015-04-14 18:04 (UTC)

@Rogge, 2GB/s is a very unusual speed for a scrub, I believe. After all, ZFS needs to read *all* data from the vdevs to check it for corruption. What devices do you use and what's the configuration of your pool? @lockheed, do you still experience your problem? If you do, could you please open a thread on the forums?

Rogge commented on 2015-04-11 22:39 (UTC)

Scrubbing speed went down from ~2GB/s to ~640MB/s. Anyone else experiencing this?

lockheed commented on 2015-04-11 08:32 (UTC)

@puithove - thanks for the suggestion. However... basically your reasoning is that I installed and configured ZFS on my Arch system without checking out the Arch wiki page on ZFS, and then, when I encountered this issue, instead of going to the Arch wiki in the first place to solve my problem in one minute, I went out of my way to talk to developers directly. Well… This is not what happened.

Noctem commented on 2015-04-11 03:46 (UTC)

Nevermind my previous comment, apparently the issue was related to USB Attached SCSI. Disabling UAS for the drive in question has allowed it (and ZFS) to work properly on the current kernel.

puithove commented on 2015-04-10 11:37 (UTC)

@lockheed - There's an archwiki article on ZFS: - pay special attention to the Automatic Start section.

puithove commented on 2015-04-10 11:36 (UTC)

Repo is updated with the new packages, and the dependency issue is gone. Thank you!

lockheed commented on 2015-04-10 06:58 (UTC)

Hi demizer. First of all - thank you for your work. I started using ZOL just yesterday so I do not know whether the problem was introduced by 0.6.4, but after reboot my pools remain undetected. Here is detailed discussion form ZOL irc channel. However, people there are not familiar with systemd so perhaps you will be more competent in this respect.

demizer commented on 2015-04-09 23:33 (UTC)

@everyone. I will be updating the packages at 6:30PDT. ZOL 0.6.4 was released today! Not sure why we are getting the dependency issues yet. :(

puithove commented on 2015-04-09 19:52 (UTC)

@demizer - are the packages perhaps not updated in the repo? Still showing a dependency on 3.19.3-1

Noctem commented on 2015-03-30 22:25 (UTC)

On Linux 3.18/3.19/4.0 I get kernel panics when booting or trying to import a zpool, but this works fine with 3.14 (via linux-lts).

demizer commented on 2015-03-28 16:54 (UTC)

@kerberizer, udevadmn looks interesting. I will test that.

kerberizer commented on 2015-03-25 22:27 (UTC)

This commit should also fix some problems with importing pools, particularly when paritions are used for vdevs and not whole devices. For instance, 'zpool import -d /dev/disk/by-id/' might sometimes show part of the vdevs as 'UNAVAIL corrupted data', the reason being that zpool wrongly picks up the whole disk device instead of the partition device where the vdev really resides -- and thus sees, unsurprisingly, a seemingly corrupted vdev. With this patch, the import logic would instead pick up the device "with mo[r]e vdev labels", which hopefully would be the correct one.

kerberizer commented on 2015-03-24 21:38 (UTC)

@demizer, I wonder if that commit isn't connected to the panics that some people experience on boot. Should we also use 'udevadm settle' in the initcpio hook? What do you think?

khenderick commented on 2015-03-24 06:29 (UTC)

In the case that people would be in doubt to update; I just updated 4 machines without any issues.

kerberizer commented on 2015-03-23 21:30 (UTC)

@Ibex: I don't have any problems either. Indeed, I use my own fork of the PKGBUILDs, but I don't think it really differs much. Of course, just like you said, being careful with any update is a wise thing to do anyway.

khenderick commented on 2015-03-23 21:13 (UTC)

@demizer, thanks for the feedback. I have a bunch of test machines and all necessary backups. But if (almost) everybody had these issues, I'd rather wait to update my machine :). But in this case, I'll just give it a go, updating the machines one by one. Anyway, to be clear, I do appreciate all your work every day I'm using zfs on all my machines.

demizer commented on 2015-03-23 20:53 (UTC)

@ibex, I am not getting panics, i.e., "Works on my machine(s)" My current archzfs tasks involve setting up a testing cluster for verifying the archzfs builds, but as you can imagine, this is a *ton* of work, about 40 hours of work to be exact. (I get to put in about 4 hours a week at most). I absolutely _do not_ have the time to manually QA every release, this is the price of bleeding edge that we Arch users must contend with. This will improve in time, but it's going to take time, of which I am currently short on. As I have said before, and will say every chance I get, do backups people!

khenderick commented on 2015-03-23 19:01 (UTC)

Is there actually anybody who doesn't have panics at boot?

kinghajj commented on 2015-03-20 04:13 (UTC)

After updating to the latest version, I get panics on boot.

justinkb commented on 2015-03-09 00:58 (UTC)

Yeah, that was it exactly. Looking at that commit, looks like such a simple fix for so many critical bugs. Kinda funny.

kerberizer commented on 2015-03-06 21:54 (UTC)

@justinkb, thanks for confirming this! Indeed, I think this particular commit to SPL really closed a lot of nasty bugs... If I remember correctly, you were also facing CPU soft lockups in the kernel, with the txg_sync thread getting stuck. I'm glad to say that, like you, I haven't noticed a single one after that commit.

justinkb commented on 2015-03-02 23:57 (UTC)

A while ago I had a recurring problem, which I posted about in this comment box, where I got kernel panics on 3.16 and 3.17. This is now fixed with the latest package and using kernel 3.18.x. Running it rock solid for 2 months now or so. Just wanted to report this.

kerberizer commented on 2015-02-05 01:06 (UTC)

@Perseids, @Ibex, these commits might be relevant to (and, indeed, might fix) your problem with the spl_hostid module parameter...

Perseids commented on 2015-01-29 22:03 (UTC)

@demizer, done: :) It's good to know that it isn't supposed to work. As I've written in the bug report, the root on zfs wiki page mentions it as a valid kernel parameter. @Ibex, thanks. That kernel option is much more comfortable than forcefully importing it in the minimalistic busybox. Have you tried writing a /etc/hostid file as per ? Does it have its own complications? I'll try that next before I permanently add the force option to my boot parameters.

khenderick commented on 2015-01-29 19:23 (UTC)

@Perseids: I had some issues with the hostid in the past as well, and I eventually decided to always do a force import on boot. Might help you (for now) as well. My grub linux line: linux /vmlinuz-linux zfs=zroot rw zfs_force=1

demizer commented on 2015-01-29 19:18 (UTC)

@Perseids Sorry to hear about your issue. Archzfs does not currently support setting a custom hostid. I will look into this issue further. If you don't mind, could you create a ticket here:

Perseids commented on 2015-01-29 07:32 (UTC)

Hi, I just restarted my system after the 3.18.4-1 kernel update and got an import error on my (zfs) root partition, because the hostid did not match the previous one. On the previous kernel I could set it via the spl.spl_hostid kernel parameter, but apparently this no longer works. Maybe something's broken in the mkinitcpio zfs module?

cryptix commented on 2015-01-16 19:08 (UTC)

I did the update, too and my pool is still alive as well :) sorry for the noise ps: i also don't use ecc ram.

butler360 commented on 2015-01-15 21:35 (UTC)

No problems so far for me @cryptix.

kerberizer commented on 2015-01-15 21:32 (UTC)

Folks, some of you might have noticed that GRUB from the core packages doesn't recognize ZFS pools upgraded to support the most recent feature flags. This is because the upstream GRUB lacks the proper support for the hole_birth and embedded_data features. The problem doesn't affect booting, i.e. even systems with unpatched GRUB and fully upgraded pools boot normally, but especially on new installations grub-install fails, not recognizing the ZFS filesystem on the required devices. Tim Chase (@dweeezil on GitHub) has submitted patches upstream, but they have not yet been accepted. I've prepared a PKGBUILD, based on the standard package from the core repo and with Tim's patches [], and if you think it might be helpful, I can create an AUR here as well and/or perhaps @demizer could add the grub-zfs package to his repos. This should be a temporary problem only, but seeing that the activity in the GRUB repo is not too high, it might take some time before the patches that Tim has sent get incorporated upstream.

kerberizer commented on 2015-01-15 20:59 (UTC)

@cryptix, I always follow HEAD in my own PKGBUILDs and haven't faced any problems, but of course that's not an absolute guarantee.

cryptix commented on 2015-01-15 20:38 (UTC)

phew... that's a jump of 40 commits (on zfs, 10 on spl), did you test that zfs build? I see a lot of stuff I'm waiting for in there but it seems a bit risky to jump in there. thanks still! if this works out great i'd be really happy. compare of repos:

demizer commented on 2015-01-15 20:07 (UTC)

Hi everyone. I updated the packages for the 3.18.2-2 kernel. I have also moved the git commit target to HEAD for the spl and zfs packages.

demizer commented on 2015-01-14 18:16 (UTC)

I have 32gb non-ecc ram. I also use raidz-2 with six 3tb disks on with weekly scrubs. Smartd also sends me email if errors are detected on my disks. So far I have had three drives fail since 2012. ZFS has been a joy. This weekend I am going to setup for additional protection.

mpdavis73 commented on 2015-01-13 00:36 (UTC)

Check out episode 31 of BSDNow for a discussion - they had an interview with one of the OpenZFS devs in another episode. Also, read this blog: . My current pool (a 2 disk mirrored VDEV with weekly scrubs) has been on Ubuntu, Arch, FreeBSD, and back to Arch, through 3 HDD replacements, all with the only issue being NFS syntax differences between Linux and FreeBSD. If you are worried about bad RAM, ZFS is the only FS I would trust.

cmtonkinson commented on 2015-01-12 21:13 (UTC)

For what it's worth, it's my understanding that ZFS is no more or less susceptible to damage from RAM bitflips than any other filesystem.

kerberizer commented on 2015-01-12 21:08 (UTC)

@NoSuck, the problem with ECC is that you would want it everywhere your data happens to be at some point of time or another: including all buses that it traverses. I have yet to see such implementations even on servers (not saying they don't exist, just that I've never encountered such in my practice), and it's certainly not something that you could find on any desktop. In other words, ECC memory saves you from yet one more place where your data can go corrupt -- and a very important and vulnerable place, indeed -- but that's it. To say that without ECC memory ZFS is pointless, and vice versa, that with ECC memory and ZFS a system is bulletproof against bit-flips and other data corruption is, mildly speaking, unprofessional.

kerberizer commented on 2015-01-12 21:01 (UTC)

@NoSuck, I do -- and have used it for more than 5 years now on my desktop (first two years on FreeBSD, two years on Ubuntu, and the last year on Arch). It's certainly better to use ECC memory, but it's not a strict requirement either.

NoSuck commented on 2015-01-12 21:00 (UTC)

@senorsmile Thanks. A lot of the documentation seems to stress the importance of ECC to the point of making ZFS seem pointless without it--though I suppose now that such documentation is aimed at large-scale server admins. (Original post, deleted because demizer mentioned using non-ECC RAM in a previous comment.) @demizer Do you (or anyone else) use ZFS with non-ECC RAM? I'd love to use ECC RAM, but my current mobo doesn't support it.

graysky commented on 2015-01-12 20:56 (UTC)

Not a requirement, but recommended. I use zfs without ecc ram.

senorsmile commented on 2015-01-12 20:56 (UTC)

I have over a dozen machines running zfs withOUT ecc ram. For desktops/laptops, it's pretty much the norm. ECC ram helps you, especially with scrubs, but it's certainly not a requirement. Your data is still safer with zfs and nonecc ram than without zfs and nonecc ram.

demizer commented on 2015-01-08 22:24 (UTC)

@butler360 Did not know that existed! Thanks for the tip!

butler360 commented on 2015-01-08 22:12 (UTC)

You don't use mcelog demizer?

demizer commented on 2015-01-08 02:52 (UTC)

@Fardbdose, AFAIK the ZFS packages work best on x86_64 with lots of ECC ram. ZFS is ram intensive, especially when performing scrubs. Last year I had a scrub go bad when one of my ram modules died and I didn't recognize the symptoms (chromium tabs crashing for no reason). The bad memory caused the scrub to produce incorrect checksums which in turn caused the scrubbing process to attempt to recover the file, which failed. At the same time, one of my drives failed leaving me with a very degraded system. Amazingly, I was able to get back to a fully operational pool after replacing the drive and memory. After doing a second scrub process, only one file was unrecoverable, of which I restored from backups.

Mic92 commented on 2015-01-07 09:03 (UTC)

@Farbdose the banana pi does not ship with 3.18.1-1 but an 3.4.90 kernel, this should not be a problem. But I would not recommend to try this on a banana pi because of the lack of RAM.

khenderick commented on 2015-01-06 11:00 (UTC)

You can try, but I don't know whether this makes sense. ZFS needs quite an amount of RAM (4GiB is advised) and is meant for 64 bit processors.

Farbdose commented on 2015-01-05 15:01 (UTC)

Noobquestion: what will happen if simply rewrite the packe file und try to compile it for 3.18.1-1? (Trying to install it on a Bananapi armv7)

demizer commented on 2014-12-15 19:23 (UTC)

Hi everyone. Just want to let you all know I will be unavailable for the next week. I will still update the packages, but updates may be a little delayed. Sorry for the inconvenience!

graysky commented on 2014-11-28 15:41 (UTC)

A major cause of problems upgrading AUR packages is AUR helpers; use demizer's repo or build with makepkg to avoid headaches.

pmedina commented on 2014-11-28 15:38 (UTC)

After manually removing the conflicting packages I was able to preform a system upgrade sudo pacman -R spl-git zfs-git zfs-utils-git When updating the system with packer (AUR), the new version of 'spl-utils-git' got updated and I was later also able to install the packages that I previously removed. $ uname -a Linux forensic 3.17.4-1-ARCH #1 SMP PREEMPT Fri Nov 21 21:14:42 CET 2014 x86_64 GNU/Linux $ pacman -Q spl-git spl-utils-git zfs-git zfs-utils-git spl-git 0.6.3_r44_g46c9367_3.17.4_1-1 spl-utils-git 0.6.3_r44_g46c9367_3.17.4_1-1 zfs-git 0.6.3_r130_g0ec0724_3.17.4_1-1 zfs-utils-git 0.6.3_r130_g0ec0724_3.17.4_1-1

graysky commented on 2014-11-28 14:27 (UTC)

Don't think you're trying to build the latest version...

pmedina commented on 2014-11-28 14:23 (UTC)

This package gives me the following error while upgrading my system. looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: spl-git: requires linux=3.17.3-1 :: zfs-git: requires linux=3.17.3-1 $ uname -a Linux forensic 3.17.3-1-ARCH #1 SMP PREEMPT Fri Nov 14 23:13:48 CET 2014 x86_64 GNU/Linux

graysky commented on 2014-11-07 12:45 (UTC)

Rather than polluting the AUR page for this package, can I ask users to post in the following thread with their observations of zfs-git under linux-3.17.2-1? Are there truly stability or data integrety issues or just a few isolated cases. Again, do not reply here in the AUR. Thanks all!

justinkb commented on 2014-11-06 10:17 (UTC)

Interesting thread. I don't use zvols but that log does look similar. Some strange goings-on... Think I'll roll back to a more stable kernel, see if that fixes things. Hope I don't run into any backward compatibility problems moving from zfs-git to zfs-lts packages...

kerberizer commented on 2014-11-05 10:49 (UTC)

@justinkb, any chance that you're using ZVOLs? You might want to see this...!topic/zfs-discuss/GZcKqUjvuPM

justinkb commented on 2014-11-04 22:44 (UTC)

Relevant lines from kernel log here

demizer commented on 2014-11-04 22:31 (UTC)

@justinkb, I'm am using the git packages and don't see any problems. If you could post the exact error message that would be helpful.

justinkb commented on 2014-11-04 22:18 (UTC)

Getting big lockup problems nearly daily now with this. Kernel log full of mutex timeouts or something like that. Anyone else?

timemaster commented on 2014-10-26 02:32 (UTC)

Since the last update, doing a zpool status show status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, .... .. I am not sure if it's just a new detection that warns me of available features not activated. Indeed, if I inspect (without upgrading) my features flag with "zpool upgrade", I can see many missing from the "man zpool-features" list.

sukosevato commented on 2014-10-24 03:55 (UTC)

I can confirm that ZFS works with 3.17.1-1, I just upgraded from 3.16. Thank you Demizer!

demizer commented on 2014-10-23 21:56 (UTC)

Ok the packages have been updated! Be WARNED! I had to set the commit reference to HEAD for the spl and zfs packages. This makes spl 44 commits past the 0.6.3 release and zfs 130 commits past the 0.6.3 release. Shouldn't be a problem, but just wanted to make sure everyone knows. Jesus

demizer commented on 2014-10-23 21:07 (UTC)

Hi everyone, I moved the archzfs project directory on my workstation and this caused the kernel update cronjob to fail. I will have the packages updated in a hour or less. Guaranteed. If not, ask for a refund! Jesus

demizer commented on 2014-09-18 16:10 (UTC)

I will update these packages at 6pm PST.

demizer commented on 2014-09-09 15:59 (UTC)

Hey everyone! I am currently at work and ssh access to my workstation is not setup (router change). I will update these packages at 7PM PST. Thanks, Jesus A.

demizer commented on 2014-07-09 16:17 (UTC)

@rkelly thanks!

rkelly commented on 2014-07-09 16:10 (UTC)

Thanks demizer for all your efforts. This is a great package.

demizer commented on 2014-07-08 19:26 (UTC)

The 3.15.4 packages are A OKAY.

khenderick commented on 2014-07-06 09:07 (UTC)

Hi, I updated right before the message of Flink at 04/07, so I wonder whether it's safe to reboot or not. Today, I suddenly got: :: Starting full system upgrade... warning: spl-git: local (0.6.3_r0_g31cb538_3.15.3_1-2) is newer than demz-repo-core (0.6.3_r0_g31cb538_3.15.3_1-1) warning: spl-utils-git: local (0.6.3_r0_g31cb538_3.15.3_1-2) is newer than demz-repo-core (0.6.3_r0_g31cb538_3.15.3_1-1) warning: zfs-git: local (0.6.3_r0_g07dabd2_3.15.3_1-2) is newer than demz-repo-core (0.6.3_r0_g07dabd2_3.15.3_1-1) warning: zfs-utils-git: local (0.6.3_r0_g07dabd2_3.15.3_1-2) is newer than demz-repo-core (0.6.3_r0_g07dabd2_3.15.3_1-1) there is nothing to do

Flink commented on 2014-07-04 17:14 (UTC)

@demizer Hey no I don’t think you’re an idiot, you still do a great job with your packages :) I understand you’re in a stressful situation, I hope things will go well!

demizer commented on 2014-07-04 17:10 (UTC)

@Flink, sorry I am an idiot that can't remember to stash changes apparently! I have been preoccupied with finding a new job (i'm currently unemployed) and forgot to stash the changes to the initcpio hooks before updating. I should soon be able to finish the hooks so this won't happen anymore.

Flink commented on 2014-07-04 13:33 (UTC)

Thanks to comment from @moon_bear I managed to boot my system again. But I think there’s a real problem here, like zpool not imported with -R /new_root or something like this maybe. My zpool root mountpoint should be “/” and not “/new_root”.

Flink commented on 2014-07-04 13:20 (UTC)

@demizer OK juste did the update yesterday and I can't boot anymore again :( Same error: filesystem cannot be mounted due to canonicalization error 2. This is pretty much annoying :(

demizer commented on 2014-07-03 17:39 (UTC)

Hello everyone! I flagged the packages out of date and won't be able to update them until after 3PM PST. I have to study for a followup phone interview for Jr. Sys. Admin. Also, I had to destroy my storage pool so that I could set the ashift=12. It shouldn't be that long to reset everything and import the backup. Some advice for anyone that is listening. Use raidz2 at the minimum with six drives. It's also a good idea to use lots of ECC ram. I had a drive fail AND a memory stick fail at the same time! While I was rebuilding the array, another drive started failing! Yikes! Luckily I was able to save my data, but I also had a good backup so I was not worried.

moon_bear commented on 2014-06-30 19:06 (UTC)

For everyone stuck in the busybox: I managed to fix my system trough resetting the mountpoint of my zroot containing my rootfs (zroot) to /new_root: #> zfs set mountpoint=/new_root zroot Then I rebooted and updated zfs. The next boot worked as well. Maybe this helps some of you.

Flink commented on 2014-06-30 08:14 (UTC)

@demizer Ok! Thank you for your quick answer. I’ll try that :)

demizer commented on 2014-06-30 01:15 (UTC)

The packages have been reverted. For those that are stuck in busy box, the only way to fix is to boot from the archiso, install the archzfs packages, chroot into your root and update the archzfs packages. Sorry!

demizer commented on 2014-06-30 00:37 (UTC)

Oh crap! I went on vacation and came back and accidentally committed the hook changes. Well, sorry about that. The only way to fix it now is using the archiso once I have uploaded the fixed packages. Sorry! I have flagged all of the packages out of date. This only affects the git packages.

Flink commented on 2014-06-30 00:20 (UTC)

It seems your initcpio refactoring has broken my setup :( I'm using zfs as my rootfs and I can't boot my system anymore. All I have is the busybox. New_root is empty and I have an error: can't mount due to canonicalization error 2. Please help :/

demizer commented on 2014-06-28 20:25 (UTC)

Hello everyone! My workstation is currently down due to a bad memory module. I am currently running memtest on new memory and hopefully it will be good after a run of 12-24 hours. Unfortunately, I won't be able to update the packages until tomorrow. I also had a drive in the zfs storage pool become corrupt due to the bad memory. So remember, ZFS is only as good as the hardware! I can't really afford and ECC memory setup ATM, so I make sure my backups are up-to-date always.

Zielony commented on 2014-06-28 17:02 (UTC)

Hi, demizer, you are probably aware there has been released 3.15.2-1 already. ;-) Thank you for previous great package work and in advance for this next one. Best regards

justinkb commented on 2014-06-24 01:37 (UTC)

Hm, I didn't notice any bumps to the actual commit after the bump from 0.6.2 base to the specific commit on master (4fd762f) necessitated by the 3.14 kernel release a while back. Unless critical issues arise, I don't think demizer intends to be constantly bumping the commit (now 07dabd2, which is the 0.6.3 tag) in the PKGBUILD...

khenderick commented on 2014-06-21 06:17 (UTC)

@justinkb, as per my understanding (from discussions here in the past), zfs-git follows the master branch, so the zfs-git package is evolving as time passes, following the commits on the repo. All commits on the master branch are considered stable enough and to be as stable as Arch Linux itself, being a rolling release. It was explained that taking the last release and always having to patch the code to work with the evolving kernel is a lot of work and might introduce bugs during the patching, making such packages in fact even less stable than the master branch. If stability is your main concern (running and enterprise storage system or so), you would most likely be running the -lts variants from both kernel and zfs anyway :).

justinkb commented on 2014-06-21 00:01 (UTC)

@kerberizer, As long as you use known "stable" commits (current commit is the 0.6.3 tag effectively, right?) I'm totally on board with keeping these as git packages. Just thought it would lessen the maintenance burden until kernel 3.16 might start messing up compilation again. :-) But your rationale for keeping it on git is fine.

demizer commented on 2014-06-19 05:44 (UTC)

For reference, if anyone needs old packages they are archived here

demizer commented on 2014-06-19 03:25 (UTC)

timemaster and kerberizer are correct on all points. I am going to update the packages for kernel 3.15.1, and begin work on re-factoring the initcpio hooks. The hooks have two issues logged on the archzfs github project page and I am going to work over the next few days to iron them out. There is also another issue with hostid reported by email that I am going to fix. I don't want to bork systems that use zfs as the root fs, so if you have what you consider a unique setup, please post the spec here. I will be setting up testing environments in qemu and recording my steps for the record. Again, if you are using a unique root zfs setup, please take a bit of time and post your setup so I can make tests for it. Once I have the hooks done, I will post a notice here two hours before posting the updated packages to give people a heads up. It will be up to the user to make sure their system does not get stuck in busy box. Hopefully with multiple testing environments setup, this won't be an issue. Thanks!

kerberizer commented on 2014-06-19 02:40 (UTC)

@timemaster, exactly. @justinkb, you may find more details in the comments from 2014-04-13. If your concern is that the SPL/ZFS master branch is not stable enough -- which could, indeed, be a valid concern depending on your specific use case, e.g. in a critically important production system environment -- then you'd probably want to use the linux-lts kernel packages anyway; and @demizer also supports {spl,zfs}{,-utils}-lts packages for those kernels. Not much sense otherwise to use very stable SPL/ZFS code on not-so-stable kernel codebase (i.e. on the non-lts kernels). As a side note, on not particularly critical systems, I have found the frequent updating to be actually more manageable than jumping from one stable version to another. The reason is that the changes are introduced at much smaller steps, so 1) cases, where you face a large number of significant changes and in very different areas, are avoided, and 2) if a bug is encountered, it's source can be easily located across the code, often outright down to the specific commit. For this reason now I tend to rebuild my own ZoL packages on almost every new commit. But again, this may not quite be the best approach for critical production systems. :)

timemaster commented on 2014-06-19 01:31 (UTC)

I don't think resurecting the stable packages will provide any long term good. If I understand correctly, the original issue was that the stable packages were lacking so much behind that they could not build on newer kernel. Maintainer had to patch them to make them wok on newer version and it was finally decided that instead of patching them in a untested way we would be much better and stable to use the git version that work on newer kernel. If I am not mistaken, the packages for zfs-git was always specifying the same git commit even across kernel upgrade. This provided a consistent version that would work for newer kernel version and won't introduce new development bugs. Now that a new stable version exists, let's just point this zfs-git to that specific tag and be done with it. When a future kernel is released and 0.7.3 can still build on it, then let's keep it. When a future kernel is released and the current 0.7.3 version can't build on it, then we'll just bump the package version to use a newer development commit ? kernel incompatibility seems to have a high chance of happening so resurecting the stable packages then to delete them again seems pointless. Your thoughts ?

justinkb commented on 2014-06-19 00:47 (UTC)

Well, this is interesting: * zfsonlinux 0.6.3 has been released * kernel 3.15 has landed in [core] I checked and 0.6.3 supports 3.15 without any patches. Maybe it's time to bring back the non-git spl/spl-utils/zfs/zfs-utils packages.

demizer commented on 2014-06-07 17:50 (UTC)

The scripts have been fixed and the archiso packages have been updated.

demizer commented on 2014-06-07 17:18 (UTC)

Hi, I have not updated the archiso zfs packages hosted at because I forgot. My "reminder" was broken and wasn't sending the email. I am working on it now. Sorry!

khenderick commented on 2014-06-07 05:17 (UTC)

@zidarsk8: That's most likely because ZFS is build against a specific kernel, being the latest available. The Archlinux installer ISO is most of the time an older snapshot and thus most of the time incompatible with this package. For use with the Archlinux install ISO, I advise to use demizer's repositories: as there is one for the main kernel (a pre-build zfs-git) and one (and this is where it's interesting for you) for the current Archlinux installer ISO.

zidarsk8 commented on 2014-06-06 23:21 (UTC)

installing zfs-git with yaourt on the new archlinux-2014.06.01-dual.iso I can't get modprobe zfs to work root@archiso ~ # modprobe zfs 1 root@archiso ~ # depmod -a :( depmod: ERROR: could not open directory /lib/modules/3.14.4-1-ARCH: No such file or directory depmod: FATAL: could not search modules: No such file or directory root@archiso ~ # find / -iname "zfs.ko" /var/abs/local/yaourtbuild/zfs-git/src/zfs/module/zfs/zfs.ko /var/abs/local/yaourtbuild/zfs-git/pkg/zfs-git/usr/lib/modules/3.14.5-1-ARCH/extra/zfs/zfs.ko /usr/lib/modules/3.14.5-1-ARCH/extra/zfs/zfs.ko root@archiso ~ # insmod /usr/lib/modules/3.14.5-1-ARCH/extra/zfs/zfs.ko insmod: ERROR: could not insert module /usr/lib/modules/3.14.5-1-ARCH/extra/zfs/zfs.ko: Unknown symbol in module 1 root@archiso ~ # zpool create zroot /dev/disk/by-id/ata-SAMSUNG_HM641JI_S26XJ9DB746224-part1 Failed to load ZFS module stack. :( Load the module manually by running 'insmod <location>/zfs.ko' as root.

kerberizer commented on 2014-05-16 12:16 (UTC)

@*david_a*: The "easiness" depends on what datasets you have. If /etc and /usr/{bin,lib} are on your root dataset, then solving the problem is simply a matter of "ln -s /usr/lib/systemd/system/ /etc/systemd/system/" and then rebooting. If not, then @ejstacey's advice is probably the best one to take.

ejstacey commented on 2014-05-16 10:32 (UTC)

david_a: Not sure this counts as "easy", but when I need to fix stuff (with zfs root) I mount the latest arch zfs, get the zfs repos installed, install zfs/spl, mount zfs, and chroot to my system. Instructions are here:

*david_a* commented on 2014-05-16 05:00 (UTC)

Sorry - bad question - I've just made the stupid mistake of rebooting after this upgrade, *without* doing systemctl enable first. Is there an easy way for me to fix my mistake?

butler360 commented on 2014-05-15 05:42 (UTC)

Hah, I realized I never disabled zfs.service and it was slowing down my boot time. So if upgrading, should be enabled and zfs.service should be disabled.

nostalgix commented on 2014-05-13 09:10 (UTC)

Is there a chance, that dependencies to linux kernel are updated/solved for upcoming kernel versions?

kerberizer commented on 2014-05-05 21:12 (UTC)

@izmntuk: I should have probably explained it a bit more. Without hooks support, when you upgrade the kernel, you'll have to run dkms {uninstall,build,install} manually, which isn't really much more convenient than rebuilding the packages anyway. There is no (easy) way to make this automatic, unless the install scripts in the kernel package do it, which I don't believe is going to happen (and it wouldn't be right, in any case). With support for hooks in the package manager, on the other hand, as is the case with Debian's Apt for example, the packages that employ dkms-based modules may install hooks that'll handle the rebuilding and reinstallation process for the modules automagically, each time the kernel package is upgraded. I hope someone will correct me here if I'm missing some important point.

kerberizer commented on 2014-05-05 20:58 (UTC)

@izmntuk: The problem with dkms is that pacman currently doesn't support hooks (see: So, right now there isn't much sense in using dkms: it actually makes the things more complex, yet without any real benefit to compensate. Of course, that'll change once pacman does begin to support hooks.

izmntuk commented on 2014-05-05 11:20 (UTC)

Hello, how about add a dkms version of the package(like 'zfs-dkms-git', 'spl-dkms-git' )? I think it'll be very useful for who often switch between different variants of stock kernel.

demizer commented on 2014-05-03 17:28 (UTC)

The old zfs packages have been merged into the zfs-git packages.

kerberizer commented on 2014-05-02 22:10 (UTC)

@demizer, actually, thank you! Your information on the nature of yesterday's problem saved me (and likely others, too) much precious time.

demizer commented on 2014-05-02 18:17 (UTC)

Thanks kerberizer for the heads up!

kerberizer commented on 2014-05-02 14:11 (UTC)

The wait wasn't long, indeed. GCC 4.9 has landed in [core] this morning.

kerberizer commented on 2014-05-01 16:07 (UTC)

@demizer: How about building with gcc & libtool from the testing repo? I did that for my own build and it worked fine. OTOH, of course, if it's a matter of just a few hours or even a day or two of waiting, the risk -- even the lowest one -- might not be worth taking. If anyone's interested, these packages may be downloaded from here, though it's much better of course to build them on one's own. (And it shouldn't be really necessary to say this, but such packages must never be tested directly on production systems!)

justinkb commented on 2014-05-01 15:29 (UTC)

Sounds like a pretty big mistake from arch kernel maintainers, maybe they will just release 3.14.2-2 to fix it

demizer commented on 2014-05-01 13:31 (UTC)

Here is the problem described clearly: from Looks like we'll have to wait.

demizer commented on 2014-05-01 12:31 (UTC)

Ok so it seems 3.14.2-1 was built with GCC 4.9. So we can't build these packages until GCC 4.9 is released to stable, which I'm not sure when that'll happen. Sorry guys and gals!

demizer commented on 2014-05-01 12:01 (UTC)

Well, i'm trying to build the updated packages and it's not happening. It seems CONFIG_CC_STACKPROTECTOR_STRONG is set in the kernel config, but this feature was added for GCC 4.9, which is still in testing. Not sure how to fix this yet... Here is the offending output from config.log when building spl.git:

demizer commented on 2014-04-22 22:27 (UTC)

@PelPix, for the newest kernels, there are often api changes in the kernel that prevent the stable ZFSonLinux releases from building. We attempted to just pull in the patches of the changed API, and this worked for about six months, but in the latest kernel (3.14) the patches required were too many. My testing apparatus is virtually non-existent, so I didn't feel comfortable picking and choosing patches to get the build working again, so we abandoned the original package names for the zfs-git and zfs-lts packages. If you want peace of mind, you should be using lts anyway, but for me the git builds are perfectly fine. I am working on setting up a testing environment now with qemu to re-factor the mkinitcpio hooks. The testing environment will also allow me to run the builds through regression tests in the Arch userland to make sure everything works right.

PelPix commented on 2014-04-22 22:07 (UTC)

How difficult would it be to adapt to mainline versions instead of just stable? Would you describe this as a module that needs little patching to be brought up to mainline, or a lot of patching? I'd be willing to help.

demizer commented on 2014-04-21 13:15 (UTC)

It's working fine for me on multiple systems. What architecture are you using?

skeksis268 commented on 2014-04-21 10:54 (UTC)

Something's wrong here, maybe? Failed to load ZFS module stack. Load the module manually by running 'insmod <location>/zfs.ko' as root.

demizer commented on 2014-04-20 22:37 (UTC)

Ok, the git packages use git now and are tied to a specific commit.

demizer commented on 2014-04-20 18:30 (UTC)

Ok everyone, the zfs-lts packages are in AUR. They are also included in the archzfs repository. The lts packages use the official releases from and do not contain any patches. demizer

butler360 commented on 2014-04-20 08:11 (UTC)

Upgrade went just fine, thanks!

demizer commented on 2014-04-20 04:16 (UTC)

@jalley you should use: systemctl enable We used to maintain a single zfs.service file, but the systemd units included with ZOL are more robust and include support for zfs nfs shares. demizer

jalley commented on 2014-04-20 03:55 (UTC)

What systemd units should be active with the new packages? I appear to have all of these available: zfs-import-cache.service zfs-mount.service zfs.service zfs-import-scan.service zfs-share.service But zfs.service is erroring out "Cannot add dependency job for unit zfs.service, ignoring: Unit zfs.service failed to load: No such file or directory."

graysky commented on 2014-04-19 22:09 (UTC)

Great job, just built the new package set and after enabling zfs.service, everything seems fine under 3.14.1-1.

Panzerino commented on 2014-04-19 09:06 (UTC)

Ok everyone the zfs-git packages are in AUR. If you are using the archzfs repository, you will be prompted to replace the old packages. You will also need to enable the zfs target: systemctl enable The PKGBUILDS don't use the devtools to fetch the git repos, I provided the patches manually as it allows me greater control. Let me know if you all have any problems. I will be starting on the lts packages tomorrow. demizer

justinkb commented on 2014-04-19 01:13 (UTC)

Nice work! Gonna test these right away, fingers crossed :-P

demizer commented on 2014-04-19 00:21 (UTC)

@justinkb, I only have to update the git patches on every minor kernel release 3.13 -> 3.14. Due to kernel API changes. This I don't mind as it is pretty easy. And it allows me to track problems down if they were to come up. The ZOL master branch changes every day.

demizer commented on 2014-04-19 00:18 (UTC)

@justinkb, I will take a look. @lucy, cool, didn't know that. Couldn't find it either. On the next update I will play with that. The devtools (makechrootpkg) still don't properly support the pkgver() function though... I build all of my packages in a clean chroot environment.

demizer commented on 2014-04-19 00:13 (UTC)

Forgot to mention, the original zfs packages will be deleted from aur, so please subscribe to the zfs-git packages. Thanks!

demizer commented on 2014-04-19 00:12 (UTC)

Brand new git packages for arch linux! The lts packages will be next.

demizer commented on 2014-04-19 00:11 (UTC)

Ok everyone the zfs-git packages are in AUR. If you are using the archzfs repository, you will be prompted to replace the old packages. You will also need to enable the zfs target: systemctl enable The PKGBUILDS don't use the devtools to fetch the git repos, I provided the patches manually as it allows me greater control. Let me know if you all have any problems. I will be starting on the lts packages tomorrow. demizer

justinkb commented on 2014-04-19 00:06 (UTC)

There are many AUR packages which work fine just pulling the latest stuff from git and doing some pkgver magic. Try looking at sickbeard-git or xbmc-git packages on AUR. Manually creating these huge patches regularly seems pretty much insane.

commented on 2014-04-18 21:57 (UTC)

The PKGBUILD documentation ( says you can specify a commit in the fragment for git sources like so: source=('project_name::git+http://project_url#commit=4fd762f8ad') It works just fine on all of my git PKGBUILDs.

demizer commented on 2014-04-18 21:17 (UTC)

Just a little update, I have been trying to work with the arch linux packaging tools to allow me to precisely control how the git sources are pulled and it works, but there is no fine grain control beyond pinning branches it seems. That and the devtools scripts don't support the pkgver() function adequately (yet), so I am going to manually create git patches like we have been doing. I have been fighting the tools for the last two days and are basically giving up. I don't have time to work on the upstream tools, so I am going to work around them. Jesus A.

justinkb commented on 2014-04-16 22:24 (UTC)

Pretty excited for those git packages, take your time to ensure all is well :-)

demizer commented on 2014-04-16 21:29 (UTC) Interesting. This package uses git, but it pulls from a specific tag. We will be using the master branch, but not a specific tag. Also, because we are in AUR, I think it would be better to follow the *-git naming scheme to signify that the package uses the git master branch. The grub official package is maintained by the arch devs, so that doesn't matter as much, but people pulling from AUR should know where the sources are coming from. I will also make zfs-lts packages that use the official ZOL release.

graysky commented on 2014-04-16 21:07 (UTC)

Stupid question perhaps but why rebrand the packages with the -git suffix? Grub in the official repo for example is a git snapshot I believe.

demizer commented on 2014-04-16 08:43 (UTC)

The PKGBUILDS I am working on as we speak use hardcoded variables generated by the archzfs build scripts instead of the bash regex clusterfuck that is in the current PKGBUILDS. Bash regex is horrible and hard to read. It makes me wish for python. I am hoping I will have the zfs git packages up by tomorrow. I have had to modify the PKGBUILDS and build scripts heavily.

commented on 2014-04-16 08:38 (UTC)

The current PKGBUILD needs some love in the part relating to 'If LINUX_VERSION does not have a minor version, we need to add "0"', since when I manually edited the LINUX_VERSION_X64 to be "3.14.1-1", the MOD_BASENAME became "" and build failed. Not a big deal for tinkers to manually workaround that issue, of course. (I did not look further into the string manipulation since it is not my field of experience.)

demizer commented on 2014-04-16 03:23 (UTC)

Hi everyone, I am working on supporting zfs-git and zfs-lts packages. It will be a few days before I can get everything uploaded. I am integrating kerberizer's changes and will be looking at the systemd files provided upstream to see if they will work for us. Thanks!

kerberizer commented on 2014-04-16 01:56 (UTC)

As I emphasized when publishing them, those PKGBUILDs are not intended for general use, but rather as a potential point for reference. Sticking to demizer's well-proven, stable and supported packages and PKGBUILDs is the sensible thing to do, unless you want to experiment and then also understand well the risks involved. Now, for those that really want to tinker with my PKGBUILDs, here's a critical thing which I only hinted earlier: because these PKGBUILDs install the systemd unit files provided by ZoL, you need to `systemctl disable zfs.service` and then, after the packages are installed, to `systemctl enable`. The latter is crucial for your datasets to be mounted as expected. There are likely more elegant ways to achieve this, but I haven't yet had the time to give it more thought (any ideas are welcome, of course: probably something connected with the systemd presets). P.S. The reason why it's not (apparently) necessary to change the version for the {spl,zfs}-utils-git PKGBUILDs is because they don't have a dependency on the Linux kernel. The real problem here, however, is that each of the PKGBUILDs in their own chain of dependencies (spl-utils -> spl-modules -> zfs-utils -> zfs-modules) doesn't check the version of the package it depends upon. That's exactly one of the other problems with my PKGBUILDs that I talked about (and the reason are the Git type versions, for which there's likely an easy and elegant solution, but at least I need some time to think about it; again, ideas are very welcome).

timemaster commented on 2014-04-16 00:09 (UTC)

Well... it seems I had an old version in /usr/local and it conflicted with the newer version. Seems to work with kerberizer packages and seems like my disk is 96% used :) fragmentation? who cares for a system mainly used for save once/don't read often.

timemaster commented on 2014-04-15 23:54 (UTC)

I tried to remove the zfs packages from demizer repo and build the git packages using kerberizer. Had to modify the version for the zfs-modules-git and spl-modules-git but not on the two others ? After the installation, zfs import was crashing with an error. I will be coming back to demizer version but they require a different version of the kernel...? I am lazy and this will be working back in a few days so I will wait I guess.

puithove commented on 2014-04-14 11:54 (UTC)

@demizer - switching to the -git packages sounds like a totally sane approach. Take it easy and hope you have a speedy recovery. Thanks for all you do here. My laziness likes the convenience of the repo so that I don't pull any kernel updates until I know the zfs stuff is building for it - especially useful if running with a zfs root.

demizer commented on 2014-04-14 01:09 (UTC)

@WhiteKnight, I will continue to update demz-repo-core, only the packages will be based on the zfs-git packages that we will begin to support. @kerberizer, The upstream git master branch is stable. Before patches are merged into the master branch they are tested. In the years I have been using ZOL, I have never had a problem using patches from the master branch. As far as the zfs, zfs-utils, spl, and spl-utils packages, I think they should be deleted too. We would have to record somewhere our reasoning for no longer updating these packages or following the release model. So for the record, on the next kernel bump, I will create the following packages (using kerberizer's existing work posted below) that use the "replaces" PKGBUILD variable: zfs-git zfs-utils-git spl-git spl-utils-git I will update these packages on every kernel bump so the changes propagate. The demz-repo-core packages will be based on these packages.

kerberizer commented on 2014-04-13 22:53 (UTC)

Sorry for spamming the comments, but it just came to me that if we migrate towards -git packages, the yaourt users will need to use the --devel option. Not sure if that's relevant for the other AUR helpers, and I wonder if it should be considered a problem or not.

kerberizer commented on 2014-04-13 22:36 (UTC)

I thought it might be still helpful to share the PKGBUILDs I've been working on, as a line or two of them may come in handy (I've also tried to optimize slightly a few things)... Mind you, they are NOT to be used blindly! At the very least, they need manually switching to the new systemd provided by ZoL, but that's not the only thing that needs additional tinkering. @WhiteKnight: You are welcome! ;) As for the LTS packages, they are necessary anyway, and if I find some time next week, I might give them a try, as it's certainly better for @demizer to concentrate on his recovery right now.

WhiteKnight commented on 2014-04-13 14:40 (UTC)

Thanks for the detailed explanation, @kerberizer. With your words in mind, just forget my asking for LTS packages. :)

kerberizer commented on 2014-04-13 14:24 (UTC)

@WhiteKnight: As @demizer said, the master branch of the ZoL code is considered stable -- or at least as "stable" as Arch Linux itself is, being a rolling release distribution. This means that moving to -git packages shouldn't lower the stability of a non-LTS Arch Linux system below its inherent level. To put it another way, the packages based on release tags (e.g. 0.6.2) cannot make a non-LTS system any more stable that it inherently is, and indeed, due to the need for specific patching with small user base for testing, they might even _lower_ that stability. This means that all people who have so far been happy with the regular packages shouldn't be any less happy with the -git ones. And those who need more stability than that should consider the LTS kernels anyway -- or, even better, a non rolling-release distribution (for example, I personally tend to use older, well-proven versions of FreeBSD for the most critical systems I manage, albeit it's somewhat arguable if that's not simply laziness on my side ;))). BTW, there's one more reason in my view why -git packages are convenient for non-critical systems. They allow for a gradual upgrade process, where new or changed functionality is introduced in small -- and more manageable -- steps, as opposed to the "huge leaps" between two releases, where one has to cope with a multitude of new things at once -- both as pure number and as variation. That's another reason why I prefer either regularly upgraded systems (like the rolling-release distros) or systems that are never upgraded, save for the most critical patches -- and even then only the ones which are relevant to the specific use. As for the "automatic" transition, if I understand the process correctly, it's just a matter of adding one more variable ("replaces") to the PKGBUILD -- nothing fancy here really and no waste of resources either. And it shouldn't involve any manual work. It's also probably worth mentioning that the transition to -git packages is really more an "organizational" or "administrative" issue at the moment -- the packages are in fact _already_ based on the master ZoL branch (and there's no reasonably simple way to avoid this for the 3.14 kernel as @demizer explained earlier).

WhiteKnight commented on 2014-04-13 12:38 (UTC)

What @kerberizer says makes sense from my point of view. Providing LTS packages for the arch LTS kernel sounds like a good compromise, even thou I'd prefer to have the default (non LTS) kernel on my server. But I'm well aware that I cannot demand anything. :) By the way: Please don't get me wrong; I don't have any problems if the transition would require manual work. And I guess, most users here see it like that, too. So I'd suggest to not waste time and energy for some kind of atuomatic transition.

kerberizer commented on 2014-04-13 10:10 (UTC)

@demizer: I fully support what you've written. It's not only a potentially tedious work patching the ZoL releases for each new kernel, but it's also probably more risky in terms of stability, since this is not something that is necessarily widely tested outside of the Arch Linux community. Thus, somewhat paradoxically, the "stable" packages might actually be less stable than the -git ones. So, I'd also vote for moving towards -git (and supporting the -lts as well for those who really need stability). Concerning the zfs, zfs-utils, spl and spl-utils packages, it might indeed be better to delete them in favour of the -git ones. My reasoning is based mainly on version problems. If we are to follow Git master, it becomes quite important on which exactly snapshot of the source tree the package is based, especially during times of high commit activity, when the timestamp of the package can't be used as a more or less reliable indicator. Simply put, the -git type versioning (e.g. 0.6.2.r253.g888f714_3.14-1) is very desirable anyway. I don't have much experience with this, but I suppose we could also use the "replaces" array in the PKGBUILD to have the transition done smoothly for the people who use the repos (that's partially in reply to the question by @WhiteKnight).

WhiteKnight commented on 2014-04-13 09:42 (UTC)

What effect would that have on your repo? ([demz-repo-core])

thunderforce commented on 2014-04-13 02:31 (UTC)

I would vote for using -git packages since that would match the Arch way better. since I'm abroad (in Brazil, home server is in Los Angeles) and / is mounted read only, I will play safe for a while and not try anything that requires a reboot..... but back to topic, I would be willing to help prepare a testing environment (vagrant and virtualbox come to mind) to aid testing releases, if that would be helpful and easy to work with. Thanks for the great work!

demizer commented on 2014-04-13 01:04 (UTC)

@kerberizer, yes I have been thinking about this as well. These packages are now essentially similar to zfs-linux-git. I'm not sure if that is right. Since takes a long time between releases, the release based model would not work for Arch Linux since Arch uses the newest kernel ASAP. These packages would only be viable on every new ZOL release, after that kernel updates would require the use of patches to fix kernel API changes, which is the method we have deployed until now. The API changes for 3.14 were fixed in the ZOL master branch, but was built upon all of the previous changes over an 8 month period, so there was no easy simple patch to pull in as was done before. So technically, the best solution would be to just build ZFS from git everytime. This is what the gentoo guys do. I'm not sure if we should delete the zfs, zfs-utils, spl, spl-utils packages in AUR and just use zfs-git, zfs-utils-git, spl-git, and spl-utils-git? Since the release based zfs packages won't work on Arch. Let me know what you all think guys! Thanks, Jesus A.

kerberizer commented on 2014-04-12 16:24 (UTC)

@demizer: Are you going to keep following master (i.e. not stick to the "release" tags, like 0.6.3) in the future? I remember you doing that in the past, but then at some point you switched to the 0.6.2 tag. I'm asking because I'm almost ready with a set of {spl,zfs}-{utils,modules}-git packages for those who want to follow the Git master, but this now seems redundant.

demizer commented on 2014-04-12 16:15 (UTC)

So this latest update does use a patch to make the code current to git master. As Arch is bleeding edge, so must be these packages, it is the only way. The master branch of the ZOL git repo is stable. Users that don't feel comfortable using bleeding edge, should use the linux-lts packages. I'm sorry about the rw kernel parameter change, I should have vetted it more before adding it to the repo, and definitely should not have changed it right before going out on surgery. Once I feel physically comfortable I will work on linux-lts packages as well as closing some of the issues in the archzfs repo.

kerberizer commented on 2014-04-12 14:35 (UTC)

@puithove: Hm, do you have the "rw" kernel parameter set in your bootloader? This hasn't been required until very recently (it is also due to a change in the ZFS initcpio hook, not in the ZoL code itself; see

puithove commented on 2014-04-12 14:25 (UTC)

To get by for now, it looks like it'll work if I go with mountpoint=legacy on my root filesystem dataset, and put it in fstab. Not the way it should have to be but... Everything else seems to be working as far as I can see.

puithove commented on 2014-04-12 14:08 (UTC)

I decided to try this update. Unfortunately I'm running into an issue. I have my root filesystem on zfs. Now after the update, everything still mounts and I'm able to get logged in, but my root fs is mounted read-only. If I check properties, I see "readonly=on" and the source is "temporary". If I do zfs inherit readonly or zfs set readonly=off it'll remount as rw, but by that point of course my boot is screwed and most stuff isn't running. Looks like temporary properties are something new to zfsonlinux according to this that I found: - I wonder if something new needs to be added to the boot sequence to get the root remounted as rw.

justinkb commented on 2014-04-12 02:19 (UTC)

does this incorporate everything from 0.6.2 to git HEAD? think I'll wait for 0.6.3 in that case, unless we get a minimal backport in another package or something.

graysky commented on 2014-04-12 00:21 (UTC)

demizer has unfucked the packages; repo and AUR updated.

chungy commented on 2014-04-11 18:08 (UTC)

@demizer: this was passed around on IRC. I haven't tested it at all, but it's a rather more lightweight patch than 2.3MB

kerberizer commented on 2014-04-11 09:38 (UTC)

@demizer: Glad to see you back here! :) @all: Just in case anyone is interested in such experience, I've built for myself packages for linux-3.14 based on Git master for SPL and ZFS and the pull request #2226 for ZFS (which is now merged in master). Everything builds cleanly as expected and I haven't noticed any problems after the upgrade (I have about 500 GB of data on an encrypted mirrored pool and am going to test on another server today). This obviously doesn't mean that everyone's data would be safe, but at least it might bring a little reassurance to those who might want to take the same path. Overall, though, I agree that waiting is the safest solution.

graysky commented on 2014-04-11 09:25 (UTC)

My toe is to wait. We can just keep using 3.13.x until a safe patch is assembled. I would HATE to lose any data just so I can be running the latest kernel version.

demizer commented on 2014-04-11 09:04 (UTC)

Well, I took a first stab at getting the packages to work with 3.14 and it's not looking like it's going to be easy. There are some kernel API changes in 3.14 that require the pulling in of POSIX ACL patches from the ZOL repo ( and This patchset deppends on many other patchsets and I don't feel comfortable picking and choosing. So I attempted to create a large patchset with everything from git master on the ZFS repo and the patch is 2.3mb. Tar'd it is about 450k, which is an upload size that is frowned upon on AUR. I'm not even sure if AUR would accept a file that big. Not sure what to do now. ZFS 0.6.3 is supposed to be released soon, so we could just wait I guess.

justinkb commented on 2014-04-10 19:30 (UTC)

It's cool, this is a package patches for which you need to take your time to get right ;-) I don't want to lose 7TB of data :-D

graysky commented on 2014-04-10 18:17 (UTC)

Sorry gang, some work is needed to update the package set for 3.14. I need to wait for demizer to do it.

graysky commented on 2014-04-08 19:18 (UTC)

@itsjapie - See my comment 4 down.

itsjapie commented on 2014-04-08 17:23 (UTC)

My system didn't boot until I added 'rw' to my APPEND line in Syslinux. Why wasn't this nessecary before? Dit the initcpio hook for ZFS change ?

nOon commented on 2014-04-03 21:02 (UTC)

ok sorry for that i just find that i was missing the rw parameter on my grub.cfg ... now everything works fine

nOon commented on 2014-04-03 20:35 (UTC)

ok thanks so it seems that this issue comes from another package or an error happen since my last upgrade.

graysky commented on 2014-04-03 13:44 (UTC)

@noon - I have several systems running zfs and do not experience this problem. There hasn't been a change to zfs.service as far as I know either. The only change that was recently made by demizer is here:

nOon commented on 2014-04-03 13:13 (UTC)

upgrade of my system to kernel 3.13.8-1 make my system crash. The / is now mounted on read only.. For the moment i have disable gdm and everytime i remount the / in rw and restart all services. But it's quite troublesome If someone have the same issue could be great. I also saw that the new zfs.service didn't export the pool anymore. So the service crash everytime (but the system works well), is it normal?

thunderforce commented on 2014-03-22 12:40 (UTC)

Never mind.... forgot to use "demz-repo-archiso" in pacman.conf since I'm installing from USB

thunderforce commented on 2014-03-22 12:34 (UTC)

Hello, I'm getting this when I try to install, booting from USB zpool create zroot <DISK_ID> <DISK_ID> Failed to load ZFS module stack. Load the module manually by running 'insmod <location>/zfs.ko' as root. root@archiso ~ # insmod /usr/lib/modules/3.13.6-1-ARCH/extra/zfs/zfs.ko insmod: ERROR: could not insert module /usr/lib/modules/3.13.6-1-ARCH/extra/zfs/zfs.ko: Unknown symbol in module

graysky commented on 2014-03-05 00:11 (UTC)

You will need to build the four packages in a clean chroot or use demizer's repo.

zidarsk8 commented on 2014-03-04 23:44 (UTC)

archiso# yaourt -S --deps zfs resolving dependencies... warning: cannot resolve "linux=3.12.9-2", a dependency of "spl" warning: cannot resolve "spl=0.6.2_3.12.9-2", a dependency of "zfs" warning: cannot resolve "linux=3.12.9-2", a dependency of "spl" warning: cannot resolve "spl", a dependency of "zfs-utils" warning: cannot resolve "zfs-utils", a dependency of "zfs" warning: cannot resolve "linux=3.12.9-2", a dependency of "zfs" :: The following package cannot be upgraded due to unresolvable dependencies: zfs

demizer commented on 2014-02-23 17:24 (UTC)

Forgot to mention, please use "pacman -Syy" when updating your sync databases!

demizer commented on 2014-02-23 17:21 (UTC)

Ok, sorry about that everyone. It should be fixed now!

demizer commented on 2014-02-23 17:08 (UTC)

FYI, there is a problem with the archzfs repo, I am working to see what is going on. Sorry!

demizer commented on 2014-02-23 04:23 (UTC)

Ok, after a long fought battle with apache, graysky's built packages are up! You will need to locally sign his key if you are using the archzfs repo: # pacman-key -r 5EE46C4C # pacman-key --lsign-key 5EE46C4C Thank!

butler360 commented on 2014-02-09 21:19 (UTC)

Thanks to you both for this, and good luck with the surgery and recovery!

graysky commented on 2014-02-09 21:19 (UTC)

Just FYI. I am not a TU :p

demizer commented on 2014-02-09 21:11 (UTC)

Okay, good news everyone. graysky is going to push the updated packages to the demz-repo-core repo as well as updating the PKGBUILDS. So this means no one will have to update the url location of the archzfs package repos while i'm away. When the 3.13 kernel is released to core, graysky will take that opportunity to make trial run on his end for managing the ZFS packages. This includes signing the packages and database with his GPG key. Since he is a TU, there should be further intervention by users of the archzfs repository. @lucky, I know I promised to take a look at adding support for lts kernels, and I haven't... sorry about that. I will make sure I tackle it once I recover from surgery. And thank you for the kind words!

Lucky commented on 2014-02-09 02:07 (UTC)

@demizer Good luck with the surgery and a fast convalesce. We will see you in a few months back. :D @graysky & demizer Would it be possible also create a zfs package for -lts kernels? Because on "server" side i think most of us will go with a LTS kernel.

demizer commented on 2014-02-08 18:45 (UTC)

A quick update. I am emailing with graysky on him taking over for a few months while I recover. Thanks for all the support everyone!

graysky commented on 2014-02-08 12:22 (UTC)

I might have some time to take over the 4 packages while you convalesce. Email me so we can do the handoff if you wish.

demizer commented on 2014-02-08 06:01 (UTC)

Hello everyone. Unfortunately, I will be having major heart surgery in the next month that will make it difficult for me to keep up with the ZFS packages on AUR. Therefore, I am going to have to drop my maintainership of these packages. For those that may be interested in adopting these packages, here are some details: 1. ZOL is released every six months or so. Sometimes a new kernel version includes API changes that break ZOL builds. Luckily, patches are usually available in the ZOL github repo. 2. The upstream ZOL master branch is stable. ZOL has been very stable for me and has not once refused to build (except for API changes, which happen every few months). 3. There has been very little email traffic to me regarding ZFS on Arch in the last year . 4. The archzfs repository on github can be transferred to the new maintainer. 5. Build scripts exist for automatically building the packages, adding the built packages to a repo, pushing the package sources to AUR, and scraping webpages for version numbers (with email reporting). These scripts are adapted to my workflow, but they can be adapted easily to a new maintainer's workflow. 6. The repo will be taken down as I won't be able to keep up with it. If you are interested, just send me a note to Sorry for having to bow out everyone. demizer

demizer commented on 2014-01-31 22:54 (UTC)

@graysky, the linux version is hardcoded in zfs/PKGBUILD and spl/PKGBUILD. So just updating the x86_64 packages won't work. :( Anyways, I have added the kludge. This breaks the linux version dependency output in AUR as you can see above "linux=" is missing the version number. This is something I wanted to avoid, but it looks like that won't be happening until AUR gets fixed. I also cleaned up the version replacement functions in my build scripts. Took about three hours, but I'm happy with everything. If anyone has any problems, leave your comments here. Thanks!

graysky commented on 2014-01-31 20:41 (UTC)

@demizer - Or just manually rebuild one of the two since this is a pretty rare occurrence.

demizer commented on 2014-01-31 20:39 (UTC)

So it seems that the i686 and x86_64 linux packages do get out of sync with each other. It hasn't happened in the last year that I have been maintaining these packages, but I guess it does happen. So now I have to put some kludge in the build scripts for handling this occurrence as my request to keep the linux packages in sync was closed as won't fix. The packages will be updated in a few hours. Sorry!

demizer commented on 2014-01-31 14:31 (UTC)

I tried updating the packages, but linux i686 is at 3.12.9-1 and linux x86_64 is at 3.12.9-2. I have filed a bug report here: I will update once the out of sync versions of linux are fixed.

graysky commented on 2014-01-21 10:08 (UTC)

Cool, glad others find value in ccm64 and ccm32!

demizer commented on 2014-01-21 07:04 (UTC)

Sorry it took more than a few hours to update. I had to refactor my build scripts. Devtools changed the way arch-nspawn worked, so instead I refactored the build scripts to use clean-chroot-manager. For anyone that is curious, you can see the build script here:

demizer commented on 2014-01-14 01:22 (UTC)

Well it seems the pkgnames in the PKGBUILDS had incorrect syntax. I was using parenthesis in the pkgname when it wasn't necessary. All fixed now, enjoy!

demizer commented on 2014-01-14 01:09 (UTC)

For some reason AUR is rejecting the package updates saying they are split packages, which they are not. Not sure why. I am working on a solution.

wolfdogg commented on 2014-01-11 22:00 (UTC)

error: failed retrieving file 'chroot_local.db' from disk : Couldn't open file /var/repo/chroot_local.db

wolfdogg commented on 2014-01-11 21:48 (UTC)

# pacman -S archzfs :: There are 4 members in group archzfs: :: Repository demz-repo-core 1) spl 2) spl-utils 3) zfs 4) zfs-utils Enter a selection (default=all): resolving dependencies... warning: cannot resolve "linux=3.12.6-1", a dependency of "spl" warning: cannot resolve "linux=3.12.6-1", a dependency of "spl" warning: cannot resolve "spl=0.6.2_3.12.6-1", a dependency of "zfs" warning: cannot resolve "linux=3.12.6-1", a dependency of "spl" warning: cannot resolve "spl", a dependency of "zfs-utils" warning: cannot resolve "zfs-utils", a dependency of "zfs" warning: cannot resolve "linux=3.12.6-1", a dependency of "zfs" warning: cannot resolve "linux=3.12.6-1", a dependency of "spl" warning: cannot resolve "spl", a dependency of "zfs-utils" :: The following packages cannot be upgraded due to unresolvable dependencies: spl zfs zfs-utils :: Do you want to skip the above packages for this upgrade? [y/N]

cabrey commented on 2014-01-05 21:23 (UTC)

@graysky, changing the dependencies to linux-ck doesn't seem to help. I can compile and install all the relevant packages manually (that is, without an AUR helper), but `modprobe zfs` leads to "modprobe: FATAL: Module zfs not found." I can find the ko inside /usr/lib/modules/3.12.6-1-ck/extra/zfs/zfs.ko however... I'll give your script a try, thanks.

graysky commented on 2014-01-03 19:59 (UTC)

You can just modify the PKGBUILDs of the zfs packages to require "linux-ck=3.xx.y" and build them on that machine. I wrote a little script that allows me to build the packages using clean-chroot-manager (available in the AUR). Note that you still will need to modify the PKGBUILDs for your alternative kernel. Here is my build script if you are interested. Note that the last line sends the built packages to my ZFS server where it is setup to read a custom repo from there. This allows for transparent upgrades. You can comment it out if you don't do something similar. #!/bin/bash # # ZFS Builder by graysky # # define the temp space for building here WORK=/scratch # create this dir and chown it to your user # this is the local repo which will store your zfs packages REPO=/scratch/null # Add the following entry to /etc/pacman.conf for the local repo #[chroot_local] #SigLevel = Optional TrustAll #Server = file:///path/to/localrepo/defined/above for i in rsync cower ccm; do command -v $i >/dev/null 2>&1 || { echo "I require $i but it's not installed. Aborting." >&2 exit 1; } done [[ -f ~/.config/clean-chroot-manager.conf ]] && . ~/.config/clean-chroot-manager.conf || exit 1 [[ ! -d "$REPO" ]] && mkdir $REPO [[ ! -d "$WORK" ]] && echo "Make a work directory: $WORK" && exit 1 cd "$WORK" for i in spl-utils spl zfs-utils zfs; do [[ -d $i ]] && rm -rf $i cower -d $i done rsync -auvxP $CHROOTPATH64/root/repo/ "$REPO" rsync -auvxP --delete-after -e 'ssh -c arcfour128' "$REPO/" facade@mars:/var/repo/

demizer commented on 2014-01-03 18:57 (UTC)

@cabrey, I would be willing to include any changes made to the PKGBUILD that support these kernels. I'm sorry, but I just don't have the time to do it myself. I know graysky is the maintainer of the linux-ck kernels and I believe I once saw a script he wrote for building the archzfs packages for the linux-ck kernels. I can't seem to find it now though.

cabrey commented on 2014-01-03 15:29 (UTC)

Any chance you can modify the PKGBUILD to support alternative kernels (such as linux-ck-*)?

demizer commented on 2013-12-14 06:00 (UTC)

The current kernel version is 3.12.4, but 3.12.5 is in testing so I want to wait until that version comes out so I don't have to update back to back. Should be in the next day or two.

demizer commented on 2013-11-15 05:16 (UTC)

Okay everyone the packages are updated. Sorry it took so long, had to pull in some patches from upstream to make it work with 3.12.

thunderforce commented on 2013-10-16 21:51 (UTC)

@demizer Thanks for being really responsive even though you have a life :) Great work!

Achterin commented on 2013-10-15 10:02 (UTC)

@demizer thanks for your answer. don't stress yourself and take your time.

fukawi2 commented on 2013-10-15 07:10 (UTC)

==> ERROR: install file (zfs.install) does not exist.

demizer commented on 2013-10-15 06:47 (UTC)

I plan on supporting the lts kernels in the future, the only problem is that I am knee deep in chemistry at school. So it will take some time to implement it in my build scripts.

thunderforce commented on 2013-10-14 22:25 (UTC)

another kernel update 3.11.5-1 !!

Achterin commented on 2013-10-14 10:08 (UTC)

@demizer is it possible to provide the zfs modules for arch lts-kernel, maybe also in your repository? anyway, thanks for your work.

PelPix commented on 2013-10-05 22:46 (UTC)

It's that time again! Kernel package update!

bussiere commented on 2013-10-02 01:27 (UTC)

I have the failed to load module and cannot load it with insmod. If you could fix it, it would like it a lot i have a problem with my computer and a snapshot to mount relatively quickly. Thanks for the work btw

thunderforce commented on 2013-09-29 08:53 (UTC)

@demizer All is good, now! Thanks a bunch!

demizer commented on 2013-09-28 17:09 (UTC)

Sorry, I am working on updating the packages now. It has been a crazy week due to school. Sorry all!

thunderforce commented on 2013-09-28 09:35 (UTC)

Can't seem to be able to update at the moment.... hints? pacman -Su :: Starting full system upgrade... resolving dependencies... warning: cannot resolve "linux=3.11.1-2", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.2_3.11.1-2", a dependency of "spl" warning: cannot resolve "linux=3.11.1-2", a dependency of "spl" warning: cannot resolve "linux=3.11.1-2", a dependency of "spl-utils" warning: cannot resolve "linux=3.11.1-2", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.2_3.11.1-2", a dependency of "spl" warning: cannot resolve "linux=3.11.1-2", a dependency of "spl" warning: cannot resolve "spl=0.6.2_3.11.1-2", a dependency of "zfs" warning: cannot resolve "linux=3.11.1-2", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.2_3.11.1-2", a dependency of "spl" warning: cannot resolve "linux=3.11.1-2", a dependency of "spl" warning: cannot resolve "spl=0.6.2_3.11.1-2", a dependency of "zfs-utils" warning: cannot resolve "linux=3.11.1-2", a dependency of "zfs-utils" warning: cannot resolve "zfs-utils=0.6.2_3.11.1-2", a dependency of "zfs" warning: cannot resolve "linux=3.11.1-2", a dependency of "zfs" warning: cannot resolve "linux=3.11.1-2", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.2_3.11.1-2", a dependency of "spl" warning: cannot resolve "linux=3.11.1-2", a dependency of "spl" warning: cannot resolve "spl=0.6.2_3.11.1-2", a dependency of "zfs-utils" warning: cannot resolve "linux=3.11.1-2", a dependency of "zfs-utils" :: The following packages cannot be upgraded due to unresolvable dependencies: spl spl-utils zfs zfs-utils :: Do you want to skip the above packages for this upgrade? [y/N] n

commented on 2013-09-17 23:16 (UTC)

@demizer Thanks for maintaining the package and the very quick update. You make it easy for everyone. It took me just 2 hours to understand and install ZFS on a 6x4TB 4+2 RAIDZ-2, while it took 2 days (and still going) to make Samba4 run properly on that server (joined as a member to an Active Directory domain). The OpenZFS is great news. At the very least it formalizes the current upstream code coordination between the Illumos, FreeBSD and ZoL platforms. Oracle Solaris will be the 'orphan'.

PelPix commented on 2013-09-17 22:06 (UTC)

So will this package transition to Open-ZFS or will there be another package for that?

demizer commented on 2013-09-17 17:51 (UTC)

Hello everyone, there has been an exciting announcement just moments ago regarding ZFS. directly: It appears that the ZFS filesystem has been forked and further development will be done on this new branch outside of Oracle by the open source community. However, I have not found any indication that the licensing will change. I am work so I cannot go any deeper. I will be sending an email to the arch-dev-public mailing list about ZFS being added to the official repos. I have been maintaining the packages for the last six months and have had very little reports of problems from users, or issues compiling against new kernel versions. It has been a breeze maintaining these packages, and all credit goes to the upstream developers. They have done a wonderful job with the speed and stability of their support. Cheers.

therp commented on 2013-08-22 08:41 (UTC)

I uploaded a DKMS version of the SPL/ZFS modules/utils chain. See

commented on 2013-08-11 19:56 (UTC)

@demizer Not auch Problem for me. I will not work on it before wednesday anyhow.

demizer commented on 2013-08-11 18:45 (UTC)

@hlaube, well the demz-repo-archiso is out of date... I am working on a script right now to notify me of out of sync repos. I will update it when I get home. Once I have the time to setup my scripts and perform the update, I will report back to you. That should be sometime tonight or tomorrow. Sorry.

commented on 2013-08-11 05:01 (UTC)

@demizer I have booted installer-cd 2013.08, added your repo as described, loaded archzfs. The kernel is 3.10.5-1 as the archzfs is calling by its dependencies. What I am planing is to set it up as a root filesystem, if that will not work, I will boot that server, I am building, from a separate disk. Preferred ist root on zfs.

demizer commented on 2013-08-10 22:55 (UTC)

@hlaube, are you using the archzfs repo? If so, those packages will only work with the default 3.10.5 kernel. If not, how are you attempting to install the packages? Are you trying to use ZFS as a root filesystem? @megagram, I have never built these packages for the lts kernel, but there should be no problems. Have you tried "modprobe zfs" or "depmod -a" ? What is the log output from your efforts?

commented on 2013-08-10 21:22 (UTC)

Anybody have success building this on the linux-lts kernel? The two methods below from last year do not work for me. Modules are built and in /usr/lib/modules/3.0.89-1-lts/ but I cannot load them. Always syas module not found. Thanks.

commented on 2013-08-10 17:56 (UTC)

Hi Jesus, still seems not resolved. I tried set up a new system, instaled modules. A "zpool status" results into Failed to load ZFS module stack. Load the module manually by running 'insmod <location>zfs.ko as root An insmod /usr/lib/modules/3.10.5-1-ARCH/extra/zfs/zfs.ko results into insmod: Error: could not insert module /usr/lib... Unknown sysbol in module

demizer commented on 2013-08-08 20:21 (UTC)

It should work now everyone. Sorry about that!

demizer commented on 2013-08-08 20:19 (UTC)

Son of a gun! I forgot to push the updated repo to archzfs. Sorry about that everyone. I am going to setup a cron job to take care of it in the future.

jdn06 commented on 2013-08-08 10:40 (UTC)

I guess you forgot to update the demz-repo-core to 3.10.5-1. Thank you for your very useful work!

demizer commented on 2013-07-27 16:23 (UTC)

The packages have been updated to 3.10.3.

demizer commented on 2013-07-26 15:21 (UTC)

The packages have been updated. Unfortunately, I have had to create patches from the zfs git master branch to bring the zfs 0.6.1 release up to date to work for linux 3.10. The ZOL team has yet to make a new release since march. There should be no problems since everything that gets merged into the master branch is considered stable. Everything seems to work fine on my end, but you all may want to proceed with caution.

ezzetabi commented on 2013-07-26 09:19 (UTC)

New kernel is out: 3.10.2-1.

nemster commented on 2013-07-15 21:25 (UTC)

many thanks for the awesome work @demizer i have several machines, some even with zfs root.

demizer commented on 2013-07-15 19:55 (UTC)

Hello everyone. I think it is time to merge the "Installing Arch Linux on ZFS" into the main ZFS article. Please contribute to the discussion here: Thanks!

lenzcom commented on 2013-07-05 13:04 (UTC)

ah, thanks

demizer commented on 2013-06-29 17:38 (UTC)

@lenzcom, I just updated the packages, you should not have to change anything. Just re-download the packages from AUR.

lenzcom commented on 2013-06-29 17:32 (UTC)

ah, okay, just changed the kernel version to my running "3.9.8-1" in each package spl-utils=0.6.1_3.9.7-1 -> spl-utils=0.6.1_3.9.8-1 spl=0.6.1_3.9.7-1 -> spl=0.6.1_3.9.8-1 zfs-utils=0.6.1_3.9.7-1 -> zfs-utils=0.6.1_3.9.8-1 zfs=0.6.1_3.9.7-1 -> zfs=0.6.1_3.9.8-1 and build each of them with "makepkg -sf", afterwards "sudo pacman -U $pkg" worked like a charm.

lenzcom commented on 2013-06-29 17:13 (UTC)

pardon, this is what we need: "linux=3.9.7-1" makepkg -sf ==> Erstelle Paket: zfs 0.6.1_3.9.7-1 (Sa 29. Jun 21:11:32 CEST 2013) ==> Prüfe Laufzeit-Abhängigkeiten... ==> Installiere fehlende Abhängigkeiten... Fehler: Ziel nicht gefunden: linux=3.9.7-1 ==> FEHLER: 'pacman' konnte fehlende Abhängigkeiten nicht installieren.

lenzcom commented on 2013-06-29 17:10 (UTC)

same for me: resolving dependencies... warning: cannot resolve "linux=3.9.4-1", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.1_3.9.4-2", a dependency of "spl" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl-utils" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.1_3.9.4-2", a dependency of "spl" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl" warning: cannot resolve "spl=0.6.1_3.9.4-2", a dependency of "zfs" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.1_3.9.4-2", a dependency of "spl" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl" warning: cannot resolve "spl=0.6.1_3.9.4-2", a dependency of "zfs-utils" warning: cannot resolve "linux=3.9.4-1", a dependency of "zfs-utils" warning: cannot resolve "zfs-utils=0.6.1_3.9.4-2", a dependency of "zfs" warning: cannot resolve "linux=3.9.4-1", a dependency of "zfs" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.1_3.9.4-2", a dependency of "spl" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl" warning: cannot resolve "spl=0.6.1_3.9.4-2", a dependency of "zfs-utils" warning: cannot resolve "linux=3.9.4-1", a dependency of "zfs-utils" :: The following packages cannot be upgraded due to unresolvable dependencies: spl spl-utils zfs zfs-utils

ezzetabi commented on 2013-06-29 15:34 (UTC)

Linux kernel 3.9.8-1

commented on 2013-06-22 23:25 (UTC)

@demizer: Hm. You could be right about the missing /bin to /usr/bin symlink. I'll check the version of "filesystem" package once I get back to that PC, because as far as I remember, /bin was a directory with no files and just a few symlinks (bash being one of them). That seems weird.

demizer commented on 2013-06-22 22:19 (UTC)

@MilanKnizek, which package is failing? I have not had any problems. Do you not have a symlink in for /bin -> usr/bin?

commented on 2013-06-22 11:51 (UTC)

Building fails since there is hardcoded /bin/cp in The path should be /usr/bin/cp or just simple "cp" should work, too.

Dolpa commented on 2013-06-14 12:53 (UTC)

FYI if you have the missing zvol bug: I patched this package on my system and the zvols works again after reboot. These patches are now part of Gentoo's zfs kernel module package

demizer commented on 2013-06-13 01:40 (UTC)

The archzfs repo has been pushed to the host. Sorry about the f-up people.

demizer commented on 2013-06-12 17:18 (UTC)

Oh dang I forgot to push the repo to the host. I will push it when I get home later tonight. Sorry about that!

senorsmile commented on 2013-06-11 15:16 (UTC)

kernel 3.9.5 is out now. Zfs repo out of date.

demizer commented on 2013-06-11 01:17 (UTC)

@thunderforce, the packages were out of date. You should be good to go now.

thunderforce commented on 2013-06-11 00:29 (UTC)

while following this wiki I get stuck here: pacman -S gnupg vim archzfs warning: gnupg-2.0.20-2 is up to date -- reinstalling :: There are 4 members in group archzfs: :: Repository demz-repo-core 1) spl 2) spl-utils 3) zfs 4) zfs-utils Enter a selection (default=all): resolving dependencies... warning: cannot resolve "linux=3.9.4-1", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.1_3.9.4-2", a dependency of "spl" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl-utils" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.1_3.9.4-2", a dependency of "spl" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl" warning: cannot resolve "spl=0.6.1_3.9.4-2", a dependency of "zfs" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.1_3.9.4-2", a dependency of "spl" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl" warning: cannot resolve "spl=0.6.1_3.9.4-2", a dependency of "zfs-utils" warning: cannot resolve "linux=3.9.4-1", a dependency of "zfs-utils" warning: cannot resolve "zfs-utils=0.6.1_3.9.4-2", a dependency of "zfs" warning: cannot resolve "linux=3.9.4-1", a dependency of "zfs" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl-utils" warning: cannot resolve "spl-utils=0.6.1_3.9.4-2", a dependency of "spl" warning: cannot resolve "linux=3.9.4-1", a dependency of "spl" warning: cannot resolve "spl=0.6.1_3.9.4-2", a dependency of "zfs-utils" warning: cannot resolve "linux=3.9.4-1", a dependency of "zfs-utils" :: The following packages cannot be upgraded due to unresolvable dependencies: spl spl-utils zfs zfs-utils :: Do you want to skip the above packages for this upgrade? [y/N] Do I have to update to an updated zfs package (kernel 3.9.5-1) or what should I do?

ezzetabi commented on 2013-06-03 14:36 (UTC)

Marked out-of-date as the zfs-utils and spl-utils packages leave files in /usr/sbin. To fix I changed the PKGBUILD configure --sbindir line to /usr/bin in both packages. In zfs-utils I patched the Makefile in /src/zfs-0.6.1/cmd/mount_zfs after calling configure.

WhiteKnight commented on 2013-05-28 17:06 (UTC)

Same here: no objections.

senorsmile commented on 2013-05-28 16:11 (UTC)

no objections here. using zfs with testing repo sounds like a recipe for disaster.

demizer commented on 2013-05-28 16:10 (UTC)

Hey all, the packages have been update. Thanks for the notifications. I'm thinking about dropping the testing repo. No one uses it and I don't keep up with it that often. Anyone have any objections?

ezzetabi commented on 2013-05-28 11:59 (UTC)

Ahhh... here is the problem. In one computer I set correctly the core repo, instead in the other I set the archiso. Thanks a lot. Still there is a kernel version dump, 3.9.4-1. Flagging out of date.

commented on 2013-05-28 09:28 (UTC)

@ezzetabi There are multiple repos: - demz-repo-core - demz-repo-testing - demz-repo-archiso See

ezzetabi commented on 2013-05-28 08:17 (UTC)

Wait a second, so it means there is no repository with for the current kernel version?

demizer commented on 2013-05-27 17:17 (UTC)

@ezzetabi, that is correct. The archiso repo only tracks the latest archiso release. According to, that is kernel 3.8.10.

ezzetabi commented on 2013-05-26 14:33 (UTC)

The package here is fine, but the repo still has zfs 0.6.1_3.8.10-1.

lachesis commented on 2013-05-21 03:53 (UTC)

Linux kernel version bump today, to 3.9.3-1.

commented on 2013-05-19 15:33 (UTC)

@demizer solved it: i ran "depmod" once, and then "modprobe zfs" works fine

commented on 2013-05-19 15:28 (UTC)

@demizer thanks i'll check there

demizer commented on 2013-05-19 04:06 (UTC)

@cinch, I have no clue why it is not working. All I can tell you is that I think ZOL is meant to be used with a vanilla kernel. I would recommend you go check the github issue tracker to see if there are issues with ZOL and custom kernels.

commented on 2013-05-18 21:22 (UTC)

just compiled it via aur, but it doesn't seem to working right: david@mango ~ % sudo modprobe zfs modprobe: FATAL: Module zfs not found. david@mango ~ % locate zfs.ko /usr/lib/modules/3.9.2-2-ck/extra/zfs/zfs.ko david@mango ~ % uname -a Linux mango 3.9.2-2-ck #1 SMP PREEMPT Sun May 12 22:46:40 CEST 2013 x86_64 GNU/Linux david@mango ~ % sudo insmod /usr/lib/modules/3.9.2-2-ck/extra/zfs/zfs.ko insmod: ERROR: could not insert module /usr/lib/modules/3.9.2-2-ck/extra/zfs/zfs.ko: Unknown symbol in module

ezzetabi commented on 2013-05-13 16:59 (UTC)

Sorry, my bad.

demizer commented on 2013-05-12 04:22 (UTC)

@ezzetabi, That is correct. The current archiso has kernel 3.8.10: I just tested it and it worked fine. Can you include more detail please?

ezzetabi commented on 2013-05-11 19:45 (UTC)

The repo still has 0.6.1_3.8.10-1.

proxypoke commented on 2013-05-06 18:42 (UTC)

@jpapadopoulos: I run ZFS with a ck kernel just fine. @senorsmile: Your kernel version and the version that ZFS in the repos was compiled with likely do not match. Try building it yourself from the AUR.

senorsmile commented on 2013-05-04 18:20 (UTC)

I am testing zfs on root following directions at archiso worked fine. I booted to cd, added repo and key and installed. modprobe zfs gives 1 and when I try to zpool create I get "Failed to load ZFS module stack. Load the module manually by running 'insmod <location>/zfs.ko' as root." I actually tried insmod /usr/lib/modules/3.8.11-1-ARCH/extra/zfs/zfs.ko which gave "insmod: ERROR: could not insert module /usr/lib/modules/3.8.11-1-ARCH/extra/zfs/zfs.ko: Unknown symbol in module"

jpapadopoulos commented on 2013-05-04 12:22 (UTC)

Does this work with patched kernels like linux-ck or zen?

ezzetabi commented on 2013-05-03 15:15 (UTC)

Linux 3.8.11 is out.

proxypoke commented on 2013-05-03 15:01 (UTC)

100% installation including boot doesn't work, to my knowledge. You need a separate /boot. The rest, however, does work - I've done it - but it's very brittle, and really not worth the trouble IMO. Though, it's been a while since I've migrated back to ext4 for / and /home, so this might have changed. Go ahead and try, I'd love some new data on this.

demizer commented on 2013-05-02 15:21 (UTC)

@ezzetabi, the archiso repo has been updated. Sorry it took longer than I had expected.

ezzetabi commented on 2013-05-02 09:47 (UTC)

100% installation might be a problem. But there are no problems if you keep /boot (and /boot/efi, if applicable) in a separate partition. Read the wiki about how-to, seek for `zfs'

jnbek commented on 2013-05-01 19:51 (UTC)

I wonder how hard a 100% ZFS Arch Install would be..... Is there a ZFS forum post?

ezzetabi commented on 2013-05-01 17:55 (UTC)

The AUR package is actually up-to-date, but the repository still has version 0.6.1_3.8.4-1 .

ezzetabi commented on 2013-04-30 12:17 (UTC)

Sorry, I flagged by my mistake. I did not notice the repo has changed...

demizer commented on 2013-04-28 00:15 (UTC)

@foolosophy, you will have to delete the specified files.

demizer commented on 2013-04-28 00:15 (UTC)

@foolosophy, somehow my signatures got messed up. It should be fixed now.

foolosophy commented on 2013-04-27 21:39 (UTC)

Sorry for being a pain in the ass, but I have already done "pacman-key --lsign-key 0EE7A126" and when upgrading, pacman says: File /var/cache/pacman/pkg/spl-utils-0.6.1_3.8.8-2-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] (for all four packages)

foolosophy commented on 2013-04-27 05:30 (UTC)

Ooops: all the info is there, you're right. I deleted my comment before seeing you had already replied. Sorry!

demizer commented on 2013-04-27 05:28 (UTC)

@foolosophy, Thanks! The packages have always been signed. See for more info. The script used to build the packages is available in this repo: The archzfs website also details how to setup a build environment for building packages with

demizer commented on 2013-04-27 05:12 (UTC)

Hello everyone! The pre-built package repo has been relocated. The new server string is as follows: [demz-repo-core] Server =$repo/$arch For anyone tracking the testing repo: [demz-repo-testing] Server =$repo/$arch

WonderWoofy commented on 2013-04-27 01:09 (UTC)

Thanks for the heads up demizer.

demizer commented on 2013-04-26 16:28 (UTC)

The packages have been updated. I also made the dependencies on the kernel specific to the pkgrel as it should be. The packages must be rebuilt on _every_ kernel release. I have yet to update the archzfs repo because I am rewriting the build tool into a regular bash script to make it easier to build for newcomers. I am also changing the way my repositories are implemented so I am not maintaining a bunch of different repositories. The path to repository will change, so it will need to be changed in your pacman.conf. This should be done by tonight. Sorry!

WonderWoofy commented on 2013-04-26 15:18 (UTC)

This may be out of date, but since the official repo kernel update was from 3.8.8-1 to 3.8.8-2 a simple version bump and pkgrel increase should to the trick. Of course you could just force recompile it against the new kernel with the same pkgver/pkrel so that any update demizer puts through will show up on any of those helpers many use.

timemaster commented on 2013-04-20 02:13 (UTC)

demizer release new version of the package 1-3 days after a new version of the upstream software or a new kernel version. He also offer a pacman repository instead of the aur. I am happy with demizer work.

jnbek commented on 2013-04-20 02:08 (UTC)

how well maintained is this package?

demizer commented on 2013-04-19 03:53 (UTC)

For anyone using the pre-compiled archzfs repo, I am soon going to be merging my repositories into one repo to ease maintenance. This would probably be in the next release.

ezzetabi commented on 2013-04-08 14:37 (UTC)

Linux 3.8.6 is out.

ezzetabi commented on 2013-04-05 09:18 (UTC)

Linux 3.8.5 is out.

timemaster commented on 2013-03-31 01:02 (UTC)

Before upgrading the zfs and spl package using pacman, should we unmount all filesystem and modprobe -r the modules to prevent weird behaviour ? - The same behaviour as upgrading the X server and not the proprietary graphic display driver, or upgrading the kernel or libc and not rebooting the machine. Is this something worth writing in the wiki?

demizer commented on 2013-03-28 01:01 (UTC)

The production ready version 0.6.1 of ZFS and SPL have been released. The packaging has changed greatly and will probably take a day or two to test and make sure everything works on my systems.

demizer commented on 2013-03-23 00:56 (UTC)

The core and testing archzfs repos have been updated to 0.6.0_rc14_3.8.4-1.

demizer commented on 2013-03-22 17:36 (UTC)

It appears someone has already made dkms packages for zfs, But these only extract the precompiled rpm packages for redhat, I do not recommend this. The modules should be built with libraries compiled for arch.

demizer commented on 2013-03-22 17:23 (UTC)

@darklajid, if you do wind up working on an update script for cron, instead of doing a pacman update, you should use curl to get this page and just grep the version. Be warned though, new kernel versions first show up in testing before they are moved to core. I think if I set this script up on my development system I would have one cronjob for testing and one for core. Usually I create the packages for testing first and then after a few days I move them into the core directory of the archzfs repo project.

demizer commented on 2013-03-22 17:08 (UTC)

wowzers, a lot of activity going on here. Great! @teateawhy, thanks for the tip. 3.8.4 moved into core really fast. @darklajid, yes it is due to the archzfs repo not being current. Sorry about that. Your idea of an automated system is really worth investigating (I have half of it done already). If you want to help make an update script to run in cron, can make a script to change the PKGBUILD dependency version requirements in the devsrc directory in this project: and run another command once the PKGBUILDs are updated that would be great. Just fork the repo and add the script to a "tools" directory and send a pull request. That would be awesome. I use this build tool to build the packages in a build environment Note: The apc build tool is currently being rewritten in the "command_refactor" branch, but this branch is broken. I am not even sure if this tool would work for you yet, it is under heavy development. But the command I use to build the packages are "PYTHON_PATH=/path/to/pbldr pbldr build" while being in the directory of the archzfs repo with the config.yaml file. If this is too much, I understand. I am going to spend this weekend looking into dkms and pacman hooks for those that want to build the packages themselves on a kernel update. @ezzetabi, That is an interesting idea, I will take a look at that this weekend too. Thanks!

flrichar commented on 2013-03-22 16:18 (UTC)

Maybe just change the packagebuild to include the dependencies as linux>=3.8.0? Then you can call the package zfs_rc14_3.8.x-4 and you're all set until 3.9. :)

darklajid commented on 2013-03-22 14:58 (UTC)

Ah.. Stupid me. I thought that's a weird dependency issue, when in fact it's just a (simple) missing bump for kernel 3.8.4 instead. Would it make sense to automate this step? Cronjob syncing with pacman (or just a plain old curl/wget to a mirror and grepping the "linux" package version), bumping the PKGBUILD or rebuilding the package for the repository? Can I help? And of course: Thanks for doing the maintenance in the first place.

darklajid commented on 2013-03-22 14:26 (UTC)

Hmm.. I'm still not sure what the right way to update my system is here. So, I'm doing upgrades not every day, more in ~random~ intervals every couple days, up to 1-2 weeks. Now: [root@bitdump dar]# uname -a Linux bitdump 3.7.10-1-ARCH #1 SMP PREEMPT Thu Feb 28 09:50:17 CET 2013 x86_64 GNU/Linux [root@bitdump dar]# pacman -Suy :: Synchronizing package databases... core is up to date archzfs is up to date haskell-core is up to date haskell-extra is up to date haskell-web is up to date extra is up to date community is up to date :: Starting full system upgrade... resolving dependencies... warning: cannot resolve "linux=3.8.3", a dependency of "spl" warning: cannot resolve "linux=3.8.3", a dependency of "spl-utils" warning: cannot resolve "linux=3.8.3", a dependency of "spl-utils" warning: cannot resolve "linux=3.8.3", a dependency of "zfs" warning: cannot resolve "linux=3.8.3", a dependency of "spl" warning: cannot resolve "linux=3.8.3", a dependency of "zfs-utils" warning: cannot resolve "linux=3.8.3", a dependency of "spl-utils" warning: cannot resolve "linux=3.8.3", a dependency of "zfs-utils" warning: cannot resolve "linux=3.8.3", a dependency of "spl" warning: cannot resolve "linux=3.8.3", a dependency of "spl-utils" :: The following packages cannot be upgraded due to unresolvable dependencies: spl spl-utils zfs zfs-utils Do you want to skip the above packages for this upgrade? [y/N] y looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: spl: requires linux=3.7.10 :: spl-utils: requires linux=3.7.10 :: zfs: requires linux=3.7.10 :: zfs-utils: requires linux=3.7.10 I'm using the binary repository you're offering (thanks!), but .. still no luck. Is there any way out of this without doing a manual step every time I'm in this situation? I know I _can_ remove the packages, update the kernel and reinstall them. But that's feels nasty. Are dkms packages the only option here? Do I miss anything?

ezzetabi commented on 2013-03-21 07:26 (UTC)

Sorry demizer, I was totally unclear. For what I know pacman reads the list of packages from the /etc/pacman.conf in the order they appears. So if I put the demizerone repo in the top it should be checked as first. What I was thinking is: if you keep a copy of the default arch kernel (the one meant to be used with zfs packages) in demizerone repo together with zfs then the user can your repository as first and it should not possible to break the kernel image as pacman will not download a newer pkgrel as it will check your repository first. Maybe it does not really work this way, it was just a wild idea. It is worth a try however, because wait a little to update the kernel is usually not a problem at all, and I never thought you were slow in updating. But updating the system and see that it broke the kernel image is annoying, not noticing it might make the system not-bootable. Seriously, thanks to keep this package and a repo for it.

demizer commented on 2013-03-21 06:24 (UTC)

Okay had to increase the pkgrel to 4, this fixes this issue with the depmod command in run_depmod() and i18n. Still not really necessary to update unless you don't use English as your system language.

demizer commented on 2013-03-21 04:50 (UTC)

For those that use the archzfs core and testing repositories the packages have been fixed. If your build from AUR, you don't need to worry about the update. Thanks!

demizer commented on 2013-03-20 16:20 (UTC)

@ezzetabi if you use the archzfs repo I maintain you will get updates to zfs as soon as I release them, but only for the official kernel package. If you use a custom kernel you will have to build the packages yourself. IMO this is the best it will get due to the licensing issues. Sometimes the kernel version gets away from me and I am sorry about that. I got a lot of stuff going on in my personal life, so I lose track sometimes. That being said, I love maintaining these packages so keeping them up-to-date when there is a new release (zfs or kernel) is not a problem.

demizer commented on 2013-03-20 16:13 (UTC)

Sorry about the wait. The packages have been updated. I have updated the testing and core repositories for the archzfs repo.

ezzetabi commented on 2013-03-20 10:54 (UTC)

Marked out of date, current kernel version is 3.8.3-2... I was thinking, it is possible to keep a copy of the kernel in the same repo of zfs so they get updated together?

demizer commented on 2013-03-16 19:32 (UTC)

The testing repo has been updated to 0.6.0_rc14_3.8.3-1 To use the testing repo, in pacman.conf add: [archzfs] Server =$repo/testing/$arch

Achterin commented on 2013-03-07 08:52 (UTC)

thanks for updating. works like a charm...

demizer commented on 2013-03-07 06:22 (UTC)

I have updated the packages to pkgrel=3. I have finally removed the hardcoded depmod kernel version because it was a pain one too many times.

demizer commented on 2013-03-07 01:28 (UTC)

@achterin, it should be pkgrel=1 but I forgot to change it to 1. However, it shouldn't be a problem. Thanks for the note.

Achterin commented on 2013-03-06 15:44 (UTC)

hey demizer, i may understand it wrong but could it be that if pkgrel=2 it requires 3.7.10-2? if so this will fail because the current core kernel is 3.7.10-1. thanks for your time

demizer commented on 2013-03-02 03:02 (UTC)

I have update the testing and archiso repos for these packages: testing: ZFS 0.6.0_rc14_3.8.1-1 archiso: ZFS 0.6.0_rc14_3.7.9

timemaster commented on 2013-02-28 02:59 (UTC)

Thanks for your hard work demizer.

demizer commented on 2013-02-28 02:53 (UTC)

Ok the packages have been updated. Sorry for the misunderstanding everyone! For future reference, the ZFS packages need to be updated even on kernel updates that only effect the kernel packaging, i.e., pkgrel=1 to pkgrel=2.

ezzetabi commented on 2013-02-27 21:52 (UTC)

Yes, updating now the kernel (even if pacman is configured with demizerone repository) breaks the kernel image.

Achterin commented on 2013-02-27 13:18 (UTC)

hi demizer, i've flagged it out of date because the package has linux 3.7.9-1 as dependency while linux 3.7.9-2 is in the core repository. the same problem exists for your pacman repository. so the problem for me is, that i've installed the new kernel and can't use your repository because, as mentioned before, it reqiures the old package. the only 2 solutions for me would be to downgrade the kernel or use the aur pkg and edit it myself. nevertheless your pkg is out of date because it requires an old kernel pkg. sorry for flagging it without a notice.

demizer commented on 2013-02-27 02:12 (UTC)

I will be fixing the hardcoded depmod verison in spl.install and zfs.install soon, it is on my todo list. Also, anyone that is using the official testing repo (which currently has kernel 3.8) can use the archzfs testing repository with [archzfs] Server =$repo/testing/$arch If this is the reason someone flagged the packages out-of-date, please don't do that. Kernel 3.7.9 is still the current kernel in core. As a general courtesy when using AUR, if you flag any packages out of date, please have leave a note on the reason. In the case of ZFS it can be anything, and I have to work to find the reason and this is annoying.

demizer commented on 2013-02-27 01:59 (UTC)

@timemaster, there are no problems updating the zfs packages from a kernel pkgrel update. I just confirmed on my desktop system.

timemaster commented on 2013-02-27 01:11 (UTC)

I see that there is a new revision of the kernel available (3.7.9-2) "-2" and the kernel upgrade does not include new zfs modules for this -2 revision. Is this a changes that you made after the last comment of lebel ? Is it safe to upgrade that kernel revision but keep the same zfs modules ?

demizer commented on 2013-02-19 08:43 (UTC)

@lebel, most (all?) kernel modules are built to a specific kernel version (see nvidia for example). ZFS is hardcoded by upstream to target the kernel that the headers are pulled from when building the module. The kernel version is hardcoded into the path for the ZFS kernel module i.e., "/usr/lib/modules/3.7.9-1-ARCH/addon/zfs/zfs/zfs.ko". So it must target that kernel version or it will not work. Admittedly I have not tried to route around and find a solution because I don't run into problems performing updates. If you don't/can't use the the pre-built packages I have at, then you can build in a clean chroot using the tool I use, or the tools available package. Once you have built packages, add them to a local repo that you maintain and you will have nice clean updates without having to remove anything. See the repo-add command that comes with pacman, or the makechrootpkg command in devtools. Every package I personally use from AUR are built and added to a local repo. This repo is synced to all of my computers so I only have to build once, and update everywhere. The arch devs made greatly useful tools for package management, but little documentation on how to use them it seems.

commented on 2013-02-18 17:56 (UTC)

Why the need to follow the exact version of kernel? I don't see any particular reason to do it and it breaks updates as soon as there is a new kernel.

commented on 2013-02-16 09:48 (UTC)

[UPDATED after verification] @lebel: you can recompile all the zfs/spl packages before reboot - it will find the new kernel headers despite that an old kernel is still used (in memory). If the install script of zfs/spl produces a warning, you might need to run `depmod $NEW_KERNEL_VERSION` manually.

commented on 2013-02-15 16:24 (UTC)

@lebel: you can recompile all the zfs packages before reboot. Though, the install scripts will produce an error - depmod will fail and after reboot the new kernel will not find zfs and spl modules. Easy solution is to run depmod against the new kernel before reboot manually. (I think -k switch is the one. Check the man page.)

commented on 2013-02-13 14:52 (UTC)

Well, seeing that I'll lose access to my zfs drives after the first reboot, I was looking into ways in upgrading zfs packages even while still running 3.7.6.

KuchenKerze commented on 2013-02-13 14:04 (UTC)

@lebel Two options: 1.) Exclude the Kernel from updates # pacman -Syu --ignore=linux,linux-headers,linux-api-headers 2.) Remove zfs $ yaourt -R zfs zfs-utils spl spl-utils Update # pacman -Syu Reboot Reinstall zfs $ yaourt -S zfs Make sure that a zfs update for the new kernel is available before updating the kernel

commented on 2013-02-13 13:46 (UTC)

I guess it is normal, but a little bit awkward right now. I'm running linux-3.7.6 with the associated zfs and now that a new kernel version is out, it is impossible for me to upgrade. It says: error: failed to prepare transaction (could not satisfy dependencies) :: Starting full system upgrade... :: spl: requires linux=3.7.6 :: spl-utils: requires linux=3.7.6 :: zfs: requires linux=3.7.6 :: zfs-utils: requires linux=3.7.6

demizer commented on 2013-02-05 08:48 (UTC)

I have pushed a new update that contains fixes for issues #2 and #3 ( relating to missing files when trying to build the initramfs.

demizer commented on 2013-02-04 20:00 (UTC)

With the recent announcement by the Arch Devs. that the old sysvinit system is going to be dropped, I am looking to file a few issues with upstream regarding Arch Linux support in ZOL. These issues include: * Remove initscript generation from the ZOL build system. * Remove Arch Linux package generation from the ZOL build system. (See below.) * Provide a link to the ZFS wiki article on the page. Currently, both of the spl and zfs packages have configuration options to create generic packages for arch linux. I am not sure when this support was last maintained, but I had a look at the packages it created once and they are very basic. The PKBGBUILDs on AUR provide better packages. With the support I provide, I don't think this support is necessary in the upstream packages, but I could be wrong. I don't see it being very effective supporting two package systems when AUR is all anyone needs. So to anyone subscribed to this stream, if you have any objections voice them now. Thanks, Jesus A.

demizer commented on 2013-01-22 19:16 (UTC)

@darklajid: There were two annoying problems I have run into so far while getting the bugs out of my build system and maintainership. First, there was one dependency rejection issue a month or two ago because I changed the structure of the pkgver variable in all of archzfs PKGBUILDs to include the kernel version to prevent issues with pkgrel collisions. I was having trouble keeping track of what pkgrel belonged to what kernel version, especially when new kernels appeared in testing, and core at the same time. I will not change the the structure of the pkgver variable in the pkgbuilds again. The second problem happened a few weeks ago when I had to change the repo url path because I added a testing repository and wanted to keep a uniform url path for all of the different repos used by archzfs (archiso, testing, core). I have been ironing out my build process and I have seem to have finally hit a groove, so there should not be any more breakage regarding the archzfs repo. Hopefully! The archzfs repository is the best automatic updates you can get for ZOL on Arch. There is zero building. The only thing is is that you have to wait for me to update the packages. I can usually get them uploaded within a few hours. I try my best. That being said, I was waiting for mkinitcpio build hooks to be integrated into mkinitcpio. I am definitely going to take a look. mkinitcpio build hooks are like DKMS, but done in the "Arch Way". As far as I can tell. Thanks for letting me know!

darklajid commented on 2013-01-22 18:49 (UTC)

proxypoke: Nope, I'm talking about the need to update zfs (+deps) when the kernel changes. That's why I pointed at the nvidia-hook thing: It's used to rebuild the nvidia module (for the proprietary driver) each time the kernel is updated, automagically. demizer: I'm not too concerned about compiler flags or that you'll drop evil binary packages on my machine, but I seem to recall that I hit the dreaded 'Cannot run pacman -Suy because zfs has a hard dependency on the current kernel' message a couple times. I'd guess that you're keeping that thing up to date on a best-effort basis, i.e. when you notice that the kernel version was bumped. The effort is very much appreciated, really. I'd just love to find a way to automate the whole process, if possible. I'm not sure IF nvidia-hook is potentially helpful as an example, but at least it's running ~some script~ everytime the kernel is bumped -> That's a start? Thanks for looking into it and thanks for your time maintaining these packages.

demizer commented on 2013-01-22 18:43 (UTC)

@proxypoke: I did not think your were arguing at all. Thanks for caring though! Believe me I don't want any legal troubles. @darklajid: Sweet! I didn't realize the build hook feature of mkinitcpio was ready yet. I will definitely take a look at it. However, I do have a pre-built repository for ZOL packages at, but I do understand some users like to compile packages with their own compiler flags. I use the standard compiler flags used by all arch packages provided by the devtools package. I had started to work on DKMS packages, but they got sidelined when I created the archzfs repository.

proxypoke commented on 2013-01-22 15:56 (UTC)

@darklajid: I think there are dkms packages in demizer's repository, which is essentially what you want. See for more info. Correct me if I'm wrong. @demizer: I really don't mean to argue with you because I, as mentioned, respect what you are doing and, by all means, want you to continue to do so. So forget I said anything, I don't think anyone cares enough. ;)

darklajid commented on 2013-01-22 11:19 (UTC)

So, I'm not the most clever guy and new to Arch Linux. You guys (or at least you, demizer) probably thought about rebuilding zfs in a hook, a la nvidia-hook? Is that impossible? A bad idea? Why?

demizer commented on 2013-01-19 17:29 (UTC)

@proxypoke, Thanks for the notification, but I am not worried. I don't think the Ubuntu people or fedora people or even the ZOL people would be distributing pre-compiled packages if there was an issue. I think the license incompatibility comes in when merging the two source tree and distributing it that way. The way the packages are setup now, the source trees are still separate, and distributed separately. The packages are even licensed separately. However, if I do get a cease and desist from Oracle, I will remove the packages. I don't think that's going to happen.

proxypoke commented on 2013-01-19 15:02 (UTC)

"Pre-compiled packages are available" I just want to point out that you are treading on thin ice here. You are technically violating both the GPL and CDDL. I don't think many people care (or anyone for that matter), but the whole reason that ZFS is here in the AUR is that you have to compile it yourself due to the incompatible licenses. I really appreciate the work you do, so I wanted to warn you about this. I don't believe the risk is anything to speak of (since there is really no one that could sue you or anything), but it's a license violation nonetheless.

demizer commented on 2013-01-19 08:58 (UTC)

I have re-updated the testing repository to the correct version, 0.6.0_rc13_3.7.3-1. This version targets the 3.7.3 kernel in testing.

demizer commented on 2013-01-19 08:22 (UTC)

I have updated the testing repository to 0.6.0_rc13-3.7.2-1 to match the 3.7.2 kernel in testing. Sorry it took so long. These packages support both architectures. Information about using the archzfs testing repository can be found at, or you can use the following server line in your pacman.conf: [archzfs] Server=$repo/testing/$arch If you want want the PKGBUILDs, download them from here:

demizer commented on 2013-01-19 07:00 (UTC)

Good news everyone! The ZOL packages for Arch Linux now support i686. Pre-compiled packages are available for those that are using ZFS as root, want to do maintenance from an Archiso, or just don't want to deal with doing their own update management. They are available at

demizer commented on 2013-01-05 07:03 (UTC)

Just a quick note, I have re-written the "Installing Arch Linux on ZFS" article on the wiki. You can view it here: This update only includes UEFI configuration at the moment because that is what the laptop had to work with. If anyone can add some content about BIOS installations that would be great! -demizer

demizer commented on 2013-01-05 03:13 (UTC)

The ZFS packages have been updated to Kernel 3.6.11. !! IMPORTANT !! If you are using the archzfs package repo, you will need to update your server string to "$repo/core/$arch". This change was made to allow for multiple repositories. The repo path will not be changed again. I have now added support for a testing repository. This repo tracks the kernel in the official testing repository. The server string for the testing repo is "$repo/testing/$arch". For more information, visit

demizer commented on 2012-12-30 16:43 (UTC)

@sweston, I was actually working on compiling i686 packages last night. I ran into some build issues though and think your tip will help me through. Thanks!

sweston commented on 2012-12-30 14:45 (UTC)

Just a note to anyone having issues building on i686; you will need to compile spl with an extra option for ZFS to build properly:

sweston commented on 2012-12-30 13:18 (UTC)

I can confirm this builds properly on arm (my raspberry pi) and i686 (a pentium III). I know this isn't entirely recommended but the developers have been working on 32-bit stability lately and it is stable so far for me. If you could add arm and i686 to the 'arch' line that would make my life marginally easier. Thanks

demizer commented on 2012-12-23 17:10 (UTC)

Just a heads up, I am currently on vacation, so if there is some reason I cannot push ZFS updates you can get them here: The last numerical digits of the package version are the kernel version the package is built against.

demizer commented on 2012-12-20 23:33 (UTC)

ZFS rc13 was just released. I will update the package when kernel 3.6.11 is released to core.

proxypoke commented on 2012-12-17 12:05 (UTC)

@chenxiaolong: Thanks, that worked like a charm. For anyone else who follows this advice, remember to `depmod -a` after building ZFS, else zfs and zpool won't find the newly installed modules. Take note that without any options to configure, man pages and some other things aren't installed. It should be enough to just copy the flags from the PKGBUILD to fix that.

demizer commented on 2012-12-15 18:41 (UTC)

I have updated the packages to pkgrel 8 fixing the initial ramdisk generation after installing the updated zfs package in cases of using zfs in the hooks array in mkinitcpio.conf.

demizer commented on 2012-12-15 06:21 (UTC)

!IMPORTANT! For users that are using ZFS as root, there is a problem with the current package when generating the ramdisk with mkinitcpio. The problem is that once the kernel is installed, the mkinitcpio is initiated before the ZFS packages have been installed. This produces errors because mkinitcpio cannot find the ZFS binaries needed by the install hook. To fix this, use: # depmod -a 3.6.10-1-ARCH # mkinitcpio -p linux

demizer commented on 2012-12-15 05:49 (UTC)

The packages and repository have been updated for kernel 3.6.10.

demizer commented on 2012-12-14 17:14 (UTC)

Indeed, ZFS does not build against Kernel 3.7. In order not to have these packages be flagged out of date for an extended period of time, I have created patches for ZFS and SPL including the fixes from the ZOL master branches and packaged them using pkgrel 8. The patch includes all the changes made up until the last release. ZOL is very weird in how they make releases, they are no rhyme or reason to them, they just happen and it seems anything that touches the master branch is stable. I have been running these updated packages for a couple days without incident. I also have the packages for 3.6.10 ready to go (pkgrel-7), I am just waiting for 3.6.10 to hit [core]. I am thinking about creating a testing repository for these packages so I can push updates out for testing. In other news, I have created a branch that tracks the archiso so we can do emergency maintenance if need be. The server string for pacman.conf is as follows: [archzfs] Server =$repo/archiso/$arch Of course, you will also need to add my key and locally sign it before using, but now we can use zfs in the archiso environment without compiling! I have installed ZFS on a root filesystem on my wife's laptop, there are changes coming to the packaging to improve the implementation. Most of all I am working on updating the archwiki documentation and that should be up in the next week or two.

chenxiaolong commented on 2012-12-14 17:14 (UTC)

@proxypoke: That has been fixed in the latest zfs git :) You can clone the git repo ( and run ./ ./configure make pkg which will create Arch Linux .pkg.tar.xz packages you can install.

proxypoke commented on 2012-12-14 14:27 (UTC)

Ahoy all, ZFS doesn't compile on Linux 3.7.0 yet. I tested this with the ck patchset, but it should be the same on the standard kernel. It gives an error about GPL-only symbols when linking zfs.ko. Short error log attached: I'd advise against kernel updates if you need ZFS. Cheers slowpoke

demizer commented on 2012-11-30 09:21 (UTC)

The ZFS package has been updated to pkgrel 5 and now supports for kernel 3.6.8. Changes include: * mkinitcpio hooks rewrite thanks to falconindy. * Removed support for spl_hostid kernel parameter. * Rewrite of systemd unit file thanks to duncant. * Experimental handling of /etc/hostid. /etc/hostid is now tracked by the spl-utils package. * Rewrite package descriptions. I apologize in advance for the long post, but a lot has changed. The systemd unit rewrite now properly loads the kernel modules with modprobe and also exports the zfs shares. The mkinitcpio hooks have been rewritten to support the next version of mkinitcpio. The spl-utils package now tracks the /etc/hostid file. This file is used by zfs to include in the storage pool metadata when creating pools. In some cases if this value differs from /etc/hostid and the pool metadata, zfs will refuse to import the pool producing an error saying that the foreign pool could not be imported. Supposedly, the hostid command produces a 32 bit unique identifier on every fresh reboot using the systems IP address. So the hostid gathered when you created the pool can be different from what the hostid command currently produces. I say supposedly because in my tests, my hostid has not changed from boot to boot. This could be because I use a static IP address though. The hostid used when creating your zfs pools can be gathered by using the command "zdb". The /etc/hostid file itself is a 4 byte little endian binary file. So `echo $(hostid) >/etc/hostid` is not the proper way to set the hostid value. One way to set the hostid is the following: HOSTID=$(hostid) sudo sh -c "printf $(echo -n $HOSTID | sed 's/\(..\)\(..\)\(..\)\(..\)/\\x\4\\x\3\\x\2\\x\1/') >/etc/hostid" You could also make a quick and dirty C program that calls sethostid(id). The spl-utils package now tracks the /etc/hostid file. If it already exists on your system, you will need to record the value somewhere and let the spl-utils package overwrite it using "pacman -Sf" (or delete the file yourself). If the value in your /etc/hostid is correctly set, than you can retrieve it using the following command: $ od -A n -t x1 /etc/hostid > 00 01 7f 00 Note: If correctly set, this value will have the low-order byte first, so it will have to be saved back to /etc/hostid with: sudo sh -c "printf $(echo -n 00017F00 | sed 's/\(..\)\(..\)\(..\)\(..\)/\\x\1\\x\2\\x\3\\x\4/') >/etc/hostid" The value produced should be only 4 bytes! If it is not, then it is okay to let the spl-utils post_install hook produce a proper hostid for you. Since the proper hostid is now included in the initramfs, I dropped support for the spl_hostid kernel parameter check in the initcpio hook. All it did anyways was echo the value to /etc/hostid, which is incorrect. NOTE: If you are using this parameter, you will be kicked out to the repair command line in the initramfs! You should now instead use the method described above to set this value to /etc/hostid. You will then need to rebuild your initramfs with "mkinitcpio -p linux". One last thing, To be on the safe side, make sure you have good backups before performing any updates ALWAYS. Whew! - demizer

demizer commented on 2012-11-29 18:29 (UTC)

The ZFS packages have been flagged out of date. Kernel 3.6.8 is now in [core]. I am currently working on fixing hostid issues in the spl package. The new packages should be uploaded to AUR within the next day or two. Thanks!

demizer commented on 2012-11-28 22:59 (UTC)

@ronnylov, copy to /usr/lib/systemd/system/zfs.service for the time being. I will update the packages in AUR once kernel 3.6.8 is out of testing. Thanks!

commented on 2012-11-28 22:36 (UTC)

Directories shared by sharenfs=on are not automatically shared after reboot when moving from rc.conf to zfs systemd unit file. I have to manually export and import my pool to make it enable the sharing again. How can I solve this? Maybe I have to make sure zfs is started after the nfs services...

demizer commented on 2012-11-26 09:55 (UTC)

The ZFS package has been updated to pkgrel 4. Changes include: * mkinitcpio updates for the initramfs install hook. * Cleaned up mkinitcpio install hook help documentation (mkinitcpio -H zfs). * Added a systemd unit file The systemd unit file allows the mounting of zpools at startup. This also makes it possible for the ZFS packages to not have to depend on initscripts for initialization. If ZFS is your last hold out for initscripts, like it was for me, you can now remove initscripts. The usage of the new unit file is pretty typical for systemd unit files: # systemctl enable zfs # systemctl start zfs # systemctl status zfs # systemctl stop zfs I have not fully tested all of these changes, especially in the updates to the mkinitcpio install hook. But they are not considered dangerous or data threatening. The systemd unit file only calls 'zfs mount -a' and 'zfs unmount -a' for example. To be on the safe side, make sure you have good backups before performing any updates ALWAYS.

demizer commented on 2012-11-26 03:21 (UTC)

@falconindy, thanks for the heads up! Will do.

falconindy commented on 2012-11-26 02:30 (UTC)

Hi, this mkinitcpio hook is going to break soon. Please avoid using MODULES and SCRIPT and use the functions "add_module" and "add_runscript" instead.

demizer commented on 2012-11-26 00:34 (UTC)

@ronnylov, So sorry! I pushed packages that didn't have any kernel modules in them, yikes! I have changed my procedures so this doesn't happen again. In this case, instead of building from scratch, I repackaged. Somewhere in development the kernel modules got deleted. I also didn't perform a proper test before pushing the repository. There won't be future packaging errors like this as I now have a checklist. Thanks for the report!

commented on 2012-11-25 15:35 (UTC)

I fixed it by installing the zfs and spl packages from AUR instead from the repository.

commented on 2012-11-25 15:16 (UTC)

I use arch-zfs and have reinstalled arch-zfs, rebooted and tried everything but I get following error when trying to load zfs: modprobe: FATAL: Module zfs not found. Something is wrong...

demizer commented on 2012-11-24 21:29 (UTC)

The packages have been updated for kernel 3.6.7. If you installed the packages from AUR, you will need to first remove the zfs and spl packages:: # pacman -Rsc spl-utils and then update the kernel:: # pacman -S linux linux-headers You will now have to restart your system. Once your system is back up, you can proceed with building and installing zfs and spl, in the following order: spl-utils, spl, zfs-utils, and zfs. Then restart, or:: # modprobe zfs spl You could also use the prebuilt signed repository available at and you will not have to remove the packages, update the kernel, and restart before performing the update. Also, these new packages now have a group, 'arch-zfs'. So next time you could remove the packages with just:: # pacman -R arch-zfs If usig the signed repository, you can now install all the packages with:: # pacman -S arch-zfs

demizer commented on 2012-11-24 10:20 (UTC)

I am aware of the new kernel update. I will update the packages first thing in the morning. Thanks!

commented on 2012-11-18 22:14 (UTC)

Although I don't use this particular PKGBUILD (I build my own), I have no problems running rc12 on my system which is ZFS throughout - root/boot and all, every filesystem is ZFS.

nhelke commented on 2012-11-16 08:32 (UTC)

@proxypoke You are not alone, I too use ZFS on root with Arch. I actually might one day write about my slightly elaborate setup which envolves having /boot also on ZFS so that when things go wrong like they did when I updated to 3.6 and ZFS stoped working, I can simple zfs rollback and everything inluding the kernel and initramfs are rolled back :) I haven't yet upgraded to rc12, but what seems to be the problem? At what point during the boot does it fail?

demizer commented on 2012-11-16 05:17 (UTC)

The build tool source code is up at I also updated the wiki to reflect the new repository. My next cause is to start looking into systemd support and then DKMS.

proxypoke commented on 2012-11-15 22:14 (UTC)

I will have to add a warning to my earlier enthusiasm: rc12 doesn't seem to be useable as a root fs - or at least not as far as I have tried. Since I somewhat doubt that there are a lot of (if any) people besides me who try to run Arch on ZFS, so this shouldn't be too important. Just thought I 'd mention it.

senorsmile commented on 2012-11-15 16:00 (UTC)

I think you should add your repository information to the wiki. It would be helpful for newcomers to ZFS without having to search through this page's comments.

demizer commented on 2012-11-15 08:17 (UTC)

@proxypoke, thanks for the notification! The packages have been updated to 0.6.0-rc12. I have been working creating a unofficial repository for the Arch ZFS kernel modules. The database and packages are signed with my PGP key, see for more info and instructions on how to add my repository to pacman and add my key (0EE7A125) to your keyring trust. My signed repository and packages are pre-built _x86_64 packages. See for more info. The github master branch for the build tool is not yet up to date. I will have that up and ready sometime tomorrow. cheers

proxypoke commented on 2012-11-15 03:06 (UTC)

Good news, everyone! With the latest release of ZFS/SPL on Linux, 0.6.0-rc12 (available as of yesterday), everything builds completely fine on kernel 3.6.5 without the need for any patches. All PKGBUILDs (spl{,-utils}, zfs{,-utils}) require a quick :%s/rc11/rc12/, generation of new md5sums, and the preempt patch can be removed. Happy compiling!

demizer commented on 2012-10-29 15:56 (UTC)

Hey everybody, just a quick update. The new build tool I have been working on is now in master, With it you can build and package two different groups of packages one for aur and one for split. Again, building the split packages is more efficient. I still have a lot of work to be done, but it is progressing. I will be adding git, dkms, and lts packages after I setup my repo. My next step is to add unofficial repository support to my build tool so I can easily setup a repo with precompiled binaries. I will be hosting the repo on my website at Initially it will only be for 64bit code since the ZOL FAQ states that ZOL is very unstable with 32bit code due to memory management differences in Solaris and Linux. I will notify you all in the future when that is ready to go. @MilanKnizek, Yes updating is a pain. ZFS itself is hard-coded to linux versions at build time. The ZFS build tool puts the modules in "/usr/lib/modules/3.5.6-1-ARCH/addon/zfs/", and this the primary reason it has to be rebuilt each upgrade, even minor point releases. Nvidia for example puts their module in "/usr/lib/modules/extramodules-3.5-ARCH/", so minor point releases are still good and the nvidia package doesn't need to be re-installed. A possible reason for ZOL to be hard-coded like this because ZOL is still technically very beta code. I do have a question for the community, does anyone use ZFS on a 32bit system? Thanks!

stoone commented on 2012-10-29 12:09 (UTC)

If you keep the linux, and linux-headers packages while using the LTS you don't need to modify the PKGBUILDs. Because the checks will pass but it will build the packages to your current runnning kernel.

sysfu commented on 2012-10-28 04:00 (UTC)

All, if you're suffering zfs kernel upgrade pain & fatigue, seriously consider going with the LTS (long term support) kernel. I just successfully built zfs on a system that I switched to the linux-lts 3.0.48-1. All you have to do is install the linux-lts and linux-lts-headers packages, reboot to the lts kernel, and change any instances of depends= or makedepends= lines in the package build file like so: Before: depends=('linux>=3.5' "spl>=${pkgver}" "zfs-utils>=${pkgver}") makedepends=('linux-headers>=3.5') After: depends=('linux-lts>=3.0' "spl>=${pkgver}" "zfs-utils>=${pkgver}") makedepends=('linux-lts-headers>=3.0') Then build and install each package in this order: spl-utils,spl,zfs-utils,zfs. Worked like a champ for me.

commented on 2012-10-24 08:07 (UTC)

@demizer: there still seemed to be a problem during upgrading - zfs/spl requires kernel of certain version (hard-coded) and this blocks the upgrade (the old installed zfs/spl requires the old kernel and kernel can't be upgraded w/o breaking dependency of zfs/spl and therefore build of the new zfs/spl fails, too). So far, I have had to remove zpl/spl, upgrade kernel, rebuild + install spl/zfs and manually run depmod against the new kernel (i.e. the postinst: depmod -a does not work until next reboot) and only then reboot to load the new kernel & zfs modules successfully. That is quite clumsy and error-prone - I hope it will be resolved via DMKS.

demizer commented on 2012-10-24 04:11 (UTC)

@modular, You're trying to build with the 3.6.2 kernel. The current version (rc11) does not work with the 3.6.2 kernel. If you want to use it, you will have to downgrade to the 3.5.6 kernel (linux and linux-headers). Thanks!

commented on 2012-10-24 03:09 (UTC)

@demizer I don't/won't run ZFS as a root file system. I'm getting the following build error:

demizer commented on 2012-10-24 02:07 (UTC)

@modular, I don't use zfs as root, but I don't think you need to depmod and mkinitcpio every time you upgrade, i'm not 100% sure though since I don't use zfs as root. depmod is done automatically by makepkg on install. I do know for sure that on kernel upgrades (3.5.5 -> 3.5.6), you will have to rebuild and upgrade. I am working on a DKMS solution to help alleviate this and am also working on making an unofficial repository so users don't have to build themselves. Honestly at this point I would not use zfs as root because linux support is still under very heavy development. zfs is stable as a rock, but not the integration into linux. Case in point, the 3.6 kernel is released and the patches have been merged into the ZOL source tree, but the ZOL devs still have not made a release. To this end, I would say if you use zfs with anything in linux, make sure you have proper backups before updating. You just never know. As of this moment I am waiting for the next ZOL release, rc12, before I update the packages on AUR. At some point in the future I will also update the git packages in AUR, after getting permission or control from the current zfs-git package maintainer in AUR so users can easily build the latest git version if they choose.

commented on 2012-10-23 23:52 (UTC)

Isn't there a more elegant version of updating? What do you guys do? depmod, then mkinitcpio -p linux every time? Linux 3.6.2 is current in Arch, can you fix this package accordingly? Thanks!

demizer commented on 2012-10-19 07:13 (UTC)

@srf21c, I will see about adjusting the dependency versions to have a minimum for the lts kernels. I'll have to look around to see what the standard practice is for kernel packages when it comes to linux-lts. Until then, change 3.5 to 3.0 when building the packages with makepkg, or whatever you use to install packages from AUR. It should install fine. Let me know if you have any problems. @ronnylov, I just finished setting up my data server with systemd and also ran into no problems with zfs, but I also don't run zfs as root. I think the main issue with systemd and zfs is with those that run zfs as root. From what I have read, the ZOL developers that run as root, don't use systemd... yet. Of course, I would also like to get rid of the last vestiges of the old initscripts off my system, as we all probably do, but the arch devs did a great job of integrating everything and it is completely out of the way.

sysfu commented on 2012-10-19 01:12 (UTC)

I'd like to build this package on a system running the linux-lts 3.0.46 kernel. It seems that the spl dependency requires linux-headers>=3.5. According to supported Linux kernel range is 2.6.26 - 3.5. Are there any workarounds you are aware of to get zfs running with linux-lts?

commented on 2012-10-18 22:30 (UTC)

@mikers and @demizer: Regarding systemd I can say that "A mixed systemd/initscripts installation" according to the systemd wiki with zfs being the only daemon listed in rc.conf works for me. But I do not use ZFS on the root file system. So there is no need to avoid systemd.

demizer commented on 2012-10-16 07:06 (UTC)

I have flagged all of the packages out of date due to the 3.6 kernel in core. The spl package does not currently build with the 3.6 kernel and the api updates to allow it to build will not land until rc12 which should come in the next few weeks. Until then I recommend staying with 3.5 kernel until rc12 is released. Thanks!

demizer commented on 2012-10-13 17:29 (UTC)

@mikers, thanks for the tip. Now i'm not sure when systemd support will be implemented. I myself don't know enough about the internals of systemd (or zfs for that matter) to implement the support myself, and have zero time to really dig deep. Looks like my desktop will not be systemd for a while.

chungy commented on 2012-10-09 19:22 (UTC)

There is already a ticket for systemd support upstream: Nothing complete has been done; there is a large disinterest among the developers towards supporting it. Not that it's impossible (nor are they against it), it's just difficult and apparently none of them use systemd themselves.

demizer commented on 2012-10-09 18:50 (UTC)

@srf21c, currently you have to rebuild the package manually on kernel upgrades. I am working on DKMS packages to allow this step to be done automatically. @maattd, The rc.d file is supported upstream by the zfsonlinux developers. I will have to get in touch with them to figure out systemd support.

maattd commented on 2012-10-09 16:45 (UTC)

Hi, Thanks for this package. However they seem to provide a rc.d file but no systemd service ?

sysfu commented on 2012-10-08 18:20 (UTC)

zfs install broken by recent upgrade to 3.5.6-1-ARCH kernel on x64. Removing and re-installing via yaourt resolved the issue.

demizer commented on 2012-10-06 06:54 (UTC)

If anyone is interested in the new build tool, you can track the progress here:

demizer commented on 2012-10-06 06:52 (UTC)

@ronnylov, Yes that is the way I perform kernel updates as well and it is not effective. That's why I am working on a new build script. I want to create a couple DKMS packages so I don't have to do the rebuilding manually. Unfortunately, this would mean that I would have to maintain 8 separate PKGBUILDS for spl, spl-utils, zfs, and zfs-utils packages. The new build tool I am working on will allow me to only have to edit one file and then I can build and test all the packages at once.

commented on 2012-10-05 10:01 (UTC)

Thanks demizer! I have been wondering how to perform kernel upgrades if running ZFS on root (maybe this could be described in the wiki). The only way I found to perform kernel upgrades was to first uninstall zfs and spl, upgrade kernel, reboot, recompile and install spl and zfs again but if root is on zfs then I don't understand how to boot without zfs. Maybe that's why we need the DKMS packages?

demizer commented on 2012-10-05 02:34 (UTC)

@ronnylov, I saw that and agree that I don't really think it is necessary... but I was afraid of breaking something someone needed as I just picked up this package from the previous maintainer. When creating the new patch, the difference was only about three to four lines so I kept it. After I complete the new build tool I am working on, as well as create DKMS packages, I will try removing the patch and see if it breaks anything for anybody. Thanks!

commented on 2012-10-03 20:24 (UTC)

zfs version 0.6.0 rc11 includes support for preemptible kernels. So I wonder if the zfs_preempt.patch really is necessary in this PKGBUILD? Release notes:!topic/zfs-announce/zIcg68ehRTA

demizer commented on 2012-09-20 04:52 (UTC)

Ok guys hopefully the bugs are fixed. Once again the split package is located here:

demizer commented on 2012-09-19 16:15 (UTC)

Hey guys sorry about the bugs. I am working on it and it should be uploaded by 1pm PST. Thanks!

Roberth commented on 2012-09-19 10:43 (UTC)

Sorry my bad I had installe spl and spl in right version, same with zfs-utils, but this package I had just reinstalled rc10 lol...

Roberth commented on 2012-09-19 10:24 (UTC)

I am using linux-ck by the way.

Roberth commented on 2012-09-19 10:23 (UTC)

After I installe rc11, I can't start zfs [root@R2D2 roberth]# /etc/rc.d/zfs start :: Starting zfs [BUSY] ERROR: could not insert 'zfs': Invalid argument [FAIL]

KuchenKerze commented on 2012-09-19 07:43 (UTC)

There is an error in the pkgbuild: /tmp/yaourt-tmp-root/aur-zfs/./PKGBUILD: Line 26: cd: /tmp/yaourt-tmp-root/aur-zfs/src/zfs-0.6.011: No such file or directory Needs to be zfs-0.6.0-rc11

commented on 2012-09-19 06:42 (UTC)

Why are you using configure --prefix=/ and not --prefix=/usr ? This breaks a numbers of things such as the zfs hook which looks for /usr/sbin/zpool not /sbin/zpool

demizer commented on 2012-09-19 04:09 (UTC)

Hey guys and gals. I have updated the packages to the latest release. Let me know if you encounter problems. I have also created a split package to make installing faster and easier, but unfortunately AUR does not support split packages. However, you can get it here if you like

commented on 2012-09-17 22:58 (UTC)

Tried to compile on 32 bit machine and got this error 64 bit works like a charm

demizer commented on 2012-09-05 00:40 (UTC)

@mikers I totally missed that thanks.

chungy commented on 2012-09-04 17:24 (UTC)

pkgrel for official maintainer builds should always start at 1 and increment by whole integers. The reason I had used 0 previously was in order to get a clean upgrade when this package gets updated. (My personal convention when I need further changes on my own are to increment by .1; eg, 0.1 or 1.1, then when the package in AUR gets updated hopefully pkgrel will be bigger than the minor point value I gave it)

commented on 2012-09-03 21:26 (UTC)

Thanks demizer for updating this package and thank you all others for helping out too :-)

demizer commented on 2012-09-02 23:57 (UTC)

Thanks goes to kylef for giving me ownership of the package. He didn't have access to his machines to perform the updates. I have updated the package.

demizer commented on 2012-09-02 23:20 (UTC)

Here is a link to the package I put together: sorry about that.

Roberth commented on 2012-09-02 22:17 (UTC)

Can someone please post a patch which works with rc10?

demizer commented on 2012-09-01 01:39 (UTC)

Here are the updated PKGBUILDS for 3.5.3 kernel. Not sure about stability yet though... You will need to rebuild spl and zfs for the new kernel, with spl being rebuilt and installed first. spl: zfs: Devoted: The patch is located in the tarball link on this page.

commented on 2012-08-26 19:40 (UTC)

I have recently migrated to systemd (mixed w/ legacy rc.conf) and while checking the boot performance I found that loading the zfs module takes about 8 seconds (intel i7-2600K). Pretty long... If zfs is not explicitely included in modules to be loaded (either rc.conf or modules-autoload.d) at startup and one relies on "/etc/rc.d/zfs start" to modprobe it, then it fails due to missing /dev/zfs. Having "modprobe zfs" in the rc.d script does not help, the script continues w/o waiting for the module to be actually loaded and usable. At least within systemd... An extra while loop in the rc.d script to check for /dev/zfs existence might be helpful. (I cannot confirm how it behaves w/o systemd.) EDIT: Adding udevadm settle --exit-if-exists=/dev/zfs to the rc.d/zfs might be a cleaner solution.

commented on 2012-08-26 18:07 (UTC)

I have recently migrated to systemd (mixed w/ legacy rc.conf) and while checking the boot performance I found that loading the zfs module takes about 8 seconds (intel i7-2600K). Pretty long... If zfs is not explicitely included in modules to be loaded (either rc.conf or modules-autoload.d) at startup and one relies on "/etc/rc.d/zfs start" to modprobe it, then it fails due to missing /dev/zfs. Having "modprobe zfs" in the rc.d script does not help, the script continues w/o waiting for the module to be actually loaded and usable. At least within systemd... An extra while loop in the rc.d script to check for /dev/zfs existence might be helpful. (I cannot confirm how it behaves w/o systemd.)

chungy commented on 2012-08-25 21:31 (UTC)

Devoted: he was basing on my package, see the dropbox link.

commented on 2012-08-25 21:21 (UTC)

Hi demizer, I have tried editing the PKGBUILD and using yours instead. Unfortunately it comes back with this: ==> Validating source files with md5sums... zfs-0.6.0-rc10.tar.gz ... Passed preempt.patch ... FAILED ==> ERROR: One or more files did not pass the validity check! ==> ERROR: Makepkg was unable to build zfs. ==> Restart building zfs ? [y/N] Why does it do this how how do I validate the preempt.patch? Thanks!

chungy commented on 2012-08-21 03:17 (UTC)

It might also be good to have both zfs and spl via DKMS, but probably as separate packages from this one.

demizer commented on 2012-08-20 09:41 (UTC)

Hi guys. I am curious. Is there a reason for not using ">=" when specifying the dependency version? I am having to uninstall zfs to update the dependencies, or to the latest kernel version (3.4.8 to 3.4.9) and this is because the dependency versions are hard coded. I just rebuilt all the packages manually changing the dependencies to use ">=" and so far so good, no problems. Also, according to the Arch Packaging Guidelines (, using custom variables can break AUR parsing of PKGBUILDS, which is shown on this page in the dependencies list. I recommend removing the cute bash escape statement and just using a good old string. Here is the update zfs package I made Thanks!

chungy commented on 2012-08-19 11:36 (UTC)

I don't know if this package was forgotton about or what, but i made a temporary package for myself with rc10:

commented on 2012-08-15 01:13 (UTC)

@kylef: Nice! You're pretty fast! I just built myself a custom kernel which includes zfs and spl (=built in). It would be cool if you would write a PKGBUILD that uses arch' kernel and adds spl and zfs to it :-) :

kylef commented on 2012-08-15 01:10 (UTC)

rc10 is out, I will update zfs and spl packages tomorrow.

demizer commented on 2012-08-13 01:21 (UTC)

FYI: There is now a ZFS wiki page at

commented on 2012-08-03 19:32 (UTC)

@kylef: Unfortunately it doesn't work with the new PKGBUILD either. Mkinitcpio still can't find zfs' and spl's modules. I'm currently on 3.5.0-1, upgraded to 3.5.0-2 via pacman and then built the new packages. I removed all previous versions of zfs/spl. I can't boot into the new kernel because i'm using a zfs root. I'll rollback to 3.5.0-1 and wait till this issue is fixed. Thanks anyway! :-) ; @all-testing-users: I updated my edited version of kylef's PKGBUILD, which includes the required patch for the 3.5x kernel :

kylef commented on 2012-08-02 01:29 (UTC)

I have changed this package, splitting it into a separate -utils package like suggested by archlinux. The new packages will depend on the current installed linux kernel, so this should solve issues with different kernel versions.

commented on 2012-08-01 05:30 (UTC)

@schreiberstein: Your problems seems that modules is compiled for wrong kernel. I think that after kernel upgrade you should manually add directives for configure in PKGBUILDs to point it to new kernel directory.

commented on 2012-07-31 23:07 (UTC)

I have this problem : This happened to me last time when I tried to upgrade from kernel 3.4.something to 3.4.something. Now I have the same problem with 3.5.0-1 to 3.5.0-2. (I rebuild ZFS + SPL in a clean x86_64 testing chroot.) This is quite annoying :-/ @kylef: could you please add a package for the testing kernel to your repo? Would be awesome :-)

proxypoke commented on 2012-07-26 21:30 (UTC)

I haven't exactly solved my problem (still can't get the module to generate, and I seriously can't figure out why), but I could build it just fine from a live system and install the resulting package into a chroot, which worked just fine. I'll still try to get to the bottom of this, but it's one hell of a weird problem. Probably an elusive loch ness monster bug. :) Thanks for your help and efforts.

commented on 2012-07-25 16:01 (UTC)

Doesn't build on kernel 3.5 (Testing) anymore : Fortunately I found a patch over there :!topic/zfs-discuss/FAve5Prwvo4 --> My overworked PKGBUILD : schreiberstein @kylef: Thanks for your work! :-)

kylef commented on 2012-07-23 22:59 (UTC)

I have updated this package for full /usr/lib support, this includes moving the zfs.ko to the new locations. You can find a full diff at There are also x86_64 binary packages available. This is on my repo "ark" # /etc/pacman.conf [ark] SigLevel = Required Server =$arch/ Note, you will need to add my GPG key (E1650558) pacman-key -r E1650558 pacman-key --lsign-key E1650558 @proxypoke, could you try again with the latest changes.

proxypoke commented on 2012-07-19 19:19 (UTC)

The problem isn't that I can't compile it, it's that I can compile it just fine, but it won't generate the zfs.ko module. I have no idea why. I tried explicitly configuring with --with-config=all, but to no avail. As soon as I have time and access to a live boot medium (probably tomorrow), I will try some other things, but right now I just need my laptop. I suspect that I am missing something entirely obvious.

commented on 2012-07-19 18:28 (UTC)

If your laptop is running, then why you can not make zfs now? What problem you have?

proxypoke commented on 2012-07-19 17:39 (UTC)

That's nice to know, though I will probably use the same approach as when I installed my laptop (installing ZFS in the tmpfs, then bootstrap/chroot). Also, as of right now, the laptop is still running, I just can't *re*boot. ;)

commented on 2012-07-19 16:47 (UTC)

You can try to use Gentoo 12.1 LiveDVD - they have zfs on it.

proxypoke commented on 2012-07-19 14:24 (UTC)

I'm currently having a slight problem: the zfs.ko module is missing, and I can't get ZFS to compile it. This means I can't generate an initramfs, which is sort of a big deal for me because my system runs on ZFS, and without zfs.ko in the initramfs, I can't boot. I suspect this is also related to the /usr/lib move, maybe in conjunction with the kernel update (I'm building against 3.4.5-1). Any ideas?

commented on 2012-07-17 15:57 (UTC)

Made new patch, considering /lib -> /usr/lib move: Also /usr/libexec/zfs is now /usr/lib/zfs. One issue with /lib still remains - spl & zfs installs modules into /lib/modules/... Do not know now how to fix this.

commented on 2012-07-17 10:38 (UTC)

> The cd ../../ line is missing and leads to the failed stat call. This is not because of glibc! This is because error in PKGBIULD, I think. And it is better change to this instead of "cd ../../": install -D -m644 $srcdir/zfs.initcpio.hook "$pkgdir"/lib/initcpio/hooks/zfs install -D -m644 $srcdir/zfs.initcpio.install "$pkgdir"/lib/initcpio/install/zfs I have posted this already.

commented on 2012-07-17 07:58 (UTC)

After upgrading glibc and using the new /usr/lib scheme, installing ifs complains: "install: cannot stat ‘zfs.initcpio.hook’: No such file or directory". SOLUTION: Change the PKGBUILD's package() from: package() { cd "$srcdir/$pkgname-${pkgver//_/-}" make DESTDIR="$pkgdir" install install -D -m644 zfs.initcpio.hook "$pkgdir"/lib/initcpio/hooks/zfs install -D -m644 zfs.initcpio.install "$pkgdir"/lib/initcpio/install/zfs } to: package() { cd "$srcdir/$pkgname-${pkgver//_/-}" make DESTDIR="$pkgdir" install cd ../../ install -D -m644 zfs.initcpio.hook "$pkgdir"/lib/initcpio/hooks/zfs install -D -m644 zfs.initcpio.install "$pkgdir"/lib/initcpio/install/zfs } The cd ../../ line is missing and leads to the failed stat call.

commented on 2012-07-14 23:39 (UTC)

After upgrading glibc and using the new /usr/lib scheme, installing ifs complains: "install: cannot stat ‘zfs.initcpio.hook’: No such file or directory".

chneukirchen commented on 2012-07-14 21:28 (UTC)

/usr/libexec should not be used in Arch.

commented on 2012-07-11 06:12 (UTC)

Thank You. I think its my fault with bad copy-pasting. Maybe I have done it from "less" output. BTW for them who interested. Here is issue I have opened about bad configure: May be somebody will want to comment too. I have wrote email now asking to review it.

proxypoke commented on 2012-07-11 02:15 (UTC)

For anyone using green's patch: it has spaces instead of tabs in the section, which causes it to fail to apply. I suspect this is an issue with pastebin, so I took the liberty of reposting it as a gist with corrected tabs (link to the raw, wget-able):

commented on 2012-06-30 20:24 (UTC)

I have to make this changes to make it work properly: Summary: 1) Patch, to handle all *.in files - this is upstream bug, I have already submited it. Because of this uder rules files were not updated witch correct pathes to binaries. 2) Fix udev dir from /usr/lib/udev to /lib/udev. 3) Fix installs of zfs.initcpio.* 4) Fix mount.zfs location in zfs.initcpio.install

codekoala commented on 2012-06-26 15:57 (UTC)

It might be useful to set the spl dependency to use >= instead of =. I had a cyclic dependency problem for quite a while before I decided to put effort into fixing it. When I would try to install the updated spl package that the updated zfs wanted, it would complain that zfs wanted the prior version (because that package had the "spl=" dependency). I had to uninstall both packages and then reinstall zfs, but this time I set it to use spl>=... :D

commented on 2012-06-24 23:48 (UTC)

I've included it and additional improvements in my patch :)

commented on 2012-06-24 13:03 (UTC)

There is a mistake in PKGBUILD in package(): install -D -m644 zfs.initcpio.hook "$pkgdir"/lib/initcpio/hooks/zfs install -D -m644 zfs.initcpio.install "$pkgdir"/lib/initcpio/install/zfs need to be install -D -m644 "$srcdir"/zfs.initcpio.hook "$pkgdir"/lib/initcpio/hooks/zfs install -D -m644 "$srcdir"/zfs.initcpio.install "$pkgdir"/lib/initcpio/install/zfs

commented on 2012-06-24 00:54 (UTC)

I worked on a few of your files. I updated the locations of where the udev rules are and other bins, added your name and mine to the top of the PKGBUILD, worked on the functions in zfs.initcpio.hook so it's much cleaner now when booting, and a few other things.

commented on 2012-06-19 05:51 (UTC)

Here is the patch for zfs-rc9 (preempt.patch)

chenxiaolong commented on 2011-12-15 01:29 (UTC)

@surya1: You're welcome! This will be one of the first packages to integrate with the Arch Linux package management system upstream :)

commented on 2011-12-15 00:52 (UTC)

@chenxiaolong: Awesome! I just spoke with Brian, and the patches should land on master today. Feel free to open tickets on the projects' GitHub issue tracker about any problems or improvements. Thanks for trying them out!

chenxiaolong commented on 2011-12-13 05:17 (UTC)

@surya1: The packages work great! :)

chenxiaolong commented on 2011-12-09 22:18 (UTC)

@surya1: Actually, if you use DKMS, you won't have any of these problems, since DKMS compiles the kernel module after booting an updated kernel or a different kernel. I currently have a package that's using a very simple DKMS configuration. Maybe it can help you:

chenxiaolong commented on 2011-12-09 22:14 (UTC)

@surya: No problem :) About the build dependencies. Unfortunately, there's no easy way to do this. Since Arch allows multiple kernels to be installed, a pseudopackage cannot be used, since 2 packages can't both provide 'linux-headers-pseudo,' for example. The correct way would be to have a dependency on a 'linux-headers,' but then we have the problem of spl and zfs not compiling, since they require a kernel built with 'CONFIG_PREEMPT=y.' As far as I know, that option is disabled in Arch's default kernel. RPM and Debian package management systems support conditional dependencies, so the following would be valid: Dependencies: ... "linux-headers || kernel26-headers || kernel26-lts-headers" ... Unfortunately, this isn't something that pacman/makepkg supports, yet :( The best thing I can come up with is to find the package name of the current kernel and append '-headers' to it. For example: pkgname=zfs pkgver=REPLACE_ME pkgrel=1 desc='...' arch=('i686' 'x86_64' ... _kernel_pkgname="$(pacman -Qo /usr/src/linux-`uname -r`/vmlinux`)-headers" makedepends=(... "${_kernel_pkgname}" ...) That should work, assuming that the user doesn't constantly switch kernels.

commented on 2011-12-09 21:13 (UTC)

@chenxaiolong: Thanks! Currently, the only concern I have with the PKGBUILD's I am proposing are the depends and makedepends arrays. I know those are incorrect at the moment, although I'm not sure what the correct values should be. e.g. to build the spl, kernel headers need to be installed, does that mean makedepends needs 'linux-headers', 'kernel26-headers', or 'kernel26-lts-headers'? Is there a psuedo package I can use which will do the right thing based on the kernel version installed? Also, I have created an SPL issue on it's github page: It would be great if you could post your results there, and we can use that as a forum to continue this discussion and get a proper solution for Arch pushed upstream. Thanks for trying it out! :)

chenxiaolong commented on 2011-12-09 18:18 (UTC)

@surya1: That's awesome! It's nice to see some Arch packaging in the upstream source code. I'll compile a preemptive kernel and test out your changes later on today :)

commented on 2011-12-09 17:53 (UTC)

Hi, I'm working on getting a set of patches upstream to the spl and zfs projects which would allow one to 'make arch' to build Arch Linux packages. This would allow an Arch Linux VM to be easily integrated into the ZFS Build Bot automated testing infrastructure just as is done for many other distributions. I wanted to run these patches by the community in hopes that you all could give me some feedback, here's a link to the spl and zfs branches with the PKGBUILD patches: SPL: ZFS: Thanks!

fsk141 commented on 2011-11-02 23:21 (UTC)

FYI: Must make a couple changed to kernel before this will work: checking whether Linux was built with CONFIG_PREEMPT... yes << need to do these things.

chenxiaolong commented on 2011-10-18 18:23 (UTC)

Please change the configure line to contain "--libexecdir=/usr/lib/zfs". The /usr/libexec directory is only used by Red Hat/Fedora and its derivatives. Here's the modified PKGBUILD:

kylef commented on 2011-09-09 21:06 (UTC)

@therp, that patch has some issues, the udev scripts reference /bin/bash which is not on the initcpio image. There is a more complete patch at Which I am waiting for behlendorf to decide what to do with. (Since I include a patch to make z(fs|pool) work without an mtab. (See )

therp commented on 2011-09-09 19:42 (UTC)

FYI has a patch with initcpio hooks for root on ZFS. Sorry it's diffed against zfs-behlendorf-git, but the two files should be easy to fish out.

cybertorture commented on 2011-08-03 01:22 (UTC)

I got issue with zfs.cache, after a while wondering + google i just created /etc/zfs folder and after recreating zpool everiting is fine now

commented on 2011-07-25 08:06 (UTC)

@kylef: Tried it, but the Installer will install the rc.d script into the /etc/init.d/ directory.

kylef commented on 2011-07-22 11:28 (UTC)

@PhlowX, if you do `./configure --prefix=/usr --sysconfdir=/etc` the installer will install the rc.d script, and some config files into etc. Currently they are being installed to /usr/etc as the prefix installs them there.

commented on 2011-07-22 06:10 (UTC)

Added rc.d script, thanks kylef :-)

kylef commented on 2011-07-18 17:11 (UTC)

Btw, I have written a rc.d script for ifs, it is included in zfs-0.6.0-rc5. This will mount and share all your pools on boot if you add it to your DAEMONS.

commented on 2011-03-22 21:41 (UTC)

any news for new version ?

commented on 2010-10-22 05:38 (UTC)

Added makedep: kernel26-headers

commented on 2010-10-21 08:39 (UTC)

@L0cutus: Nope, see zfsonlinux FAQ, 1.3:

commented on 2010-10-21 07:31 (UTC)

is this zfs version ready for every day usage ?!? same capabilities as zfs-fuse ?

commented on 2010-10-21 05:49 (UTC)

@axlrose: done!

axlrose commented on 2010-10-21 05:20 (UTC)

can you add somethime? 1. add support i686 2. add install file , depmod -a # arg 1: the new package version post_xxxxx() { <<< install , upgraded, remove >>> depmod -a > /dev/null 2>&1 }