| 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: | 56 |
| Popularity: | 0.084275 |
| First Submitted: | 2018-10-28 22:49 (UTC) |
| Last Updated: | 2024-02-23 11:27 (UTC) |
@darkbasic - thanks for your heads up. I read the github link and your post. Haven't run into any 6.8 zfs problems yet (only been a day), but I don't run Docker or Steam.
Noted on your 15931 backport. Please let me know when you believe a future PKGBUILD is good to go!
Cheers
@air-g4p Btw I highly suggest you to NOT use kernel 6.8 with zfs yet: https://github.com/openzfs/zfs/issues/15930
I've backported https://github.com/openzfs/zfs/pull/15931 in my own tree but I won't release it in a public PKGBUILD until it reaches master.
@darkbasic - Glad you are watching carefully. When we inexorably transition to the 6.9-x kernels, I would be happy to test your proposed PKGBUILD.
Please let me know when available.
Cheers
Good news: zfs-utils installed and operates correctly against the 6.8.0 linux and -zen kernels released today, 11 March!
6.8 compat patches made their way into the 2.2.3-staging branch just days before the 2.2.3 release, but it's a rare occurrence. Most likely by the time 6.9 stable gets released there won't by any support in any released version. I'd like to add official patches to the PKGBUILD to remedy that but the current maintainers are against it, so I'm going to create my own package. Stay tuned if you are interested.
Good news: zfs-utils installed and operates correctly against the 6.8.0 linux and -zen kernels released today, 11 March!
Cheers
I've just added the patch for the file corruption issue.
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?
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.
@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 .
validpgpkeys statement, one of which was for Tony Hutter.gpg --recv-key 6AD860EED4598027 to get his key from a keyserver.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.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:
@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.
@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.
@kstolp Thanks for taking on the package, and for incorporating the encryption features, finally! Will now close https://github.com/eli-schwartz/pkgbuilds/issues/30
One thing I noticed, not related to encryption though, when diffing your changes towards previous zfs.initcpio.install was this:
- [[ -f /etc/hostid ]] && add_file "/etc/hostid"
While looking through the git history for that file, the commit which added it mentions this:
commit f18efa1dc42e700fcca9dd689d3093af14023cf8
Author: Eli Schwartz <eschwartz@archlinux.org>
Date: Mon Mar 4 16:59:44 2019 -0500
upgpkg: zfs-utils 0.7.13-1
upstream release
Restore hostid handling erroneously removed long ago by archzfs -- not
enforcing its use by default is reasonable, ignoring it when it is
present and explicitly desired by the user, is not reasonable.
In my case it doesn't matter, I don't have that file, but was there a valid reason for removing it (again)?
Also, for future commits, it might be nice to include where the changes comes from, mainly for traceability but also for giving credits to other contributors I guess (archzfs in this case, which isn't really explicitly said anywhere). For example, zfs-utils.initcpio.hook in current master (97f20df49429) is a copy of https://raw.githubusercontent.com/archzfs/archzfs/be2470f56d3d6c5092caf2a28db67046cc4a5700/src/zfs-utils/zfs-utils.initcpio.hook
Thanks again!
@steved & @mabod - Both your requests have been implemented.
@kstolp:
The package overwrites /etc/zfs/zed.d/zed.rc and /etc/default/zfs
But these are config files with customizations like email address, verbosity, etc.
I suggest to add a line like
backup=( etc/zfs/zed.d/zed.rc etc/default/zfs )
to the PKGBUILD
@steved I'll check this out over the next two days. I also use an encrypted root position, so implementing that functionality would be nice.
@kstolp I submitted a pull request to eschwartz zfs-utils github repo. See. Is there a way to get it accepted?
Updated zfs-utils and zfs-dkms to 2.1.7. These are working with linux 6.1.2.arch1-1.
Note that the openzfs project has a bug related to send/receive (as discussed in comments below). Since the issue is still open and the pull request hasn't been merged, I have not included this as a patch.
Hello all,
I've just adopted these two packages (zfs-utils & zfs-dkms). I plan to get them updated right after this weekend at the latest.
Going forward, if anyone has issues/suggestions, feel free to email me or post in the comments. (My email is on my account here.) The goal will be to keep this package aligned with the upstream version. If there is a major issue upstream, I will do my best to include an approved patch. Otherwise, I'll post a warning comment here.
Hope everyone has a happy New Year!
I think that we need to update the packages or make zfs 2.1.6 DKMS compatible with the newer kernel. We have a broken zfs on all systems unless you take manual intervention. I do undestand the reluctance in updating due to the freezes but right now we have a package with broken dependencies or that doesn't work as intended without a warning. Doing manual updates to the PKGBUILD version to solve a build issue without knowing the consequences its not a good idea and we shoudn't suggest doing it.
@dmast3r1: zfs 2.1.7 has still a severe issue with send/receive which can cause a pool freeze resp. core dump: https://github.com/openzfs/zfs/issues/14252 The solution is to revert commit https://github.com/openzfs/zfs/commit/c8d2ab05e1e6bf21185723fabdebbe5bb3374381
@jonathon I updated pgkver to 2.1.7 in makepkg and built/installed as is...works perfectly.
Currently this package overwrites /etc/zfs/zed.d/zed.rc on each update.
I’ve customized the RC file to include my email address so I get notified by ZFS ZED.
I recommend adding the following to the PKGBUILD:
backup=(etc/zfs/zed.d/zed.rc)
I submitted this as a pull request to the alleged upstream mentioned in the PKGBUILD a while ago, but I guess that is derelict.
https://github.com/openzfs/zfs/pull/11468 and https://github.com/openzfs/zfs/pull/11861 added support for compatibility option files that greatly improve sharing/migrating pools between systems (or at the very least allowing that possibility) while using recent features.
The following diff installs the needed files.
diff --git a/PKGBUILD b/PKGBUILD
index 675ece6..e6c13bd 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -63,7 +63,8 @@ package() {
#rm -r "${pkgdir}"/usr/lib/dracut
rm -r "${pkgdir}"/usr/lib/modules-load.d
rm -r "${pkgdir}"/usr/share/initramfs-tools
- rm -r "${pkgdir}"/usr/share/zfs
+ rm -r "${pkgdir}"/usr/share/zfs/*.sh
+ rm -r "${pkgdir}"/usr/share/zfs/{runfiles,test-runner,zfs-tests}
install -D -m644 "${srcdir}"/zfs.initcpio.hook "${pkgdir}"/usr/lib/initcpio/hooks/zfs
install -D -m644 "${srcdir}"/zfs.initcpio.install "${pkgdir}"/usr/lib/initcpio/install/zfs
There is a bug in zfs which causes a core dump during "zfs send" when compiled with GCC 12.
Only if you alter the defaults and set march=zenver3. If you're doing this sort of thing then you're more likely to hit upstream bugs, and therefore upstream fixes are what's needed.
If the kernel parameter is set to root=zfs, the system is unbootable because the pool variable is not set in the initcpio hook. Adding ZFS_DATASET="bootfs" under line 177 of zfs.initcpio.hook fixes this issue.
There is a bug in zfs which causes a core dump during "zfs send" when compiled with GCC 12. A workaround is to force compiler flag -fno-tree-vectorize. See here: zfs issue 13605
gentoo has already added that flag to their ebuild files. I recommend to add this to zfs-utils PKGBUILD as well. I am not sure about zfs-dkms. May be this flag should be added there too as a precaution.
Can you add provides=('zfs-utils=2.1.4') to the PKGBUILD? The various zfs-linux packages require zfs-utils=2.1.4 which the pkgver 2.1.4+65.r05147319b0 doesn't satisfy.
Please update the initcpio hook to support encryption (https://github.com/eli-schwartz/pkgbuilds/issues/30). The last update cost me some time to recover my system (yes, I should have put the hook to /etc/initcpio/hooks to prevent overwriting, but it would still be nice to get encryption support out of the box).
Hi there, thanks for the package.
I was browsing my file system and was surprised to see that I had files in /usr/var/run!
I fixed this by adding --localstatedir=/var to the configure options.
Possibly consider adding "libaio" as (build) dependency. The configure script has checks for libaio.h.
Edit: Never mind. Seems like libaio is only used for test cases. Sorry for the noise.
@pizzatoole: Check out eschwartz's pinned comment beginning "This package doesn't support people who have failed to read".
I get this when trying to makepkg:
==> Verifying source file signatures with gpg...
zfs-2.1.1.tar.gz ... FAILED (unknown public key 0AB9E991C6AF658B)
==> ERROR: One or more PGP signatures could not be verified!
Edit: Thanks @wjlafrance. I've used makepkg before without signature problems, so I mistakenly thought it was a package issue. I was a little concerned at first as harmful AUR packages have existed before (albeit very uncommon). I now know this isn't the case with this version.
Looks like the repository is broken.
remote: Not Found fatal: repository 'https://aur.archlinux.org/zfs-utils.git/' not found
Would be nice if maintainer can update inticpio hook to be the same as the one in archzfs repo, as the one from this package does NOT support root volume encryption. See https://github.com/eli-schwartz/pkgbuilds/issues/30
There's a pull request open on the source repo which you can use to build 2.1.1 with https://github.com/eli-schwartz/pkgbuilds/pull/32/files
Is this repo still maintained?
Where is 2.1.1 ? zfs-linux-lts depends on zfs-utils 2.1.1 as of 2021-09-29
Use of the "which" program is an inexcusable sin, and must be replaced in source with portable command -v. No dependencies, optional or otherwise, needed.
But as it happens, upstream removed the check from git master: https://github.com/openzfs/zfs/commit/a27ab6d43b5f62db5d9093702a69b933fb5f4515
Eli, can you please add
optdepends=('which: Dracut support') to this package?
The test on line 12 otherwise causes Dracut to fail to include the zfs module in the generated initramfs. I have spent two days figuring this out.
Thanks!
@hseara
I use ZFS in production using this package. Not for root fs, as that requires really alot more dilligence in setup and usage. I plan to, using the excellent https://github.com/zbm-dev/zfsbootmenu. Right now, a small NVME boot/system drive seems easier.
Incidentally for the kernel I use https://aur.archlinux.org/pkgbase/linux-lts54/ also from AUR. Updates from upstream will be made until the end of 2025. I am using this kernel with DKMS to limit breakage from API changes happening in 5.10+. So far nothing has broken. I always keep a history of known-good kernel installation files around though, in case the current kernel breaks.
I can also recommend excluding a known-working base repository linux-lts kernel from updates through pacman.conf IgnorePkg, and through systemd-boot make sure that you can boot from it as last resort. Kind of a really last fallback, also using its -fallback ram disk. Also of note, I stopped applying intel-ucode willy nilly when they come out. Bad ucode from Intel trying to fix the next 0day in their CPUs really caught me by surprise. It is my impression that ZFS is more demanding of the whole system and will bring out ucode bugs easier than vanilla Linux installations.
@eschwartz and @krzyszto. Thank you for your answers and nice suggestions. I will now do my homework, and if something arises, I will come back to ask. Kind regards.
ZFS packages are provided by the third-party archzfs repository. You can use it as follows.
"OpenZFS developers have their own pacman repository" -- I think not. It's just as trustworthy as any other completely unofficial thing.
hseara,
I refuse to refrain from opinions!
Here is my opinion: there is nothing wrong with using Arch in production. :)
https://wiki.archlinux.org/index.php/User:Seblu#Should_I_run_Archlinux_on_my_server.3F https://lists.archlinux.org/pipermail/arch-general/2013-July/033791.html
You'll want to do your sysadmin homework though (this applies to any distro, but with Arch-specific quirks), which means don't do system updates the normal way -- first, do the update in a staging environment, verify it works, and then roll out the same packages to production. This applies to more than just the kernel + zfs, but will take care of those for you too.
(e.g. run a custom mirror and update from there to ensure packages only get upgraded after testing. The custom mirror might only include the actual repo .db files.)
Kernel updates that cause zfs failures will:
be noticeable on your staging server
not cause errors until the modules get unloaded and fail to reload, which typically happens only on the next reboot, so you have time to downgrade, you just need to watch the output of pacman.
In my experience, it is not GCC updates that cause failure to rebuild -- it is incompatibilities with the next major.minor mainline kernel releases (patch releases on the stable branch are generally fine).
Generally, you don't want to constantly update kernels without rebooting, and you don't want to constantly reboot a server. Seblu has some advice on that too. The simplest solution is to pacman.conf -> HoldPkg and schedule kernel updates for a maintenance window -- you might also want to use the LTS kernel to make upstream regressions less likely to hit you, which also means... that the ZFS modules are less likely to break on new versions, because you're not using those new versions, only the security updates for an old version.
If you have any further questions, feel free to ask them.
@hseara Please also see https://openzfs.github.io/openzfs-docs/Getting%20Started/Arch%20Linux/index.html - OpenZFS developers have their own pacman repository which provides various flavors of ZFS modules.
@eschwartz I am planning to install zfs in an arch-based production storage server (please refrain from opinions). I have been reading about the multiple options to install zfs existing on arch and I am slightly confused :).
In our centos servers, we use dkms, but for arch, we are not sure. We are afraid of dmks failing after some gcc update. I am using the officially supported arch kernels (stable and lts). My question is easy zfs-linux-dkms+zfs-utils (Same maintainer @eschwartz) or zfs-linux-stable+zfs-linux-lts+zfs-utils (different maintainers). When using arch and official kernels I would go for the last option but there are some comments about issues regarding not in sync maintainers. I would appreciate a comment from @eschwartz.
I can confirm that it works fine on my newly set-up rpi4 (aarch64), and on my older ODROID-XU4 (armv7h). I use the AUR through aurutils so at least I can keep manually adding the architecture to the PKGBUILD each time I do an aur update, but it would definitely be more convenient to not need to. That said, perhaps aurutils lets me pass a similar "ignore arch" flag like makepkg -a ...
Thanks for all your work maintaining this PKGBUILD, even if you do intend to focus on i686/x86_64 support!
Because that's not how the arch array works, what you actually want is for it to include armv7h. See the PKGBUILD(5) documentation...
Is there any reason this PKGBUILD isn't set to "any" architecture? I'm running it on my armv7h (archlinux-ARM) box along with zfs-dkms (which DOES use "any" architecture) without any issues.
zfs.initcpio.hook is missing load-key support.
initcpio hook from the official zfs-utils package has stuff like:
zfs_decrypt_fs() {
dataset=$1
# check if 'zfs load-key' is available
zfs 2>&1 | grep load-key > /dev/null || return 0
# check if dataset is encrypted
[ "$(zfs get -H -o value encryption "${dataset}")" != "off" ] || return 0
# check if key is already loaded
[ "$(zfs get -H -o value keystatus "${dataset}")" != "available" ] || return 0
# get the encryption root
encryptionroot=$(zfs get -H -o value encryptionroot "${dataset}")
# export encription root to be used by other hooks (SSH)
echo "${encryptionroot}" > /.encryptionroot
# loop until we get the correct password or key is unlocked by another vector (SSH for instance)
while [ "$(zfs get -H -o value keystatus "${encryptionroot}")" != "available" ] &&
! eval zfs load-key "${encryptionroot}"; do
sleep 2
done
if [ -f /.encryptionroot ]; then
rm /.encryptionroot
fi
}
and they call this function just before mounting every dataset.
@ipickering I ran into the same issue a few days ago. It turns out that the maintainers of the zfs-linux-lts package maintain their own unofficial zfs-utils package for situations like this. See this comment for the link:
https://aur.archlinux.org/packages/zfs-linux-lts/#comment-779700
It worked for me. Not sure if/how it differs from this one. Maybe you can compare the PKGBUILDs.
Is this going to be updated to 2.0.1? I upgraded my system and got stuck because I can't reinstall ZFS after removing it because now it has a dependency on 2.0.1, which doesn't exist.
Will confirm that adding aarch64 works great with the current PKGBUILD @eschwartz.
RPi4, especially the 8 GB model, makes for a pretty decent personal NAS.
@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.
==> Verifying source file signatures with gpg... zfs-2.0.0.tar.gz ... FAILED (unknown public key 0AB9E991C6AF658B)
==> ERROR: One or more PGP signatures could not be verified!
==> ERROR: Could not download sources.
This package requires "core/which" to support the dracut module check. @eschwartz can you add it, please?
zfs and zfs-utils are running here on Raspberry Pi 4 (4GB) (aarch64) without any issues. To build it, just replace PKGBUILD line:
arch=("i686" "x86_64")
with
arch=("i686" "x86_64" "aarch64")
Normally segfaults using gcc occur either if the compiler has some weird bug, or if you don't have enough RAM. I didn't think it could be the RAM, because I had 64G installed in my system. After trying 6-7 times to brute-force it (if it throws an error just try compiling again), it finally succeeded in compiling. Turns out one stick of RAM was faulty. So I would advise you that upon receiving a similar error, you try brute-forcing it a couple of times and double-checking with a memtest, just for good measure. Shoutout to the #archlinux IRC for the help.
Unfortunately, this package doesn't compile for me. In the directory zfs-utils/src/zfs-0.8.4/lib/libzpool, the compiler throws the following error:
/bin/sh: line 2: 68193 Segmentation fault (core dumped) /bin/sh ../../libtool --silent --tag=C
b/libspl/include -D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_LAR
run\" -DSBINDIR=\"/usr/bin\" -DSYSCONFDIR=\"/etc\" -UDEBUG -DNDEBUG -D_FORTIFY_SOURCE=2 -std=gnu99
-Wframe-larger-than=4096 -DLIB_ZPOOL_BUILD -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -MT lsta
make[3]: *** [Makefile:1216: lstate.lo] Error 139
I'm currently on the 5.7.12-zen1-1 kernel. I've also tried with the 5.7.12-arch1-1 kernel, just for good measure, but even after re-cloning, the compiler still throws the same error.
Regarding the big picture, I'm trying to build the zfs-dkms package from the AUR, where zfs-utils is logically a dependency.
makepkg --ignorearch would allow it to be built on unsupported architectures. However, previous comments indicated that would not even work because of e.g. configure: error: cannot guess build type; you must specify one.
https://aur.archlinux.org/packages/zfs-utils/?PP=250#comment-711967
Thank you for your contributions Eli. Submitted a PR on github to add armv7h to the supported arch, I have tested this on arch for raspberry pi 4 and have a clean compile. Light manual testing has shown no issues so far.
This is a necessary dependency to add zfs-dkms to arch on rpi 4. Note that other distros (Ubuntu aarch64) support zfs-utils.
I have not tested on a aarch64 kernel for the RPi4.
zfs-utils package from https://archzfs.com/archzfs/x86_64/ has better initcpio zfs hooks. For example it has the ability to unlock encrypted volumes at boot (zfs load-key). Would it be possible to implement this here?
Can you look up what the word "arch" means in the PKGBUILD(5) man page?
No.
EDIT: I'm guessing your comment is due to the desire to have this work out of the box on ARM arches. Obviously, the difference matters, or you would not be asking! And no, I've previously had comments indicate that this package didn't build on ARM, so I don't feel comfortable listing support for something I don't test which maybe doesn't work.
Can the arch be changed to any to match the zfs-dkms package?
I independently figured that out and filed https://bugs.archlinux.org/task/66762 as I'm not sure whether systemd should be in clean chroot builds, but it used to be and that assumption has actually changed now.
It has ramifications for more than just the availability of the systemctl utility -- it also affects the passwd database.
So systemd needs to either be added as a makedepends, or re-added to base-devel. Since you were the one who added systemd to base-devel a few years ago, maybe you have an opinion or two to share on that bug report? :)
I have the same issue than @PedroHLC when building with extra-x86_64-build on my aurbot builder.
There is some hints in the build log:
checking for systemd support... no
Calling systemctl in the PKGBUILD produce the following error:
==> Starting build()...
/startdir/PKGBUILD: line 38: systemctl: command not found
==> ERROR: A failure occurred in build().
systemctl is packaged inside systemd. So you need to add systemd as a makedepends.
What about moving it on community? ;)
@eschwartz Sorry, you were right, compared two BUILDINFO, at some point my containers removed systemd and stayed just with systemd-libs.
Well, if systemctl --version succeeds in your container environment I'm at a loss for words as to how zfs's --enable-systemd=check default could incorrectly analyze systemd as not being there:
As always, I have built this package and zfs-dkms using extra-x86_64-build, entered the build container using arch-nspawn, installed linux/linux-headers, and ensured that dkms install correctly builds the modules for the default kernel. Then I uploaded the resulting packages to https://wiki.archlinux.org/index.php/Unofficial_user_repositories#eschwartz
So I'm quite positive this can correctly work. You cannot argue with experimental results, and I have experimented, it did correctly work, and the results are freely available for download, right there; you may inspect the .BUILDINFO from those package tarballs and see how I've built it, with what installed packages, what makepkg.conf options, and what $PWD, try to reproduce it using makerepropkg (part of devtools) and so on.
If I had a better understanding of how your build differs from my build, then perhaps we could determine why your build failed with such disastrous results and ended up missing parts.
systemd 245 (245.5-2-arch)
+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
I actually build from a clean systemd-nspawn container with just base-devel installed. Pretty much how I've been building ZFS since 2018 on my repository...
It should autodetect systemd support and install both.
It does, in fact, autodetect systemd support and install both. On my machine.
Does systemctl --version not succeed in your environment? It is part of base-devel, so this really should work...
@eschwartz Not sure if it's something that changed with 0.8.4, but building this (without the rm *modules-load.d line) doesn't install a zfs-mount.service anymore...
With the latest PKGBUILD
rm: cannot remove '/home/main-builder/pkgwork/pkg/zfs-utils/usr/lib/modules-load.d': No such file or directory
this version no longer compiles, please update the package
@eschwartz : when this will be updated to 0.8.4?
This won't build for me. Give me this error:
CCLD libzfs.la /usr/bin/ld: ../../lib/libshare/.libs/libshare.a(smb.o):(.bss+0x0): multiple definition of `smb_shares'; ../../lib/libshare/.libs/libshare.a(libshare.o):(.bss+0x0): first defined here collect2: error: ld returned 1 exit status make[3]: [Makefile:694: libzfs.la] Error 1 make[3]: Leaving directory '/home/gooberslot/tmp/zfs-utils/src/zfs-0.8.3/lib/libzfs' make[2]: [Makefile:562: all-recursive] Error 1 make[2]: Leaving directory '/home/gooberslot/tmp/zfs-utils/src/zfs-0.8.3/lib' make[1]: [Makefile:730: all-recursive] Error 1 make[1]: Leaving directory '/home/gooberslot/tmp/zfs-utils/src/zfs-0.8.3' make: [Makefile:599: all] Error 2
This package builds fine on arm64 if the config.guess is updated or the config.guess provided on the system is used instead of the one included with the package.
This PKG looks like it is missing a lot of stuff. I really recommend to use https://github.com/archzfs/zfs-utils instead.
Hi there! I get a this: ==> Verifying source file signatures with gpg... zfs-0.8.2.tar.gz ... FAILED (unknown public key 6AD860EED4598027)
has anything changed about that signature of the packages?
A small fix for zfs.initcpio.hook suggested:
if ! zpool list -H "${pool}" 2>&1 > /dev/null ; then
if ! zpool list -H "${pool}" > /dev/null 2>&1 ; then
From bash reference:
Note that the order of redirections is significant. For example, the command
ls > dirlist 2>&1
directs both standard output (file descriptor 1) and standard error (file descriptor 2) to the file dirlist, while the command
ls 2>&1 > dirlist
directs only the standard output to file dirlist, because the standard error was made a copy of the standard output before the standard output was redirected to dirlist.
I've successfully built on aarch64 after adding ./autogen.sh before ./configure.
For x86 and x86_64 that could be skipped, but I guess for most other archs it needs to be done, at least until upstream updates automake version they build configure scripts with.
alpine for example does autoreconf -vif in prepare: https://git.alpinelinux.org/aports/tree/main/zfs/APKBUILD
zfs-dkms is unaffected by this issue because it does autoreconf -fi in prepare: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=zfs-dkms#n37
maybe add something like [ "$CARCH" != "x86" -a "$CARCH" != "x86_64" ] && autoreconf -vif in prepare(), also adding aarch64 to arch var would be nice as it built fine for me with that fix.
edit: fixed suggested autoreconf condition
Needs to be updated for Python 3.8
I don't know if this is the right place, when I tried switching over to this zfs-utils package (from the one provided on archzfs), my system would not boot properly -- it would complain about being unable to import the zpools (was in use by another system with the hostid=0).
When I switched back over to the zfs-utils from archzfs, my system works once again.
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...
To build on aarch64, config.sub and config.guess have to be updated: https://github.com/zfsonlinux/zfs/issues/8345#issuecomment-538661596
Can't build on aarch64 :(
Says:
configure: error: cannot guess build type; you must specify one
any help?
Best regards ArchGalileu
Since dracut is in the official Arch repo, could we please include the dracut files here? Line 60 just needs to be deleted.
Could we please have zfs_decrypt_fs functionality? (See shamer's comment.) It would be much appreciated!
mount.zfs does not work:
mount -t zfs zroot/data/default /mnt/ filesystem 'zroot/data/default' cannot be mounted at '/mount' due to canonicalization error 2.
@ColdCanuck,
Thank you. I've submitted an upstream fix as https://github.com/zfsonlinux/zfs/pull/8851
The addition of the python3-fake soft link to /bin/true causes the utility program arc_summary not to be included in the package file. I assume this is because the upstream configurator needs to determine if a python3 or python2 version should be used and can't do that with the fake python.
There are other python scripts in the package so some version of python is a "soft" dependency., if not on the build at least on the programs themselves.
New to Arch, so sorry if this the the wrong way to notify you; I'm open to gentle education if there is a more correct way.
zfs.initcpio.hook does not yet have zfs_decrypt_fs functionality that is present in https://aur.archlinux.org/zfs-utils-git.git
This can prevent being able to boot into an encrypted root.
I've found a problem, zfs.initcpio.hook does not seem to honor canmount=off on datasets.
patch is something like
canmount=$(zfs get -H -o value canmount "${dataset}")
if [ "${canmount}" = "off" ] ; then
continue
fi
at line 61
please use "git shallow clone" to save traffic.
81.64 MiB :full clone
5.56 MiB :shallow clone
--> less by factor 15
sample call:
git clone --depth=1 --recurse-submodules -b zfs-0.7.13 https://github.com/zfsonlinux/zfs
Valid point, but this should then be in zfs-dkms which provides the module and depends on the utils.
I removed it from spl-dkms too, because namespacing: http://www.clifford.at/spl/ is already a package and it sure isn't a kernel module. Didn't consider that zfs wouldn't have the same problem.
Thanks for putting this up. Unfortunately, this breaks some dependencies, because the PKGBUILD should include provides=zfs. Otherwise I can't have zfs-auto-snapshot installed.
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...