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

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

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

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

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

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

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

hseara,

I refuse to refrain from opinions!

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

https://wiki.archlinux.org/index.php/User:Seblu#Should_I_run_Archlinux_on_my_server.3F https://lists.archlinux.org/pipermail/arch-general/2013-July/033791.html

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

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

Kernel updates that cause zfs failures will:

• be noticeable on your staging server

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

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

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

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

@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.