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.
Git Clone URL: | https://aur.archlinux.org/zfs-utils.git (read-only, click to copy) |
---|---|
Package Base: | zfs-utils |
Description: | Userspace utilities for the Zettabyte File System. |
Upstream URL: | https://zfsonlinux.org/ |
Licenses: | CDDL |
Submitter: | eschwartz |
Maintainer: | kstolp |
Last Packager: | kstolp |
Votes: | 74 |
Popularity: | 3.14 |
First Submitted: | 2018-10-28 22:49 (UTC) |
Last Updated: | 2025-03-11 07:23 (UTC) |
« First ‹ Previous 1 .. 4 5 6 7 8 9 10 11 12 13 Next › Last »
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.
@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.
==> Verifying source file signatures with gpg... zfs-2.0.0.tar.gz ... FAILED (unknown public key 0AB9E991C6AF658B)
==> ERROR: One or more PGP signatures could not be verified!
==> ERROR: Could not download sources.
This package requires "core/which" to support the dracut module check. @eschwartz can you add it, please?
zfs and zfs-utils are running here on Raspberry Pi 4 (4GB) (aarch64) without any issues. To build it, just replace PKGBUILD line:
arch=("i686" "x86_64")
with
arch=("i686" "x86_64" "aarch64")
Normally segfaults using gcc
occur either if the compiler has some weird bug, or if you don't have enough RAM. I didn't think it could be the RAM, because I had 64G installed in my system. After trying 6-7 times to brute-force it (if it throws an error just try compiling again), it finally succeeded in compiling. Turns out one stick of RAM was faulty. So I would advise you that upon receiving a similar error, you try brute-forcing it a couple of times and double-checking with a memtest
, just for good measure. Shoutout to the #archlinux IRC for the help.
Unfortunately, this package doesn't compile for me. In the directory zfs-utils/src/zfs-0.8.4/lib/libzpool
, the compiler throws the following error:
/bin/sh: line 2: 68193 Segmentation fault (core dumped) /bin/sh ../../libtool --silent --tag=C
b/libspl/include -D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_LAR
run\" -DSBINDIR=\"/usr/bin\" -DSYSCONFDIR=\"/etc\" -UDEBUG -DNDEBUG -D_FORTIFY_SOURCE=2 -std=gnu99
-Wframe-larger-than=4096 -DLIB_ZPOOL_BUILD -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -MT lsta
make[3]: *** [Makefile:1216: lstate.lo] Error 139
I'm currently on the 5.7.12-zen1-1
kernel. I've also tried with the 5.7.12-arch1-1
kernel, just for good measure, but even after re-cloning, the compiler still throws the same error.
Regarding the big picture, I'm trying to build the zfs-dkms
package from the AUR
, where zfs-utils
is logically a dependency.
makepkg --ignorearch would allow it to be built on unsupported architectures. However, previous comments indicated that would not even work because of e.g. configure: error: cannot guess build type; you must specify one
.
https://aur.archlinux.org/packages/zfs-utils/?PP=250#comment-711967
Thank you for your contributions Eli. Submitted a PR on github to add armv7h to the supported arch, I have tested this on arch for raspberry pi 4 and have a clean compile. Light manual testing has shown no issues so far.
This is a necessary dependency to add zfs-dkms to arch on rpi 4. Note that other distros (Ubuntu aarch64) support zfs-utils.
I have not tested on a aarch64 kernel for the RPi4.
Pinned Comments
eschwartz commented on 2020-12-27 22:43 (UTC)
@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.
eschwartz commented on 2019-10-16 03:49 (UTC)
aarch64 is not an officially supported architecture for this PKGBUILD, since I don't exactly test it on such architectures. It failing to work is therefore not very surprising.
I guess you can do any necessary followup in that upstream bug report, hopefully upstream can get it into a state of "working out of the box" so that makepkg --ignorearch works. But I'm not investing any of my own time in this...