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

Thanks for looking @kstolp, sorry for not providing enough info. And thanks to @mabod for confirming it. I guess you need to be running zed for these to show up, it isn't started by default I believe.

This happens because the PKGBUILD runs configure --prefix=/usr and the configure script contains localstatedir='${prefix}/var'. This eventually filters down to cmd/zed/zed.h which contains:

#define ZED_PID_FILE            RUNSTATEDIR "/zed.pid"
#define ZED_STATE_FILE          RUNSTATEDIR "/zed.state"

I checked this. And, indeed, I found the same. Two files in /usr/var/run: zed.pid and zed.pstate. With --localstatedir=/var added to the configure command the files are now in /var/run, where they should be.

EDIT: I checked the configure script. It has a default definition for localstatedir:

localstatedir='${prefix}/var'

and prefix is /usr. That could be the cuplrit. But then, everybody should be affected.

Hello @delx

I'm not seeing this on any of my systems. Could you include more details? (e.g. What files are there? What are their modification and birth times? etc.) Also, can you explain how they got there from this package?

If anyone else is seeing something similar on their system, feel free to chime in.

Thanks!

Hi there @kstolp, thanks for the updates to the package.

A while back I was browsing my file system and was surprised to see that I had files in /usr/var/run!

I've fixed this by adding --localstatedir=/var to the configure options ever since. Could you add this to the PKGBUILD too?

Thanks.

Updated zfs-utils and zfs-dkms, and included the patch to resolve this issue related to send/receive.

@mabod Thanks for letting me know. I'll review these and see about getting them added.

@jstrom Thanks for the feedback!

Regarding the source of the changes: Yes, they are from the archzfs project. I noticed that our zfs.initcpio.hook and zfs.initcpio.install files were both identical to the ones from that project at a certain point in time. It looks like the original attribution was done via a git commit message. I mistakenly forgot this time, but will continue with that for future changes pulled in from the archzfs project.

When I pulled in the changes, I reviewed each of the commits from the git blame for each of the lines. The commit where archzfs removed hostid handling mentioned that hostid handling is not needed anymore. Upon further review, the linked issues to the openzfs project do not support this claim. I wish I had noticed the previous commit you mentioned, but will be more discerning when pulling in future changes. Thanks for catching that! I'll go ahead and re-added hostid handling in zfs.initcpio.install.

PR14304 has been approved and merged: https://github.com/openzfs/zfs/pull/14304 It is worthwhile to add this to the 2.1.7 packages. It fixes the send/receive issue 14252: https://github.com/openzfs/zfs/issues/14252

And by the way: zfs send/receive also has an issue with compiler optimization for march=znver3: https://github.com/archzfs/archzfs/issues/456 The developers are working on a fix. The workaround is to use the compiler flag "-fno-tree-vectorize". I suggest to add this flag to zfs-dksm/zfs-utils. It does not hurt and it saves all those who use an optimized znver3 kernel. gentoo and alpinelinux did this already.

@kstolp Thanks for taking on the package, and for incorporating the encryption features, finally! Will now close https://github.com/eli-schwartz/pkgbuilds/issues/30

One thing I noticed, not related to encryption though, when diffing your changes towards previous zfs.initcpio.install was this:

-    [[ -f /etc/hostid ]] && add_file "/etc/hostid"

While looking through the git history for that file, the commit which added it mentions this:

commit f18efa1dc42e700fcca9dd689d3093af14023cf8
Author: Eli Schwartz <eschwartz@archlinux.org>
Date:   Mon Mar 4 16:59:44 2019 -0500

    upgpkg: zfs-utils 0.7.13-1

    upstream release

    Restore hostid handling erroneously removed long ago by archzfs -- not
    enforcing its use by default is reasonable, ignoring it when it is
    present and explicitly desired by the user, is not reasonable.

In my case it doesn't matter, I don't have that file, but was there a valid reason for removing it (again)?

Also, for future commits, it might be nice to include where the changes comes from, mainly for traceability but also for giving credits to other contributors I guess (archzfs in this case, which isn't really explicitly said anywhere). For example, zfs-utils.initcpio.hook in current master (97f20df49429) is a copy of https://raw.githubusercontent.com/archzfs/archzfs/be2470f56d3d6c5092caf2a28db67046cc4a5700/src/zfs-utils/zfs-utils.initcpio.hook

Thanks again!

@steved & @mabod - Both your requests have been implemented.