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

Is this repo still maintained?

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

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

But as it happens, upstream removed the check from git master: https://github.com/openzfs/zfs/commit/a27ab6d43b5f62db5d9093702a69b933fb5f4515

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

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

Thanks!

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