Package Details: zfs-utils 2.2.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: kstolp
Last Packager: kstolp
Votes: 57
Popularity: 0.93
First Submitted: 2018-10-28 22:49 (UTC)
Last Updated: 2024-05-03 03:00 (UTC)

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

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 .. 11 Next › Last »

gromit commented on 2023-09-28 09:25 (UTC)

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

XkE5NBr2 commented on 2023-08-26 15:48 (UTC) (edited on 2023-08-26 15:52 (UTC) by XkE5NBr2) 

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.

kstolp commented on 2023-08-04 11:51 (UTC) (edited on 2023-08-04 11:57 (UTC) by kstolp)

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:

FrederickZh commented on 2023-08-03 14:29 (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

mabod commented on 2023-08-03 06:51 (UTC)

@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

FrederickZh commented on 2023-08-02 12:26 (UTC) (edited on 2023-08-02 13:59 (UTC) by FrederickZh)

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

kstolp commented on 2023-02-09 19:20 (UTC)

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.

delx commented on 2023-02-06 12:48 (UTC)

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"

mabod commented on 2023-02-06 06:35 (UTC) (edited on 2023-02-06 07:18 (UTC) by mabod)

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.

kstolp commented on 2023-02-05 23:58 (UTC)

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!

« First ‹ Previous 1 2 3 4 5 6 7 .. 11 Next › Last »