Package Details: zfs-utils 0.8.4-1

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: eschwartz
Last Packager: eschwartz
Votes: 17
Popularity: 2.91
First Submitted: 2018-10-28 22:49
Last Updated: 2020-07-19 18:22

Pinned Comments

eschwartz commented on 2019-10-16 03:49

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

Latest Comments

1 2 3 4 Next › Last »

DustVoice commented on 2020-08-08 18:09

EDIT:

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.

Problem:

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.

eschwartz commented on 2020-07-19 18:25

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

jaybeavers commented on 2020-07-13 17:34

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.

fluke commented on 2020-07-13 07:35

zfs-utils package from https://archzfs.com/archzfs/x86_64/ has better initcpio zfs hooks. For example it has the ability to unlock encrypted volumes at boot (zfs load-key). Would it be possible to implement this here?

eschwartz commented on 2020-06-19 19:12

Can you look up what the word "arch" means in the PKGBUILD(5) man page?

No.

EDIT: I'm guessing your comment is due to the desire to have this work out of the box on ARM arches. Obviously, the difference matters, or you would not be asking! And no, I've previously had comments indicate that this package didn't build on ARM, so I don't feel comfortable listing support for something I don't test which maybe doesn't work.

dlp commented on 2020-06-19 18:59

Can the arch be changed to any to match the zfs-dkms package?

eschwartz commented on 2020-05-27 17:39

I independently figured that out and filed https://bugs.archlinux.org/task/66762 as I'm not sure whether systemd should be in clean chroot builds, but it used to be and that assumption has actually changed now.

It has ramifications for more than just the availability of the systemctl utility -- it also affects the passwd database.

So systemd needs to either be added as a makedepends, or re-added to base-devel. Since you were the one who added systemd to base-devel a few years ago, maybe you have an opinion or two to share on that bug report? :)

seblu commented on 2020-05-27 17:29

I have the same issue than @PedroHLC when building with extra-x86_64-build on my aurbot builder.

There is some hints in the build log:

checking for systemd support... no

Calling systemctl in the PKGBUILD produce the following error:

==> Starting build()...
/startdir/PKGBUILD: line 38: systemctl: command not found
==> ERROR: A failure occurred in build().

systemctl is packaged inside systemd. So you need to add systemd as a makedepends.

What about moving it on community? ;)

PedroHLC commented on 2020-05-22 00:07

@eschwartz Sorry, you were right, compared two BUILDINFO, at some point my containers removed systemd and stayed just with systemd-libs.

eschwartz commented on 2020-05-21 23:59

Well, if systemctl --version succeeds in your container environment I'm at a loss for words as to how zfs's --enable-systemd=check default could incorrectly analyze systemd as not being there:

https://github.com/openzfs/zfs/blob/fb822260b19921985a5312f7306b0ee0e30eb3b0/config/user-systemd.m4#L28-L31

As always, I have built this package and zfs-dkms using extra-x86_64-build, entered the build container using arch-nspawn, installed linux/linux-headers, and ensured that dkms install correctly builds the modules for the default kernel. Then I uploaded the resulting packages to https://wiki.archlinux.org/index.php/Unofficial_user_repositories#eschwartz

So I'm quite positive this can correctly work. You cannot argue with experimental results, and I have experimented, it did correctly work, and the results are freely available for download, right there; you may inspect the .BUILDINFO from those package tarballs and see how I've built it, with what installed packages, what makepkg.conf options, and what $PWD, try to reproduce it using makerepropkg (part of devtools) and so on.

If I had a better understanding of how your build differs from my build, then perhaps we could determine why your build failed with such disastrous results and ended up missing parts.