| 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: | 75 |
| Popularity: | 1.92 |
| First Submitted: | 2018-10-28 22:49 (UTC) |
| Last Updated: | 2025-05-03 09:40 (UTC) |
@mabod I didn't test rolling back systemd alone (I did a full root dataset rollback), but I can confirm creating the zfs-node-permission.conf file fixed the issue.
@kstolp Can we please ship this file here? https://github.com/systemd/systemd/issues/28653#issuecomment-1663835960
@FrederickZh: This seems to be an issue with the latest systemd upgrade to 254-1. Downgrading to 253.7-1 fixes the issue. I did a "downgrade systemd-libs systemd lib32-systemd systemd-resolvconf systemd-sysvcompat" all to previous version 253.7-1 and that fixes it. Can you confirm? Please see also openzfs issue https://github.com/openzfs/zfs/issues/15146
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.
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...