Arch Linux User Repository

@Win8Error,

This package doesn't support people who have failed to read the wiki page https://wiki.archlinux.org/index.php/Makepkg, or cannot interpret error messages.

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

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

@hseara Please also see https://openzfs.github.io/openzfs-docs/Getting%20Started/Arch%20Linux/index.html - OpenZFS developers have their own pacman repository which provides various flavors of ZFS modules.

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

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

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

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

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

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

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

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

zfs_decrypt_fs() {
    dataset=$1

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

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

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

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

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

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

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

and they call this function just before mounting every dataset.

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

https://aur.archlinux.org/packages/zfs-linux-lts/#comment-779700

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

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

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

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