Arch Linux User Repository

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.

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

@gromit Yes, I am aware. I noticed it immediately after I pushed, so it was too late.

Hey @kstolp, you forgot to reset pkgrel to 1 for this release :) https://wiki.archlinux.org/title/PKGBUILD#pkgrel

I just noticed because I had already updated the package locally ^^

FAILED (unknown public key 0AB9E991C6AF658B)

I was confounded by being confronted by the error message above and the community's lack of guidance beyond "RTFM". I'll share what I learned in the hope that it saves some newbie some time.

makepkg uses PGP keys to validate the packages. Makepkg does NOT use the system PGP keyring at /etc/pacman.d/gnupg/pubring.gpg , so do not include that in your user keyring. And do not execute pacman-key as some online solutions have suggested .

• This package's PKGBUILD references a few keys in a validpgpkeys statement, one of which was for Tony Hutter.
• I went to OpenZFS's "Signing Keys" page and saw a link to Tony's PGP key (with a fingerprint of 4F3B A9AB 6D1F 8D68 3DC2 DFB5 6AD8 60EE D459 8027).
• Per a blog post by Allan McRae, I ran gpg --recv-key 6AD860EED4598027 to get his key from a keyserver.
• I ran gpg --list-keys to view the fingerprint of the newly acquired key. I compared the imported key's fingerprint (second line in the "pub" section) to the one posted on the OpenZFS website. They matched.
• I did NOT have to run gpg --lsign KEY_ID to trust the imported key, as Allan's blog post suggested. I just ran gpg --recv-key and checked the fingerprint. Your mileage may vary.
• makepkg -si then succeeded.

Thanks @FrederickZh and @mabod.

I've just added that file to fix the permissions issue. It also looks like they may be fixing it on the systemd side as well.

Anyone who is interested can follow these two issues:

• zfs issue
• systemd issue

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