| 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) |
I started getting 'Permission denied the ZFS utilities must be run as root' for things like zfs list after today's binutils/systemd/openssl/gcc/etc upgrades. Rebuilding zfs-utils solved the issue. Just dropping a note here.
Edit: It started again after reboot...
Thanks @delx and @mabod for tracking this issue down! I've updated and tested, and all looks good.
For those of you who have run ZED before, it would have created /usr/var and files within that directory. If the only files within it are /usr/var/run/zed.pid and /usr/var/run/zed.state, then you can safely delete /usr/var.
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.
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...