Package Details: zfs-utils 2.2.7-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: 70
Popularity: 4.02
First Submitted: 2018-10-28 22:49 (UTC)
Last Updated: 2024-12-13 11:25 (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 8 .. 13 Next › Last »

dhathaway commented on 2023-11-15 16:07 (UTC)

Hello,

I posted this in zfs-dkms, but it seems this is a zfs-utils issue. I was told libzfs is owned by zfs-utils.

I froze my kernal at 6.4.12-arch1-1 and had zfs 2.2.0 running since it came out.

Yesterday, my power went out, and when the machine came back on, my zfs pool wasn't mounted. I used:

sudo zpool import -a -d (etc)

I receive:

Failed to initialize the libzfs library

I get the same error with zfs set.

I rebuilt the zfs-dkms and zfs-utils packages and reinstalled, with the same result.

What is the solution?

ed209 commented on 2023-10-18 02:54 (UTC)

The PKGBUILD uses --libexecdir=/usr/lib/zfs which leads to files installed in the directory /usr/lib/zfs/zfs instead of /usr/lib/zfs. This can be avoided by using --libexecdir=/usr/lib, which is also what archzfs.com does.

libexecdir is only used to set zfsexecdir to ${libexecdir}/zfs. I couldn't find any other uses in the source code.

kstolp commented on 2023-09-28 13:42 (UTC)

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

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.

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