Arch Linux User Repository

@jongeduard

Thanks for asking. I am using a very old ATI video card that in this kernel update amdgpu is suddenly trying to handle. This causes a crash and somehow also ZFS stopped working. When I stopped amdgpu from loading it solved all of my problems.

I got it to work with 5.18 but it involved me going into my paru cache folder and git pull + makepkg manually since paru didn't pick up that anything had changed during a normal update command.

I think simply adding the + discriminator in the version doesn't cause AUR helpers to distinguish that it's a new version to build.

Fails to build with 5.18.1-arch1-1 kernel.

configure: error: 
    *** None of the expected "blk_queue_discard" interfaces were detected.
    *** This may be because your kernel version is newer than what is
    *** supported, or you are using a patched custom kernel with
    *** incompatible modifications.
    ***
    *** ZFS Version: zfs-2.1.4-1
    *** Compatible Kernels: 3.10 - 5.17

@habys What does your DKMS log say about it?

Are you shure you have everything updated?

And with that I mean are you also shure: 1. that you are not ignoring any packages in your pacman.conf anymore, 2. that you tried switching to at least one other mirror (recently I was having issues with partial upgrades from a bad mirror) and 3. that you also updated with '-Syyu' (double 'y').

I am having no luck with 5.18.1-arch1-1 currently. zfs-utils 2.1.4+65.r05147319b0-1 zfs-dkms 2.1.4+65.r05147319b0-2

I have removed and reinstalled zfs-utils and zfs-dkms after installing the new kernel to no avail.

Works fine for me indeed. Builds for both kernels.

The archzfs version is still having the issues (forgot to mention, but I have been using that one for quite while now, but I switched back and forth more than once), so now we are back on this one on AUR again. :)

There was an update to this package on 2022-05-25 to handle kernel 5.18.

For anyone having issues with updating their kernel, make sure you update your zfs packages (aur) as well.

Currently working for me with:

zfs-dkms 2.1.4+65.r05147319b0-2

zfs-utils 2.1.4+65.r05147319b0-1

linux 5.18.1.arch1-1

@bazzawill - I set the ignore option in /etc/pacman.conf to not update my kernels with:

IgnorePkg = linux-lts* linux-hardened*

(I build & update my kernels manually with arch-sign-modules in AUR)

As @jongeduard mentioned if a build fails I just downgrade the kernel with pacman -U /path/to/kernel.pkg.zst /path/to/kernel-headers.pkg.zst if the zfs modules do not build.

The zfs modules mostly build without problems for me as linux-lts & linux-hardened are not bleeding edge like linux-zen. Rarely when there is major version change in gcc I have to rebuild a whole kernel as all modules fail to build with a differing gcc major version & a kernel built with a previous gcc.

@bazzawill I am using ZFS with Arch Linux for roughly a year now. I have had build failures view times now, but they should not be a problem if you do a view things right.

Most of them where during a new kernel version release, while ZFS was indeed not ready the newest kernel version. And with a version I mean like this upgrade from 5.17 to 5.18, not the revision/build number for each regular kernel update.

My main solution: I have simply both the regular kernel and the LTS kernel installed. Most of build failures I have had where with the regular kernel, while the build for the LTS version failed only 1 time.

And since the LTS kernel is still more stable an reliable in general, I can also recommend you to boot the LTS kernel by default, when it comes to a NAS / file server with ZFS like I built at home. Unless your hardware really modern that it requires the new kernel with the newest drivers. But the 5.15 LTS version is fine for me now. Actually the 5.10 (which was the previous of the LTS) was already perfect.

Another thing I can recommend: preserve your cached packages in /var/cache/pacman/pkg/ up to a view versions (don't clean your packages with pacman -Sc, but use paccache for this, which let's you selectively remove the oldest versions), such that you can downgrade your kernel if needed.

From within that folder you can simply run a downgrade like: sudo pacman -U linux-5.17.9.arch1-1-x86_64.pkg.tar.zst linux-headers-5.17.9.arch1-1-x86_64.pkg.tar.zst

Don't forget to also downgrade nvidia or wifi drivers or other kernel modules if you have them too, they each install into a specific /lib/modules/<kernel-version>/ folder, which needs to be of a matching version.

And finally: also permanently keep your locally stored zfs-dkms and zfs-utils that you cloned from git in a folder, in which you also keep your built packages, such that you can reinstall these when needed as well.

So I just switched from the zfs-linux kernel to the dkms package and then I get hit with this. Just wondering how often this might occur. The issue is my system auto updates and because I had a power outage my system restarted and then my drives did not mount. Yes I know running a rolling release distro this can happen and some oversight when upgrading is wise but...

@fryfrog

Thanks for the link. Basically they fixed a NULL referencing pointer-to-a-struct by actual defining the struct and giving that to the pointer (if you have ever learned some C programming you'll probably know what I mean).

I really like their statement "Ah yes, the fun of compilers getting smarter and noticing when we did something foolish.", because that's so true.

And these things are indeed a good thing, it helps getting a thing like ZFS getting more safe and stable.

Not being able to build something has often very good reasons.

There are a number of commits in github issue #13463, hopefully they'll make a new release soon that supports it.

Looks like 5.18 isn't supported yet so I had to downgrade my kernel in order to not break my system outright.

==> dkms install --no-depmod zfs/2.1.4 -k 5.18.0-zen1-1-zen
Deprecated feature: REMAKE_INITRD
configure: error: 
        *** None of the expected "blk_queue_discard" interfaces were detected.
        *** This may be because your kernel version is newer than what is
        *** supported, or you are using a patched custom kernel with
        *** incompatible modifications.
        ***
        *** ZFS Version: zfs-2.1.4-1
        *** Compatible Kernels: 3.10 - 5.17

Error! Bad return status for module build on kernel: 5.18.0-zen1-1-zen (x86_64)
Consult /var/lib/dkms/zfs/2.1.4/build/make.log for more information.
==> WARNING: `dkms install --no-depmod zfs/2.1.4 -k 5.18.0-zen1-1-zen' exited 10

@daemonjax - https://unix.stackexchange.com/a/364920/93470 (add unknown public key for makepkg)

building the snapshot from this page works ok

==> Leaving fakeroot environment.
==> Finished making: zfs-dkms 2.1.4-1 (Tue 26 Apr 2022 21:59:20 BST)

I had trouble making this package...

ERROR: 0001-only-build-the-module-in-dkms.conf.patch was not found in the build directory and is not a URL.

So I get the patch file from the Sources list on this page, and I still can't build it...

0001-only-build-the-module-in-dkms.conf.patch ... FAILED

ERROR: One or more files did not pass the validity check!

Then I figured if I just cut out some of the junk in the patch file (it looks like a simple copy-paste of an entire email someone got), then it would accept the patch... nope (but I kept my changes). So, then I figured out I need to run makepkg -g >> PKGBUILD to update the hash for the patchfile. Ok... I do that, then I get a new error:

Verifying source file signatures with gpg... zfs-2.1.4.tar.gz ... FAILED (unknown public key 6AD860EED4598027) ERROR: One or more PGP signatures could not be verified!

So, then I figure out I have to add that gpg key to my key ring blindly (which defeats the purpose of using gpg, but whatever -- who is Tony Hutter and why should I trust him? Whose gpg key should I expect? No idea, but I have no choice if I want to continue EDIT: There IS a line about him in PKGBUILD file, so my bad) using the command as the non-root user I'm using the build the package:

gpg --receive-keys 6AD860EED4598027

And now finally I can build the package.

Thoughts:
1) The patch is required to make the package, and it's from the year 2018... so it should probably just be included at this point, right? Can't it be set up to auto-download the file at least? 2) Why I should dis/trust Tony Hutter's GPG key for the zfs-2.1.4.tar.gz file should probably be included in the PKGBUILD file. EDIT: There is a comment line in the PKGBUILD about trusting Tony Hutter, so that's fine. I didn't see it while using a standard tty terminal.

zfs-dkms 2.1.4-1 all ok with 5.15.27.hardened1-1

I had to clean up some old config with rm -rf /var/lib/dkms/zfs/2.1.2 to fix Unable to build an empty module

@jonathon Correct, also with archzfs now. Tried it again. Issues solved with 5.15.23-2-lts.

If you're having an issue at this point it's because you have a partial upgrade. All kernels have been built with GCC 11.2.0, and DKMS will rebuild the ZFS module accordingly.

Currently I am using the archzfs version (but also keeping a copy of this AUR one in a folder so that I can switch things easily), but yesterday the update to LTS kernel 5.15.23-1-lts gave me that exact same ZFS build error, about that it could not build an empty module (I verified it by manually running the dkms build command again to see it's output). Luckily on the regular kernel 5.16.9-arch1-1 it did still build fine (with that same archzfs version) in my case. So with having both kernels installed on my system it wasn't a direct issue. But if it's also gonna happen with the regular kernel.

https://bbs.archlinux.org/viewtopic.php?pid=2022195#p2022195

did some experiments and concur largely with @razielgn re: synchronous changes:

• build failed with gcc-11.2.0-3, gcc-libs-11.2.0-3, binutils-2.38-3, linux-lts-5.15.23
• build failed with gcc-11.2.0-3, gcc-libs-11.2.0-3, binutils-2.38-3, linux-lts-5.15.22
• build failed with gcc-11.1.0-3, gcc-libs-11.1.0-3, binutils-2.36-3, linux-lts-5.15.23
• build succeeded with gcc-11.1.0-3, gcc-libs-11.1.0-3, binutils-2.36-3, linux-lts-5.15.22

My system was running gcc-11.1.0-1 and binutils-2.36.1-3 and linux-5.15.13 and zfs was working fine. As soon as I upgraded to linux-5.16.8 nfs-dkms failed to build. I downgraded the kernel back to 5.15.13 and everything is fine again. So maybe it is just the kernel not the gcc and binutils?

dkms apparently cannot build 2.1.2-2 with gcc 11.2 and binutils 2.38: I get "checking whether modules can be built... no". make was failing due to missing target when invoked (sorry, I lost the logs). It's easy to reproduce if you include [testing] packages. I downgraded gcc to 11.1, binutils to 2.36 and got it working again. Also cannot build zfs module with gcc 11.1/bintuils 2.36 for linux-tls 5.15.23 (also in testing), I guess the maintainers have made synchronous changes across all those packages.

Thanks a lot fryfrog for confirming about this, I use the same archzfs/zfs-dkms but didnt know the right place to ask this question. I have updated now, and it indeed works all fine.

I use archzfs/zfs-dkms, but it built and ran fine for two of my systems so far.

Hi, does someone know if this builds and works fine on linux 5.16. I am using zfs on a server and i dont want to cause a downtime by this.

Sorry, by mistake I deleted my comment.

But yes, you're right. I just discovered that the packages where build on a box with older versions.

You're behind on your zfs-dkms version, maybe 2.1.1 would fix it? I'm currently running 2.1.1 w/ kernel 5.15.5 just fine.

@jongeduard, I am aware that it is likely harmless, at least for now. I just wanted to raise the issue with the maintainer.

@eschwartz @jonathon

@debohman I noticed the same. Some searching on the internet will show you more recent examples elsewhere around DKMS.

In the DKMS project itself on GitHub I found this: https://github.com/dell/dkms/pull/164.

So it's just a change there. When you click on "#158" on that page, you'll find that it's apparently a change in order to remove "distro specific packaging" related things.

Anyway, it's just a warning, not a real problem and everythings works fine.

When I just upgraded my system, I received the following warning from dkms:

Deprecated feature: REMAKE_INITRD

The system was upgraded to dkms-3.0.2-1.

thank you for the update! Great! :-)

On the topic of swapping between zfs-utils from archzfs vs eschwartz (the one in AUR), a word of warning!

The initcpio hooks in in https://aur.archlinux.org/cgit/aur.git/tree/?h=zfs-utils is not the same as in https://github.com/archzfs/zfs-utils If you rely on encrypted root volume, the initcpio in zfs-utils AUR package will not work, since it is lacking the zfs loadkey call. This is present in archzfs version though. Read more here: https://github.com/eli-schwartz/pkgbuilds/issues/30

@fryfrog, that is very useful. It wasn't commented in my paru.conf, but I added it.

@dhathaway, since you use paru, you can edit /etc/paru.conf and uncomment the line with BatchInstall, that way it'll package up the AUR packages, but install them all together at the end! This is possible in yay too, but I don't know how.

@fryfrog you are right that this is mentioned many times in the past here. You just have to know what to look for, which I did not. Thanks for the hint.

Since it has been many pages since a fix was posted, here is what I did:

I started in ~/.cache/paru/clone/ since I prefer paru to yay.

cd zfs-dkms
makepkg -s
cd ../zfs-utils/
makepkg -s
sudo pacman -U ~/.cache/paru/clone/zfs-dkms/zfs-dkms-2.1.1-1-any.pkg.tar.zst \
    ~/.cache/paru/clone/zfs-utils/zfs-utils-2.1.1-1-x86_64.pkg.tar.zst
sudo vim /etc/pacman.conf
paru
sudo reboot

Note that I had gone back to a previous kernel, so I also took linux and linux-headers out of the IgnorePkg so that I could upgrade the kernel finally. That is why I edited pacman.conf.

@dhathaway, you have to install/update both packages at the same time. This has always been true. Read further back if you need help understanding, it is a common problem.

I receive this error when installing using yay or paru:

looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing zfs-utils (2.1.1-1) breaks dependency 'zfs-utils=2.1.0' required by zfs-dkms

I've never encountered this before. How to resolve? A grep in ~/.cache/[yay|paru]/zfs-[dkms|utils] doesn't find 2.1.0.

@fryfrog Thank you! I installed the zfs-dkms and the zfs-utils from archzfs yesterday and it did the job really fine and just works now.

Just 1 day later, right now, this one here has finally been updated. But that's rather funny than a problem. I think it's a very good practice not to bet on just one horse, and to have 2 compatible choices.

Until now, I'd say they're usually very close and it didn't really matter. Sometimes archzfs was first, sometimes aur. Sometimes when patches are needed, aur is quicker to do it and then archzfs follows suit. You should generally be able to swap between them, so you could flip to archzfs/zfs-dkms for now to update and switch back to aur/zfs-dkms if you need to later.

@fryfrog Thanks for your reply. I'm still quite new to ZFS on Arch (started using it just about 2 months ago). Also just searching for what I exactly want, and how much I want to worry about things as well. :) One good reason to choose ZFS on my home built NAS/server was also it's known reliability (Btrfs is very good as well, but still not parity raid ready). And my reason to choose for Arch Linux is because of my familiarity with it now and also because I like it really much (although I have also considered to choose for FreeBSD with ZFS in the case of my NAS, but I got certain specific hardware related issues with it).

For the idea or also being compatible recent kernels I choose this zfs-dkms package. But now it's taking quite long indeed since 2.1.1 is clearly finished. Does archzfs/zfs-dkms a better job in general with respect to updates?

@jongeduard - it's safe to manually build zfs-dkms / zfs-utils versions 2.1.1. I noticed today on another machine running Manjaro they use 2.1.1 now.

If you have pacman-contrib installed the PKGBUILD integrity sums can be updated with updpkgsums run in the directory with the PKGBUILD & then makepkg -s

After building install with:

mylist=$(ls /path/to/packages/zfs*2.1.1*)
sudo pacman -U $mylist

I've successfully built zfs modules for:

==> dkms install --no-depmod -m zfs -v 2.1.1 -k 5.12.19-hardened1-1-hardened
==> dkms install --no-depmod -m zfs -v 2.1.1 -k 5.10.61-1-lts
==> dkms install --no-depmod -m zfs -v 2.1.1 -k 5.10.18-zen-1-zen-lts510-g513e3c94a40f
==> dkms install --no-depmod -m zfs -v 2.1.1 -k 5.10.60-hardened1-1-hardened-cacule
==> dkms install --no-depmod -m zfs -v 2.1.1 -k 5.12.19-1-ck
==> dkms install --no-depmod -m zfs -v 2.1.1 -k 5.14.8-hardened1-1-hardened

@johno, @eschwartz maintains a lot of packages and is just a regular old human doing this in their spare time. He's probably on vacation or busy or who knows what. Might even be testing/running it locally before pushing it up. It was updated 2 months ago, so it clearly isn't abandoned.

You can just fetch the PKGBUILD and update it yourself, if you want it updated right meow. Or archzfs/zfs-dkms has been updated, so you could switch to that.

Hello,

is this package dead? Why is it no longer maintained? Is there a reason for this? Thanks for an answer!

Best regards, johno

@Zod

That however skips all checksums and not just the specific archives. It's best to not do a global skip as other files can still be pulled.

If we're going to be clearer then we should also say why you shouldn't do something.

Or, if your really brave. Change the version to 2.1.1, save changes and...

--skipchecksums

Edit: In the interest of being more clear...

Edit the PKGBUILD to update zfs-(dkms/utils) to version 2.1.1 and save changes.

If you look at the man page for makepkg you will see --skipchecksums

I used the command "makepkg -s --skipchecksums" to build both packages.

2.1.1 was released 5 days ago with support for 5.14.x

Download snapshot, open PKGBUILD, change version to 2.1.1 and it's sum to 'SKIP'

Repeat for zfs-utils.

pacman -U $path/zfs-dkms.pkg.tar.xz $path/zfs-utils.pkg.tar.xz

Done.

@jongeduard: If that is a strong concern of yours, you should probably fork this package and maintain your own version that never patches. In the past, it and archzfs have applied patches from master in order to get versions working with the latest Arch kernel. They're usually fairly simple, but if your line is as you've stated... you've probably already violated it.

Personally, I wouldn't download any code from a unstable, unfinished version on Github when it comes to a filesystem.

If a certain new kernel version does not let it build successfully, then it doesn't, and it shouldn't.

Safety of my files sitting on my ZFS pool is more important.

Downgrading the kernel feels like the only correct decision for me, until the new version is truly released.

My advice is to have linux-lts{-headers} installed as backup kernel.

My advice is to have linux-lts{-headers} installed as backup kernel.

@johnhamelink

For me, it's not the first time that I downgraded a kernel and I knew that I have 4 packages in total that are related to my installed kernel version. My latest previous versions that I could get with the pacman -U from /var/cache/pacman/pkg/ where these very recent ones (from only one or two days earlier or so): linux-5.13.13.arch1-1-x86_64.pkg.tar.zst, linux-headers-5.13.13.arch1-1-x86_64.pkg.tar.zst, nvidia-470.63.01-4-x86_64.pkg.tar.zst, broadcom-wl-6.30.223.271-320-x86_64.pkg.tar.zst.

Actually the best advice to give is to check your /var/log/pacman.log for history if you missed it (after the system reboot after which you discover that ZFS wasn't running anymore). Then you can easilly see which packages where installed, and you only need to pick the kernel version dependent ones from them to downgrade.

This aproach went quickly for me. And a bit of searching in the issues on github showed me the reported issue with the no longer supported blk_alloc_queue() somewhere in the sourcecode (after also reading my own DKMS log) and that this story was still a work in progress. So that made clear a kernel downgrade is the only option for the moment.

Here's how to downgrade the kernel until zfs-2.1.1-staging build is promoted:

Use pacman's cache to downgrade the linux kernel

sudo pacman -U /var/cache/pacman/pkg/linux-headers-5.13.8.arch1-1-x86_64.pkg.tar.zst
sudo pacman -U /var/cache/pacman/pkg/linux-5.13.8.arch1-1-x86_64.pkg.tar.zst

Then in /etc/pacman.conf, ignore the downgraded packages

IgnorePkg   = linux linux-headers

Remember to undo the pacman.conf change later! If you are using the nvidia package, you may prefer to move to nvidia-dkms if you find your drivers are no longer available.

Need zfs-2.1.1-staging for kernels >= 5.14.2.

Another one for 5.14: https://github.com/openzfs/zfs/commit/1c24bf966c373009f2be77438e8696aabf50a7e7

Without this my system failed to boot after upgrading to linux-zen 5.14.2.zen1-2

Linux 5.14 should have an updated OpenZFS release soon, but for the impatient ones, you can patch with https://github.com/openzfs/zfs/commit/eb17f92e1edabcde442e5fbdff4525054be8595, remake, and reinstall.

Instead, build but don't install both packages. Then install both packages at the same time w/ pacman.

If anyone runs into an issue where zfs-dkms and zfs-utils cannot be updated due to zfs-dkms being locked to a version of zfs-utils, you can fix it by removing the zfs-dkms package first, updating zfs-utils, then re-installing zfs-dkms.

I had to downgrade gcc to 10.2.0-6 to get the modules to build for zfs-2.0.5 & 2.1.0 on linux-hardened-5.9.12-a-1

For linux-hardened-5.12.19 the modules build successfully with gcc-11.1.0 & zfs-dkms 2.1.0

Nice speech. Totally irrelevant though.

When I say I'm not going to apply the patch, what I mean is I can't. If you try applying it, you'll find out why you can't either.

To save you the time, I'll tell you the error message you'd get.

Reversed (or previously applied) patch detected! Assume -R? [n]

P.S. check the author of that PR, then check the commit message for the latest version of this PKGBUILD.

No

Please apply this patch https://github.com/openzfs/zfs/pull/12178

I don't know if it was just me beeing stupid, or if it is a thing, but I downgraded the kernel to 5.11 on a new machine to install zfs-dkms 2.0.4 and I all the time got the error "make: *** No targets specified and no makefile found. Stop." during the dkms install. Solution (for me) was to downgrade gcc (to e.g. 10.2.0). And then the dkms install worked as always.

btw: Thank you very much for maintaining the package! Appreciate the effort!

@iusrlinearb: The patches in the recent PKGBUILD update make it compatible, they're backported from master, so it is compatible. But once zol does the same thing and releases 2.0.5, it'll be official and also compatible.

For clarity, although there is mention of 5.12 in the patches, 2.0.4-2 isn't 5.12 compatible yet and it'll be a future release once ZOL officially supports?

There's an open PR in my PKGBUILDs repo to add a couple of backports from the zfs master branch. This will hopefully be resolved soon.

Not sure, as for current 2.1.0-RCs the maximum is still 5.11. The workaround is to use LTS version of the kernel (or self-built 5.11 version of the kernel of your choice) until the support is there.

Nasty message while upgrading to Linux 5.12.1.arch1-1

       *** None of the expected "capability" interfaces were detected.
        *** This may be because your kernel version is newer than what is
        *** supported, or you are using a patched custom kernel with
        *** incompatible modifications.
        ***
        *** ZFS Version: zfs-2.0.4-1
        *** Compatible Kernels: 3.10 - 5.11

Indeed, META still has Linux-Maximum: 5.11

update version soon?

qs9rx,

That's an integral part of setting up dkms(see wiki). There's no provides for the various linux-*-headers packages, so specifying an explicit dependency on linux-headers would prevent people from using this package with kernel variants like linux-lts.

This is missing the dependency for kernel headers. Without linux-headers installed all I got was:

==> Unable to install module zfs/2.0.4 for kernel *: Missing kernel headers.

Works for me with simple pkgver bump to 2.0.4

Note 5.12 is not supported despite mentions in git log

Might work if you don't care about your data and want to bypass the configure check

Updates are quite an issue with this package, because it has the zfs-uitls version hardcoded in its dependencies. (Not sure whether this is necessary or not.)

Well, once upon a time they both built from the same PKGBUILD, thus inconveniencing users who wanted the utils but also a built variant of the module, e.g. zfs-linux...

Given there's no real guarantee from the upstream project that you can use any module version with any utils version, I think it's reasonable to expect them to be somewhat synced... this is not a problem if your AUR helper supports building multiple packages and installing them at the end. Or if you build packages into a custom repo, like aurutils does.

@andrej, you should build both packages first & then install them in one call to pacman -U

Updates are quite an issue with this package, because it has the zfs-uitls version hardcoded in its dependencies. (Not sure whether this is necessary or not.) As a consequence, one has to remove zfs-dkms, then do a system upgrade involving zfs-utils and then reinstall zfs-dkms. If something goes wrong during the update and a reboot occurs, one may end up without ZFS support, which may be a slight inconvenience or an unbootable system, depending on your ZFS setup.

Now that autoconf 2.71 and glibc 2.33 are out of testing this should install normally.

greencopper, see the comments below. I don't think you're on [testing] as you may need to be.

==> Starting prepare()...
patching file scripts/dkms.mkconf
Hunk #1 succeeded at 26 with fuzz 2 (offset 1 line).
Hunk #2 succeeded at 60 with fuzz 1 (offset -3 lines).
configure.ac: error: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION or AM_GNU_GETTEXT_REQUIRE_VERSION
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'config'.
libtoolize: copying file 'config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'config'.
libtoolize: copying file 'config/libtool.m4'
libtoolize: copying file 'config/ltoptions.m4'
libtoolize: copying file 'config/ltsugar.m4'
libtoolize: copying file 'config/ltversion.m4'
libtoolize: copying file 'config/lt~obsolete.m4'
configure.ac:48: installing 'config/compile'
configure.ac:42: installing 'config/missing'
==> ERROR: A failure occurred in prepare().
    Aborting...

Manually updating the package to version 2.0.2 works if this patch is added. It is a workaround for an autoconf issue that will be fixed in a new version, which is not available yet.

After installation, I had to manually copy config/compile from the sources to /usr/src/zfs-2.0.2/config/. A one-time manual recompilation of the DKMS module allowed me to build the module for my new kernel. I used:

dkms install -m zfs -v 2.0.2 -k 5.4.94-1-lts

Probably these steps can be integrated in PKGBUILD.

autoconf 2.71 packaged in testing.

Tried building 2.0.2 and made the package but couldn't get DKMS to compile. Could be on my end. Package might need tweaking.

Seems to not generate the Makefile. I'm bad at finding the relevant logs (past make.log from DKMS).

I pinged the autoconf maintainer on the 25th. He was busy, but 2.71 got released today. Waiting for it to get packaged, then I'll test updating this package.

+1 on the upstream autoconf issue. I also noticed that dkms-install recompiles the whole shebang in the post-transaction hooks (i.e Install DKMS modules stage) even though all of the modules were already built. On "slower" systems (1.8GHz Atom CPUs for example) with multiple kernels, this adds several extra hours for the installation as it essentially doubles the work for no reason. There is no commandline output during this time. Further, said hooks expect dpkg-architecture to be installed, which is usually not the case on non-debian systems.

@iusrlinearb thank you for reassuring me mate. I have updates my systems today and besides that "warning" it works like a charm :)

Thanks for keeping on top of it, my 2 systems appreciate it!

The update doesn't fix the autoconf 2.70 error. It does fix a separate issue, which are some additional autoconf 2.70 warnings.

There was supposed to be a new autoconf 2.70.1 / 2.71 release "later this week", but that was last week, so maybe the autoconf maintainer didn't have time either. ;)

@storm.continuity, you don't need to worry about it. It's typical to take a bit of time from an upstream to getting an update for any package because testing, home schedules etc.

I wouldn't bother switching away from this package unless there is something in 2.0.1 which is critical to you, looking at the release notes I don't see much of interest other than the autoconf fix which will be welcome for those of us who have downgraded that package.

Please delete this if this is not the right place to ask but: the package has been flagged out of date. Do i have to worry about it or is it "normal"? Should i switch to the git version? Thanks

autoconf 2.70 is now in core.

For anyone else who needs to downgrade, pacman -U https://archive.archlinux.org/packages/a/autoconf/autoconf-2.69-7-any.pkg.tar.zst should do it.

+1 confirm that downgrade to autoconf 2.69 is needed presently for makepkg until zfs autoreconf fix is patched

@Ranguvar Upstream Issue

Just a heads up that autoconf 2.70 in testing breaks the 'autoreconf' in prepare() here.

autoupdate -f does not seem to help, but downgrading to autoconf 2.69 from core works.

pikaur installs/upgrades zfs-dkms without an issue. I use it on several machines.

Thanks. I did build them manually and then install both at the same time using pacman.

You need to install both packages at the same time. I don't think yay can do this, but I did recently discover it is a feature of paru. And of course, you could do it by hand.

Is it not possible to upgrade zfs-dkms with yay? I always end up having to remove dkms-zfs first because of:

loading packages...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing zfs-utils (2.0.0-1) breaks dependency 'zfs-utils=0.8.5' required by zfs-dkms

This has been going on for a while. Hate to rely on zfs-dkms-git and zfs-utils-git but they work and I can not get 0.8.5 or 0.8.4 to work with any recent linux-lts or linux packages. Tried sifting trough build logs and at first it looked like some errors about missing rpmbuild when running configure but no.

(4/5) Install DKMS modules
==> dkms install --no-depmod -m zfs -v 0.8.5 -k 5.4.72-1-lts
/var/lib/dkms/zfs/0.8.5/build/configure: 13381: RPM_DEFINE_COMMON+= --define "$(DEBUG_KMEM_ZFS) 1": not found
/var/lib/dkms/zfs/0.8.5/build/configure: 13382: RPM_DEFINE_COMMON+= --define "$(DEBUG_KMEM_TRACKING_ZFS) 1": not found
/var/lib/dkms/zfs/0.8.5/build/configure: 13383: RPM_DEFINE_COMMON+= --define "$(DEBUGINFO_ZFS) 1": not found
/var/lib/dkms/zfs/0.8.5/build/configure: 13384: RPM_DEFINE_COMMON+= --define "$(ASAN_ZFS) 1": not found
/var/lib/dkms/zfs/0.8.5/build/configure: 13403: RPM_DEFINE_UTIL+= $(DEFINE_INITRAMFS): not found
/var/lib/dkms/zfs/0.8.5/build/configure: 13404: RPM_DEFINE_UTIL+= $(DEFINE_SYSTEMD): not found
/var/lib/dkms/zfs/0.8.5/build/configure: 13405: RPM_DEFINE_UTIL+= $(DEFINE_PYZFS): not found
/var/lib/dkms/zfs/0.8.5/build/configure: 13406: RPM_DEFINE_UTIL+= $(DEFINE_PYTHON_VERSION): not found
/var/lib/dkms/zfs/0.8.5/build/configure: 13407: RPM_DEFINE_UTIL+= $(DEFINE_PYTHON_PKG_VERSION): not found
/var/lib/dkms/zfs/0.8.5/build/configure: 13418: RPM_DEFINE_KMOD+= --define "ksrc $(LINUX)": not found
/var/lib/dkms/zfs/0.8.5/build/configure: 13419: RPM_DEFINE_KMOD+= --define "kobj $(LINUX_OBJ)": not found
/var/lib/dkms/zfs/0.8.5/build/configure: 13420: RPM_DEFINE_KMOD+= --define "_wrong_version_format_terminate_build 0": not found
configure: error:
        *** Unable to build an empty module.

@fryfrog i will try now, thanks a lot

Not all on its own, but you should be able to checkout both, make the packages and then install both at the same time w/ yay.

and yay won't do that... correct? I mean... i had never had to do that before with yay

@storm.continuity: You need to build both packages, then install them together.

getting this error while trying to install

looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: installing zfs-utils (0.8.5-1) breaks dependency 'zfs-utils=0.8.4' required by zfs-dkms

try:

gpg --keyserver pool.sks-keyservers.net --recv-keys 6AD860EED4598027

Upstream merged my backport PR, and it is now applied here too.

@storm.continuity zfs-dkms 0.8.4-1 builds with 5.8.1 kernel when if I apply the following patch (submitted by package maintainer)

https://github.com/openzfs/zfs/pull/10728/commits/29a1bc5175da9e94941ff81b2b5079c72353d962

Have some of you guys blocked me or what? lol

@storm.continuity, no it doesn't build on the 5.8.1 kernel.

What steps did you do in order to successfully apply the patch?

Below patch applies on zfs-dkms 0.8.4-1, and runs fine (Only difference from the other patches is kernel-kmem.m4 didn't exist and thus had to be created)

From c5c63099a9d55889b815338e480e6c63e777a6cb Mon Sep 17 00:00:00 2001
From: Chirayu Desai <chirayudesai1@gmail.com>
Date: Wed, 19 Aug 2020 19:22:14 +0530
Subject: [PATCH] 5.8

---
 BACKPORT-Linux-5.8-compat-__vmalloc.patch | 152 ++++++++++++++++++++++
 PKGBUILD                                  |  10 +-
 2 files changed, 159 insertions(+), 3 deletions(-)
 create mode 100644 BACKPORT-Linux-5.8-compat-__vmalloc.patch

diff --git a/BACKPORT-Linux-5.8-compat-__vmalloc.patch b/BACKPORT-Linux-5.8-compat-__vmalloc.patch
new file mode 100644
index 0000000000..a58fb6377e
--- /dev/null
+++ b/BACKPORT-Linux-5.8-compat-__vmalloc.patch
@@ -0,0 +1,152 @@
+From 6cc95288ccea12ad7b67b2b5b3997dfad8e5b5c9 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Michael=20Niew=C3=B6hner?=
+ <c0d3z3r0@users.noreply.github.com>
+Date: Tue, 9 Jun 2020 01:32:02 +0200
+Subject: [PATCH] BACKPORT: Linux 5.8 compat: __vmalloc()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The `pgprot` argument has been removed from `__vmalloc` in Linux 5.8,
+being `PAGE_KERNEL` always now [1].
+
+Detect this during configure and define a wrapper for older kernels.
+
+[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/vmalloc.c?h=next-20200605&id=88dca4ca5a93d2c09e5bbc6a62fbfc3af83c4fca
+
+Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
+Co-authored-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
+Co-authored-by: Michael Niewöhner <foss@mniewoehner.de>
+Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
+Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
+Closes #10422
+---
+ config/kernel-kmem.m4       | 26 ++++++++++++++++++++++++++
+ config/kernel.m4            |  2 ++
+ include/spl/sys/kmem.h      |  9 +++++++++
+ module/spl/spl-kmem-cache.c |  4 ++--
+ module/spl/spl-kmem.c       |  9 ++++-----
+ 5 files changed, 43 insertions(+), 7 deletions(-)
+ create mode 100644 config/kernel-kmem.m4
+
+diff --git a/config/kernel-kmem.m4 b/config/kernel-kmem.m4
+new file mode 100644
+index 0000000000..f1c0d2412
+--- /dev/null
++++ b/config/kernel-kmem.m4
+@@ -0,0 +1,25 @@
++dnl #
++dnl # 5.8 API,
++dnl # __vmalloc PAGE_KERNEL removal
++dnl #
++AC_DEFUN([ZFS_AC_KERNEL_SRC_VMALLOC_PAGE_KERNEL], [
++  ZFS_LINUX_TEST_SRC([__vmalloc], [
++      #include <linux/mm.h>
++      #include <linux/vmalloc.h>
++  ],[
++      void *p __attribute__ ((unused));
++
++      p = __vmalloc(0, GFP_KERNEL, PAGE_KERNEL);
++  ])
++])
++
++AC_DEFUN([ZFS_AC_KERNEL_VMALLOC_PAGE_KERNEL], [
++  AC_MSG_CHECKING([whether __vmalloc(ptr, flags, pageflags) is available])
++  ZFS_LINUX_TEST_RESULT([__vmalloc], [
++      AC_MSG_RESULT(yes)
++      AC_DEFINE(HAVE_VMALLOC_PAGE_KERNEL, 1, [__vmalloc page flags exists])
++  ],[
++      AC_MSG_RESULT(no)
++  ])
++])
++-
+diff --git a/config/kernel.m4 b/config/kernel.m4
+index b67fcef8c..23edfdcd8 100644
+--- a/config/kernel.m4
++++ b/config/kernel.m4
+@@ -45,6 +45,7 @@ AC_DEFUN([ZFS_AC_KERNEL_TEST_SRC], [
+   ZFS_AC_KERNEL_SRC_SCHED
+   ZFS_AC_KERNEL_SRC_USLEEP_RANGE
+   ZFS_AC_KERNEL_SRC_KMEM_CACHE
++  ZFS_AC_KERNEL_SRC_VMALLOC_PAGE_KERNEL
+   ZFS_AC_KERNEL_SRC_WAIT
+   ZFS_AC_KERNEL_SRC_INODE_TIMES
+   ZFS_AC_KERNEL_SRC_INODE_LOCK
+@@ -163,6 +164,7 @@ AC_DEFUN([ZFS_AC_KERNEL_TEST_RESULT], [
+   ZFS_AC_KERNEL_SCHED
+   ZFS_AC_KERNEL_USLEEP_RANGE
+   ZFS_AC_KERNEL_KMEM_CACHE
++  ZFS_AC_KERNEL_VMALLOC_PAGE_KERNEL
+   ZFS_AC_KERNEL_WAIT
+   ZFS_AC_KERNEL_INODE_TIMES
+   ZFS_AC_KERNEL_INODE_LOCK
+diff --git a/include/spl/sys/kmem.h b/include/spl/sys/kmem.h
+index 72d3a7765..ca15bfe7f 100644
+--- a/include/spl/sys/kmem.h
++++ b/include/spl/sys/kmem.h
+@@ -169,6 +169,15 @@ extern void *spl_kmem_alloc(size_t sz, int fl, const char *func, int line);
+ extern void *spl_kmem_zalloc(size_t sz, int fl, const char *func, int line);
+ extern void spl_kmem_free(const void *ptr, size_t sz);
+ 
++/*
++ * 5.8 API change, pgprot_t argument removed.
++ */
++#ifdef HAVE_VMALLOC_PAGE_KERNEL
++#define   spl_vmalloc(size, flags)    __vmalloc(size, flags, PAGE_KERNEL)
++#else
++#define   spl_vmalloc(size, flags)    __vmalloc(size, flags)
++#endif
++
+ /*
+  * The following functions are only available for internal use.
+  */
+diff --git a/module/spl/spl-kmem-cache.c b/module/spl/spl-kmem-cache.c
+index d71b4b348..4866b2993 100644
+--- a/module/spl/spl-kmem-cache.c
++++ b/module/spl/spl-kmem-cache.c
+@@ -203,7 +203,7 @@ kv_alloc(spl_kmem_cache_t *skc, int size, int flags)
+       ASSERT(ISP2(size));
+       ptr = (void *)__get_free_pages(lflags, get_order(size));
+   } else {
+-      ptr = __vmalloc(size, lflags | __GFP_HIGHMEM, PAGE_KERNEL);
++      ptr = spl_vmalloc(size, lflags | __GFP_HIGHMEM);
+   }
+ 
+   /* Resulting allocated memory will be page aligned */
+@@ -1242,7 +1242,7 @@ spl_cache_grow(spl_kmem_cache_t *skc, int flags, void **obj)
+    * allocation.
+    *
+    * However, this can't be applied to KVM_VMEM due to a bug that
+-   * __vmalloc() doesn't honor gfp flags in page table allocation.
++   * spl_vmalloc() doesn't honor gfp flags in page table allocation.
+    */
+   if (!(skc->skc_flags & KMC_VMEM)) {
+       rc = __spl_cache_grow(skc, flags | KM_NOSLEEP);
+diff --git a/module/spl/spl-kmem.c b/module/spl/spl-kmem.c
+index cee69ad43..ca1fc145f 100644
+--- a/module/spl/spl-kmem.c
++++ b/module/spl/spl-kmem.c
+@@ -172,16 +172,15 @@ spl_kmem_alloc_impl(size_t size, int flags, int node)
+        * kmem_zalloc() callers.
+        *
+        * For vmem_alloc() and vmem_zalloc() callers it is permissible
+-       * to use __vmalloc().  However, in general use of __vmalloc()
+-       * is strongly discouraged because a global lock must be
+-       * acquired.  Contention on this lock can significantly
++       * to use spl_vmalloc().  However, in general use of
++       * spl_vmalloc() is strongly discouraged because a global lock
++       * must be acquired.  Contention on this lock can significantly
+        * impact performance so frequently manipulating the virtual
+        * address space is strongly discouraged.
+        */
+       if ((size > spl_kmem_alloc_max) || use_vmem) {
+           if (flags & KM_VMEM) {
+-              ptr = __vmalloc(size, lflags | __GFP_HIGHMEM,
+-                  PAGE_KERNEL);
++              ptr = spl_vmalloc(size, lflags | __GFP_HIGHMEM);
+           } else {
+               return (NULL);
+           }
+-- 
+2.25.1
+
diff --git a/PKGBUILD b/PKGBUILD
index f44d677adb..9d84d68937 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -16,13 +16,16 @@ provides=("ZFS-MODULE=${pkgver}" "SPL-MODULE=${pkgver}" 'spl-dkms')
 provides+=('zfs')
 replaces=('spl-dkms')
 source=("https://github.com/zfsonlinux/zfs/releases/download/zfs-${pkgver}/zfs-${pkgver}.tar.gz"{,.asc}
-        "0001-only-build-the-module-in-dkms.conf.patch")
+        "0001-only-build-the-module-in-dkms.conf.patch"
+        "BACKPORT-Linux-5.8-compat-__vmalloc.patch")
 sha256sums=('2b988f5777976f09d08083f6bebf6e67219c4c4c183c1f33033fb7e5e5eacafb'
             'SKIP'
-            '780e590383fb00389c5e02ac15709b7a476d9e07d3c4935ed9eb67c951a88409')
+            '780e590383fb00389c5e02ac15709b7a476d9e07d3c4935ed9eb67c951a88409'
+            '7441f67d50542b9197c722c6d1b37bb28493c5b478094708eeae927d3e5bb947')
 b2sums=('776bcd6dfab8825c07d315085e288b29bf543d6957325d5d566b7b78c04505dde9bd25eb6684cb4a1b6a657de8a4e1290d04d2b9079d26d6b834a70f1ec3b569'
         'SKIP'
-        '1fdae935043d979b9241f07f8baa25a9a0367c24c31c84a59dfe8d6b468a523d8f49b68da3c7fd3194db6638f9d7bef046fc5e2669ce25d73c65009c16bf6c50')
+        '1fdae935043d979b9241f07f8baa25a9a0367c24c31c84a59dfe8d6b468a523d8f49b68da3c7fd3194db6638f9d7bef046fc5e2669ce25d73c65009c16bf6c50'
+   '795a9db25e5697b0c57dc69dbe192434a7dbcfadfe940f7c5e3cca23c37eb57dae0eeeae0b173fa1329778acaf0d8b333b6183ef84075921968439067db64db8')
 validpgpkeys=('4F3BA9AB6D1F8D683DC2DFB56AD860EED4598027'  # Tony Hutter (GPG key for signing ZFS releases) <hutter2@llnl.gov>
               'C33DF142657ED1F7C328A2960AB9E991C6AF658B') # Brian Behlendorf <behlendorf1@llnl.gov>

@@ -30,6 +33,7 @@ prepare() {
     cd "${srcdir}"/${pkgname%-dkms}-${pkgver}

     patch -p1 -i ../0001-only-build-the-module-in-dkms.conf.patch
+    patch -p1 -i ../BACKPORT-Linux-5.8-compat-__vmalloc.patch

     # remove unneeded sections from module build
     sed -ri "/AC_CONFIG_FILES/,/]\)/{
-- 
2.28.0

@Utsi, Pardon my ignorance but... does it mean it should build now with a 5.8.1 kernel? Because as of today i still have the issue.

Haha, well this is embarrassing. Flagged the package and included the pull request patch which was submitted by eschwartz to the ZFS GitHub page.

Apologies, I physically blushed when I saw what I did, haha. Unflagged it :)

The build fails, we need the patch merged.

==> dkms install --no-depmod -m zfs -v 0.8.4 -k 5.8.1-arch1-1
Error! Bad return status for module build on kernel: 5.8.1-arch1-1 (x86_64)
Consult /var/lib/dkms/zfs/0.8.4/build/make.log for more information.
==> Warning, `dkms install --no-depmod -m zfs -v 0.8.4 -k 5.8.1-arch1-1' returned 10
==> depmod 5.8.1-arch1-1

The log shows..

make[1]: *** [Makefile:1756: /var/lib/dkms/zfs/0.8.4/build/module] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.8.1-arch1-1/build'
make: *** [Makefile:30: modules] Error 2
make: Leaving directory '/var/lib/dkms/zfs/0.8.4/build/module'

https://github.com/rtreffer/nixpkgs/blob/08566523d88cc6fb266f7d9baa01b94b6503be95/pkgs/os-specific/linux/zfs/BACKPORT-Linux-5.8-compat-__vmalloc.patch suggested by @FrederickZh works just fine on top of current patches for 5.8 kernel.

This build fails with the 5.8 kernel due to the vmalloc function changing. Can we merge in the patch suggested by @FrederickZh

Copied Linux 5.8 patch from NixOS:

diff --git a/0003-fix-5.8-build.patch b/0003-fix-5.8-build.patch
new file mode 100644
index 0000000..780ce83
--- /dev/null
+++ b/0003-fix-5.8-build.patch
@@ -0,0 +1,154 @@
+From 6cc95288ccea12ad7b67b2b5b3997dfad8e5b5c9 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Michael=20Niew=C3=B6hner?=
+ <c0d3z3r0@users.noreply.github.com>
+Date: Tue, 9 Jun 2020 01:32:02 +0200
+Subject: [PATCH] BACKPORT: Linux 5.8 compat: __vmalloc()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The `pgprot` argument has been removed from `__vmalloc` in Linux 5.8,
+being `PAGE_KERNEL` always now [1].
+
+Detect this during configure and define a wrapper for older kernels.
+
+[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/vmalloc.c?h=next-20200605&id=88dca4ca5a93d2c09e5bbc6a62fbfc3af83c4fca
+
+Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
+Co-authored-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
+Co-authored-by: Michael Niewöhner <foss@mniewoehner.de>
+Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
+Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
+Closes #10422
+---
+ config/kernel-kmem.m4       | 26 ++++++++++++++++++++++++++
+ config/kernel.m4            |  2 ++
+ include/spl/sys/kmem.h      |  9 +++++++++
+ module/spl/spl-kmem-cache.c |  4 ++--
+ module/spl/spl-kmem.c       |  9 ++++-----
+ 5 files changed, 43 insertions(+), 7 deletions(-)
+
+diff --git a/config/kernel-kmem.m4 b/config/kernel-kmem.m4
+index cc055e530..f1c0d2412 100644
+--- a/config/kernel-kmem.m4
++++ b/config/kernel-kmem.m4
+@@ -56,3 +56,29 @@ AC_DEFUN([SPL_AC_DEBUG_KMEM_TRACKING], [
+   AC_MSG_CHECKING([whether detailed kmem tracking is enabled])
+   AC_MSG_RESULT([$enable_debug_kmem_tracking])
+ ])
++
++dnl #
++dnl # 5.8 API,
++dnl # __vmalloc PAGE_KERNEL removal
++dnl #
++AC_DEFUN([ZFS_AC_KERNEL_SRC_VMALLOC_PAGE_KERNEL], [
++  ZFS_LINUX_TEST_SRC([__vmalloc], [
++      #include <linux/mm.h>
++      #include <linux/vmalloc.h>
++  ],[
++      void *p __attribute__ ((unused));
++
++      p = __vmalloc(0, GFP_KERNEL, PAGE_KERNEL);
++  ])
++])
++
++AC_DEFUN([ZFS_AC_KERNEL_VMALLOC_PAGE_KERNEL], [
++  AC_MSG_CHECKING([whether __vmalloc(ptr, flags, pageflags) is available])
++  ZFS_LINUX_TEST_RESULT([__vmalloc], [
++      AC_MSG_RESULT(yes)
++      AC_DEFINE(HAVE_VMALLOC_PAGE_KERNEL, 1, [__vmalloc page flags exists])
++  ],[
++      AC_MSG_RESULT(no)
++  ])
++])
++-
+diff --git a/config/kernel.m4 b/config/kernel.m4
+index b67fcef8c..23edfdcd8 100644
+--- a/config/kernel.m4
++++ b/config/kernel.m4
+@@ -45,6 +45,7 @@ AC_DEFUN([ZFS_AC_KERNEL_TEST_SRC], [
+   ZFS_AC_KERNEL_SRC_SCHED
+   ZFS_AC_KERNEL_SRC_USLEEP_RANGE
+   ZFS_AC_KERNEL_SRC_KMEM_CACHE
++  ZFS_AC_KERNEL_SRC_VMALLOC_PAGE_KERNEL
+   ZFS_AC_KERNEL_SRC_WAIT
+   ZFS_AC_KERNEL_SRC_INODE_TIMES
+   ZFS_AC_KERNEL_SRC_INODE_LOCK
+@@ -163,6 +164,7 @@ AC_DEFUN([ZFS_AC_KERNEL_TEST_RESULT], [
+   ZFS_AC_KERNEL_SCHED
+   ZFS_AC_KERNEL_USLEEP_RANGE
+   ZFS_AC_KERNEL_KMEM_CACHE
++  ZFS_AC_KERNEL_VMALLOC_PAGE_KERNEL
+   ZFS_AC_KERNEL_WAIT
+   ZFS_AC_KERNEL_INODE_TIMES
+   ZFS_AC_KERNEL_INODE_LOCK
+diff --git a/include/spl/sys/kmem.h b/include/spl/sys/kmem.h
+index 72d3a7765..ca15bfe7f 100644
+--- a/include/spl/sys/kmem.h
++++ b/include/spl/sys/kmem.h
+@@ -169,6 +169,15 @@ extern void *spl_kmem_alloc(size_t sz, int fl, const char *func, int line);
+ extern void *spl_kmem_zalloc(size_t sz, int fl, const char *func, int line);
+ extern void spl_kmem_free(const void *ptr, size_t sz);
+ 
++/*
++ * 5.8 API change, pgprot_t argument removed.
++ */
++#ifdef HAVE_VMALLOC_PAGE_KERNEL
++#define   spl_vmalloc(size, flags)    __vmalloc(size, flags, PAGE_KERNEL)
++#else
++#define   spl_vmalloc(size, flags)    __vmalloc(size, flags)
++#endif
++
+ /*
+  * The following functions are only available for internal use.
+  */
+diff --git a/module/spl/spl-kmem-cache.c b/module/spl/spl-kmem-cache.c
+index d71b4b348..4866b2993 100644
+--- a/module/spl/spl-kmem-cache.c
++++ b/module/spl/spl-kmem-cache.c
+@@ -203,7 +203,7 @@ kv_alloc(spl_kmem_cache_t *skc, int size, int flags)
+       ASSERT(ISP2(size));
+       ptr = (void *)__get_free_pages(lflags, get_order(size));
+   } else {
+-      ptr = __vmalloc(size, lflags | __GFP_HIGHMEM, PAGE_KERNEL);
++      ptr = spl_vmalloc(size, lflags | __GFP_HIGHMEM);
+   }
+ 
+   /* Resulting allocated memory will be page aligned */
+@@ -1242,7 +1242,7 @@ spl_cache_grow(spl_kmem_cache_t *skc, int flags, void **obj)
+    * allocation.
+    *
+    * However, this can't be applied to KVM_VMEM due to a bug that
+-   * __vmalloc() doesn't honor gfp flags in page table allocation.
++   * spl_vmalloc() doesn't honor gfp flags in page table allocation.
+    */
+   if (!(skc->skc_flags & KMC_VMEM)) {
+       rc = __spl_cache_grow(skc, flags | KM_NOSLEEP);
+diff --git a/module/spl/spl-kmem.c b/module/spl/spl-kmem.c
+index cee69ad43..ca1fc145f 100644
+--- a/module/spl/spl-kmem.c
++++ b/module/spl/spl-kmem.c
+@@ -172,16 +172,15 @@ spl_kmem_alloc_impl(size_t size, int flags, int node)
+        * kmem_zalloc() callers.
+        *
+        * For vmem_alloc() and vmem_zalloc() callers it is permissible
+-       * to use __vmalloc().  However, in general use of __vmalloc()
+-       * is strongly discouraged because a global lock must be
+-       * acquired.  Contention on this lock can significantly
++       * to use spl_vmalloc().  However, in general use of
++       * spl_vmalloc() is strongly discouraged because a global lock
++       * must be acquired.  Contention on this lock can significantly
+        * impact performance so frequently manipulating the virtual
+        * address space is strongly discouraged.
+        */
+       if ((size > spl_kmem_alloc_max) || use_vmem) {
+           if (flags & KM_VMEM) {
+-              ptr = __vmalloc(size, lflags | __GFP_HIGHMEM,
+-                  PAGE_KERNEL);
++              ptr = spl_vmalloc(size, lflags | __GFP_HIGHMEM);
+           } else {
+               return (NULL);
+           }
+-- 
+2.25.1
+
diff --git a/0003-kernel-kmem.m4 b/0003-kernel-kmem.m4
new file mode 100644
index 0000000..cc055e5
--- /dev/null
+++ b/0003-kernel-kmem.m4
@@ -0,0 +1,58 @@
+dnl #
+dnl # Enabled by default it provides a minimal level of memory tracking.
+dnl # A total count of bytes allocated is kept for each alloc and free.
+dnl # Then at module unload time a report to the console will be printed
+dnl # if memory was leaked.
+dnl #
+AC_DEFUN([SPL_AC_DEBUG_KMEM], [
+   AC_ARG_ENABLE([debug-kmem],
+       [AS_HELP_STRING([--enable-debug-kmem],
+       [Enable basic kmem accounting @<:@default=no@:>@])],
+       [],
+       [enable_debug_kmem=no])
+
+   AS_IF([test "x$enable_debug_kmem" = xyes],
+   [
+       KERNELCPPFLAGS="${KERNELCPPFLAGS} -DDEBUG_KMEM"
+       DEBUG_KMEM="_with_debug_kmem"
+       AC_DEFINE([DEBUG_KMEM], [1],
+       [Define to 1 to enable basic kmem accounting])
+   ], [
+       DEBUG_KMEM="_without_debug_kmem"
+   ])
+
+   AC_SUBST(DEBUG_KMEM)
+   AC_MSG_CHECKING([whether basic kmem accounting is enabled])
+   AC_MSG_RESULT([$enable_debug_kmem])
+])
+
+dnl #
+dnl # Disabled by default it provides detailed memory tracking.  This
+dnl # feature also requires --enable-debug-kmem to be set.  When enabled
+dnl # not only will total bytes be tracked but also the location of every
+dnl # alloc and free.  When the SPL module is unloaded a list of all leaked
+dnl # addresses and where they were allocated will be dumped to the console.
+dnl # Enabling this feature has a significant impact on performance but it
+dnl # makes finding memory leaks pretty straight forward.
+dnl #
+AC_DEFUN([SPL_AC_DEBUG_KMEM_TRACKING], [
+   AC_ARG_ENABLE([debug-kmem-tracking],
+       [AS_HELP_STRING([--enable-debug-kmem-tracking],
+       [Enable detailed kmem tracking  @<:@default=no@:>@])],
+       [],
+       [enable_debug_kmem_tracking=no])
+
+   AS_IF([test "x$enable_debug_kmem_tracking" = xyes],
+   [
+       KERNELCPPFLAGS="${KERNELCPPFLAGS} -DDEBUG_KMEM_TRACKING"
+       DEBUG_KMEM_TRACKING="_with_debug_kmem_tracking"
+       AC_DEFINE([DEBUG_KMEM_TRACKING], [1],
+       [Define to 1 to enable detailed kmem tracking])
+   ], [
+       DEBUG_KMEM_TRACKING="_without_debug_kmem_tracking"
+   ])
+
+   AC_SUBST(DEBUG_KMEM_TRACKING)
+   AC_MSG_CHECKING([whether detailed kmem tracking is enabled])
+   AC_MSG_RESULT([$enable_debug_kmem_tracking])
+])
diff --git a/PKGBUILD b/PKGBUILD
index f44d677..4638484 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -15,22 +15,30 @@ provides=("ZFS-MODULE=${pkgver}" "SPL-MODULE=${pkgver}" 'spl-dkms')
 # ambiguous, provided for backwards compat, pls don't use
 provides+=('zfs')
 replaces=('spl-dkms')
 source=("https://github.com/zfsonlinux/zfs/releases/download/zfs-${pkgver}/zfs-${pkgver}.tar.gz"{,.asc}
-        "0001-only-build-the-module-in-dkms.conf.patch")
+        "0001-only-build-the-module-in-dkms.conf.patch"
+        "0003-fix-5.8-build.patch"
+        "0003-kernel-kmem.m4")
 sha256sums=('2b988f5777976f09d08083f6bebf6e67219c4c4c183c1f33033fb7e5e5eacafb'
             'SKIP'
-            '780e590383fb00389c5e02ac15709b7a476d9e07d3c4935ed9eb67c951a88409')
+            '780e590383fb00389c5e02ac15709b7a476d9e07d3c4935ed9eb67c951a88409'
+            '4af22c91cc5ca2db2dd591cefd9b7ad7e7c7aeb35fd7831bcfdfbf3c621ba83b'
+            '666b6a7e83647f3fd815885aa4e36f5eaf0da2d8ff3d7e4fdaae03150c074676')
 b2sums=('776bcd6dfab8825c07d315085e288b29bf543d6957325d5d566b7b78c04505dde9bd25eb6684cb4a1b6a657de8a4e1290d04d2b9079d26d6b834a70f1ec3b569'
         'SKIP'
-        '1fdae935043d979b9241f07f8baa25a9a0367c24c31c84a59dfe8d6b468a523d8f49b68da3c7fd3194db6638f9d7bef046fc5e2669ce25d73c65009c16bf6c50')
+        '1fdae935043d979b9241f07f8baa25a9a0367c24c31c84a59dfe8d6b468a523d8f49b68da3c7fd3194db6638f9d7bef046fc5e2669ce25d73c65009c16bf6c50'
+        '93b60f36747a50d613ee018684ad7191ef5b08e001559d110770a78f280d2d7d591ea996e5cd287bb97bdf6237728d74897eb67d2e99ddcc4e91f8aa3ab9a61b'
+        '6df8980d529a0d5adf4a7dfb33f0838bcf2df5677d7d10d1697e89df7fb38facd009571d0312d19714a0e9e8f8f88efc948d832f78e944e5939fe8caff01bf1a')
 validpgpkeys=('4F3BA9AB6D1F8D683DC2DFB56AD860EED4598027'  # Tony Hutter (GPG key for signing ZFS releases) <hutter2@llnl.gov>
               'C33DF142657ED1F7C328A2960AB9E991C6AF658B') # Brian Behlendorf <behlendorf1@llnl.gov>

 prepare() {
     cd "${srcdir}"/${pkgname%-dkms}-${pkgver}

     patch -p1 -i ../0001-only-build-the-module-in-dkms.conf.patch
+    cp ../0003-kernel-kmem.m4 config/kernel-kmem.m4
+    patch -p1 -i ../0003-fix-5.8-build.patch

     # remove unneeded sections from module build
     sed -ri "/AC_CONFIG_FILES/,/]\)/{
 /AC_CONFIG_FILES/n

I'm using archzfs/zfs-dkms and it builds fine for 5.7.2. I would expect aur/zfs-dkms to be equally fine. Have you tried?

Does zfs-dkms 0.8.4-1 build on the latest kernel 5.7.2? Thanks, Anderson

Thanks. I managed to fix it by install zfs-dkms-git instead. Still getting a few weird errors, but at least it works now :)

@sunfisks - pacman -U $(ls /var/cache/pacman/pkg/gcc*-9.3.0-1*)

Question, how did you downgrade gcc?

To build correctly under linux-hardened I needed to downgrade gcc & gcc-libs to 9.3.0-1 - this also applied to nvidia-beta-dkms

I also upgraded to dkms 2.8.1-4 from testing

You can just remove the zfs-dkms and zfs-utils packages, and then reinstall them ...

pacman -R zfs-dkms zfs-utils

yay -S zfs-dkms

@FrederickZh that seems to have worked, thanks! Ran install, restarted and ran zpool status to ensure the pool was still available.
The full command I used was # pacman -U ~/.cache/yay/zfs-dkms/zfs-dkms-0.8.4-1-any.pkg.tar.xz ~/.cache/yay/zfs-utils/zfs-utils-0.8.4-1-x86_64.pkg.tar.xz

As I mentioned you need to upgrade both packages in a single transaction (which is also what the error messages were talking about). Build them first, then [yay|pacman] -U them.

@fryfrog Thanks for your suggestion, unfortunately it had the same result.
@FrederickZh I navigated to ~/.cache/yay/zfs-dkms/ and ran makepkg --install, since yay had already created it.

resolving dependencies...
warning: cannot resolve "zfs-utils=0.8.4", a dependency of "zfs-dkms"
:: The following package cannot be upgraded due to unresolvable dependencies:
      zfs-dkms

:: Do you want to skip the above package for this upgrade? [y/N] N
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'zfs-utils=0.8.4' required by zfs-dkms

No, you have to manually makepkg them since yay by default builds and installs AUR packages one by one instead of building them all then starting a combined installation transaction. Not sure whether this behaviour can be changed or not. Tried yay --combinedupgrade --save but apparently this only changes the 'AUR questions after official repo' behaviour.

Can't you just yay -S zfs-dkms zfs-utils?

Hi all, longtime Arch user but new to the community. I'm trying to upgrade zfs-dkms (0.8.3-3) and zfs-utils (0.8.3-1) using yay, I'm getting the following error

zfs-utils=0.8.4 not satisfied, flushing install queue
[sudo] password for oscar: 
loading packages...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing zfs-utils (0.8.4-1) breaks dependency 'zfs-utils=0.8.3' required by zfs-dkms

How can I resolve this issue and how can I upgrade to the latest version?

Same result when running as root, same uninformative make.log

BUT:

there is an additional line in the output to console that may help:

make -j2 KERNELRELEASE=5.4.39-1-lts -C module/...(bad exist status:2)

Or maybe not

Try rerunning dkms install zfs/0.8.3 -k 5.4.39-1-lts as root to get the full error log.

I cannot install version 0.8.3 on a system running the 5.4.39-1-lts kernel (latest lts kernel as of today).

The initial build process concludes successfully (but see below), then dkms fails with this message:

==> dkms install zfs/0.8.3 -k 5.4.39-1-lts
configure: error: 
        *** Unable to build an empty module.

Error! Bad return status for module build on kernel: 5.4.39-1-lts (x86_64)
Consult /var/lib/dkms/zfs/0.8.3/build/make.log for more information.

The log is not very helpful:

DKMS make.log for zfs-0.8.3 for kernel 5.4.39-1-lts (x86_64)
Mon 11 May 2020 12:45:19 PM CDT
make: Entering directory '/var/lib/dkms/zfs/0.8.3/build/module'
make: *** No targets specified and no makefile found.  Stop.
make: Leaving directory '/var/lib/dkms/zfs/0.8.3/build/module'
/var/lib/dkms/zfs/0.8.3/build/make.log (END)

Perhaps something went wrong earlier in the build process?

(please use markdown to post command output)

"It broke" isn't very useful debug info. If you cannot find the make.log, try rerunning the dkms install ... command in question manually, since it is only the pacman hook that hides the output.

I just updated to 5.6.8 and the kernel modules built fine.

The only thing I did different is, I was on 5.6.8 briefly and then downgraded back to 5.6.7 (testing dracut) a couple of days ago. I have a make.log if anyone might find it interesting.

I'm getting a build error on the latest system update:

==> dkms install zfs/0.8.3 -k 5.6.8-arch1-1
Error! Bad return status for module build on kernel: 5.6.8-arch1-1 (x86_64)
Consult /var/lib/dkms/zfs/0.8.3/build/make.log for more information.

Any suggestions on how to proceed?

The log file does not seem to exist, BTW.

Cheers and good to know about LTS. On a test rig, I released gcc and gcc-libs, did a full update but no newer versions were installed. I took the plunge and upgraded the kernel, rebuilt zfs-dkms with that 5.6 kernel running, rebooted, did a modprobe zfs and all was well. Many thanks to all for the assist.

I think you want to be running the same gcc/glibc that your kernel was built with. Normally, that just means keeping current. I would release gcc and gcc-libs and update. Then update your kernel. Then if zfs-dkms isn't latest, update and let it build for your newly updated kernel.

FWIW, I have both linux and linux-lts installed and my archzfs/zfs-dkms builds just fine.

I get adding the key, really I do :-) It's just that during my testing, on a 5.5 kernel I'm using, I cannot build this with the 'horrible but quick test hack' makepkg --skippgpcheck. On a 5.6 kernel, it builds just fine. This of course might all be me, so I wanted to highlight that when we had the zfs issues with moving to kernel 5.5 from 5.4, I know we had to keep the gcc versions in line with the kernel. Since the 5.6 issue was raised, I've had the follow in my pacman.conf

IgnorePkg=linux linux-headers gcc gcc-libs

As a workaround, I was considering removing zfs-dkms from my 5.5 main desktop as I can just about manage with it in the short term. Then upgrading to 5.6 and finally popping zfs-dkms back in again. I'd prefer to be able to upgrade other, older 5.5 kernel machines without doing those steps, but if that's the best way forward to upgrade, I'm happy to do that. Any thoughts appreciated.

Thanks for the help, in my case I get:

==> Verifying source file signatures with gpg...
    zfs-0.8.3.tar.gz ... FAILED (unknown public key 6AD860EED4598027)
==> ERROR: One or more PGP signatures could not be verified!

If I use --skippgpcheck, the resulting build gives:

libtoolize: copying file 'config/lt~obsolete.m4'
configure:24227: error: possibly undefined macro: 
ZFS_AC_KERNEL_SRC_BLKG_TRYGET
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure:41387: error: possibly undefined macro: ZFS_AC_KERNEL_BLKG_TRYGET
autoreconf: /usr/bin/autoconf failed with exit status: 1
==> ERROR: A failure occurred in prepare().
Aborting...

This is with 5.5.13-arch2-1 that is up to date.

@ck2katAUR - zfs working fine for me in 5.6.3.a-1-hardened

@eschwartz; Thank you for your comment. Based on this I've just done a; git pull and a; makepkg with linux-hardened 5.6.3.a-1. No errors were reported and now my server is back in action again. @itoffshore and @fryfrog; Thank you also for your comments. Recognising and respecting eschwartz as the maintainer of this package, I waited for his words before trying anything. Kernel version 5.6.4 and its varieties are evidently coming through the repo system as I write. I will check for comments here (hopefully indicating OK) before upgrading again.

@dmshimself: The package builds fine. Are you encountering this error? https://aur.archlinux.org/packages/zfs-dkms/?O=10&PP=10#comment-735021

I'm getting a PGP check failure when trying to apply a makepkg

Thanks for your patience! I grabbed a few minutes and tested this PR (which was tremendously helpful as I didn't have time to devote to it myself), the patch matches up to upstream stuff, everything checks out and the result builds cleanly.

Pushed.

Eli is on vacation. In the mean time, I've created a PR with a working patch (I have in production for 5 days now). https://github.com/eli-schwartz/pkgbuilds/pull/14

@ck2katAUR: Did you look at the two .patch files that get applied to make it compatible w/ 5.6.x?

@ck2katAUR - 5.6 support working OK in zfs-dkms 0.8.3-3 - thank you ;o)

@eschwartz I would be grateful if you could issue any news you have about making zfs-dkms compatible with the latest Arch kernel version (5.6.3.a-1-hardened in my case). Thank you

Looks like archzfs/zfs-dkms is also patching to fix it on 5.6.

There is a patch available on GitHub posted by satmandu. Here is the patch I made for this package. I tested it on linux-zen 5.6.2 and it seems alright so far.

diff --git a/.SRCINFO b/.SRCINFO
index b283878..1e00c5a 100644
--- a/.SRCINFO
+++ b/.SRCINFO
@@ -1,8 +1,8 @@
 pkgbase = zfs-dkms
    pkgdesc = Kernel modules for the Zettabyte File System.
    pkgver = 0.8.3
-   pkgrel = 2
+   pkgrel = 3
    url = https://zfsonlinux.org/
    arch = any
    license = CDDL
    provides = ZFS-MODULE=0.8.3
@@ -14,18 +14,21 @@ pkgbase = zfs-dkms
    source = https://github.com/zfsonlinux/zfs/releases/download/zfs-0.8.3/zfs-0.8.3.tar.gz
    source = https://github.com/zfsonlinux/zfs/releases/download/zfs-0.8.3/zfs-0.8.3.tar.gz.asc
    source = https://github.com/openzfs/zfs/commit/2fcab8795c7c493845bfa277d44bc443802000b8.patch
    source = 0001-only-build-the-module-in-dkms.conf.patch
+   source = 0001-Linux-5.6-compat.patch
    validpgpkeys = 4F3BA9AB6D1F8D683DC2DFB56AD860EED4598027
    validpgpkeys = C33DF142657ED1F7C328A2960AB9E991C6AF658B
    sha256sums = 545a4897ce30c2d2dd9010a0fdb600a0d3d45805e2387093c473efc03aa9d7fd
    sha256sums = SKIP
    sha256sums = daae58460243c45c2c7505b1d88dcb299ea7d92bcf3f41d2d30bc213000bb1da
    sha256sums = 780e590383fb00389c5e02ac15709b7a476d9e07d3c4935ed9eb67c951a88409
+   sha256sums = 7b68be97c053fc8501ef78969d0aec247de280de2119da8d7e52918ff94fd490
    b2sums = 8b51b9d5b61543566bc7839d8452fdf9358442155e95f93a011531338824bbd4fc8879500e276b02d5d49d504a046728ecc0c6154f69eb7b47180b9bb0e46958
    b2sums = SKIP
    b2sums = d221881cd4c1edc0af010343b34c941ec8bf11bf34378eef09bb5152d442f0552a527f46105ace2af76dd4b2ff4ad93d6f39fd1be3f42ccda837d0208d7f4365
    b2sums = 1fdae935043d979b9241f07f8baa25a9a0367c24c31c84a59dfe8d6b468a523d8f49b68da3c7fd3194db6638f9d7bef046fc5e2669ce25d73c65009c16bf6c50
+   b2sums = 653ade0e6640ffa355763137363b3e690147410aaaa66d63b75ff73558021cf33bf8eebf478aa86a903e26f7bf41a6f18a4e08f84ce95b8fa3e9db00c060fb37

 pkgname = zfs-dkms
    depends = zfs-utils=0.8.3
    depends = dkms
diff --git a/PKGBUILD b/PKGBUILD
index e1ee480..44ae06a 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -4,9 +4,9 @@
 # All my PKGBUILDs are managed at https://github.com/eli-schwartz/pkgbuilds

 pkgname=zfs-dkms
 pkgver=0.8.3
-pkgrel=2
+pkgrel=3
 pkgdesc="Kernel modules for the Zettabyte File System."
 arch=('any')
 url="https://zfsonlinux.org/"
 license=('CDDL')
@@ -16,17 +16,20 @@ provides=("ZFS-MODULE=${pkgver}" "SPL-MODULE=${pkgver}" 'spl-dkms')
 provides+=('zfs')
 replaces=('spl-dkms')
 source=("https://github.com/zfsonlinux/zfs/releases/download/zfs-${pkgver}/zfs-${pkgver}.tar.gz"{,.asc}
         "https://github.com/openzfs/zfs/commit/2fcab8795c7c493845bfa277d44bc443802000b8.patch"
-        "0001-only-build-the-module-in-dkms.conf.patch")
+        "0001-only-build-the-module-in-dkms.conf.patch"
+        "0001-Linux-5.6-compat-zfs-0.8.3.patch::https://gist.githubusercontent.com/satmandu/67cbae9c4d461be0e64428a1707aef1c/raw/ba0fb65f17ccce5b710e4ce86a095de577f7dfe1/k5.6.3.patch")
 sha256sums=('545a4897ce30c2d2dd9010a0fdb600a0d3d45805e2387093c473efc03aa9d7fd'
             'SKIP'
             'daae58460243c45c2c7505b1d88dcb299ea7d92bcf3f41d2d30bc213000bb1da'
-            '780e590383fb00389c5e02ac15709b7a476d9e07d3c4935ed9eb67c951a88409')
+            '780e590383fb00389c5e02ac15709b7a476d9e07d3c4935ed9eb67c951a88409'
+            '7b68be97c053fc8501ef78969d0aec247de280de2119da8d7e52918ff94fd490')
 b2sums=('8b51b9d5b61543566bc7839d8452fdf9358442155e95f93a011531338824bbd4fc8879500e276b02d5d49d504a046728ecc0c6154f69eb7b47180b9bb0e46958'
         'SKIP'
         'd221881cd4c1edc0af010343b34c941ec8bf11bf34378eef09bb5152d442f0552a527f46105ace2af76dd4b2ff4ad93d6f39fd1be3f42ccda837d0208d7f4365'
-        '1fdae935043d979b9241f07f8baa25a9a0367c24c31c84a59dfe8d6b468a523d8f49b68da3c7fd3194db6638f9d7bef046fc5e2669ce25d73c65009c16bf6c50')
+        '1fdae935043d979b9241f07f8baa25a9a0367c24c31c84a59dfe8d6b468a523d8f49b68da3c7fd3194db6638f9d7bef046fc5e2669ce25d73c65009c16bf6c50'
+        '653ade0e6640ffa355763137363b3e690147410aaaa66d63b75ff73558021cf33bf8eebf478aa86a903e26f7bf41a6f18a4e08f84ce95b8fa3e9db00c060fb37')
 validpgpkeys=('4F3BA9AB6D1F8D683DC2DFB56AD860EED4598027'  # Tony Hutter (GPG key for signing ZFS releases) <hutter2@llnl.gov>
               'C33DF142657ED1F7C328A2960AB9E991C6AF658B') # Brian Behlendorf <behlendorf1@llnl.gov>

 prepare() {
@@ -36,8 +39,10 @@ prepare() {
     patch -p1 -i ../2fcab8795c7c493845bfa277d44bc443802000b8.patch

     patch -p1 -i ../0001-only-build-the-module-in-dkms.conf.patch

+    patch -p1 -i ../0001-Linux-5.6-compat-zfs-0.8.3.patch
+
     # remove unneeded sections from module build
     sed -ri "/AC_CONFIG_FILES/,/]\)/{
 /AC_CONFIG_FILES/n
 /]\)/n

Package linux-5.6.2 has just been released.

Unfortunately, this release again breaks build of zfs-dkms:

    DKMS make.log for zfs-0.8.3 for kernel 5.6.2-arch1-2 (x86_64)
    Mo 6. Apr 21:28:55 CEST 2020
    make: Verzeichnis „/var/lib/dkms/zfs/0.8.3/build/module“ wird betreten
    list='icp lua'; for targetdir in $list; do \
            make -C $targetdir; \
    done
    make[1]: Verzeichnis „/var/lib/dkms/zfs/0.8.3/build/module/icp“ wird betreten
    mkdir -p api core spi io os algs algs/aes algs/edonr algs/modes algs/sha1 algs/sha2 algs/skein asm-x86_64 asm-x86_64/aes asm-x86_64/modes asm-x86_64/sha1 asm-x86_64/sha2 asm-i386 asm-generic
    make[1]: Verzeichnis „/var/lib/dkms/zfs/0.8.3/build/module/icp“ wird verlassen
    make[1]: Verzeichnis „/var/lib/dkms/zfs/0.8.3/build/module/lua“ wird betreten
    mkdir -p setjmp
    make[1]: Verzeichnis „/var/lib/dkms/zfs/0.8.3/build/module/lua“ wird verlassen
    make -C /usr/lib/modules/5.6.2-arch1-2/build M=`pwd`  CONFIG_ZFS=m modules
    make[1]: Verzeichnis „/usr/lib/modules/5.6.2-arch1-2/build“ wird betreten
      CC [M]  /var/lib/dkms/zfs/0.8.3/build/module/avl/avl.o
      CC [M]  /var/lib/dkms/zfs/0.8.3/build/module/lua/lapi.o
      CC [M]  /var/lib/dkms/zfs/0.8.3/build/module/nvpair/nvpair.o
      CC [M]  /var/lib/dkms/zfs/0.8.3/build/module/icp/illumos-crypto.o
    In Datei, eingebunden von /var/lib/dkms/zfs/0.8.3/build/include/sys/nvpair.h:30,
                     von /var/lib/dkms/zfs/0.8.3/build/module/nvpair/nvpair.c:30:
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h:88:15: Fehler: unbekannter Typname: »time_t«
       88 | static inline time_t
          |               ^~~~~~
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h: In Funktion »gethrtime«:
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h:108:18: Fehler: Speichergröße von »ts« ist unbekannt
      108 |  struct timespec ts; 
          |                  ^~  
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h:109:2: Fehler: Implizite Deklaration der Funktion »getrawmonotonic« [-Werror=implicit-function-declaration]
      109 |  getrawmonotonic(&ts);
          |  ^~~~~~~~~~~~~~~
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h:108:18: Warnung: Variable »ts« wird nicht verwendet [-Wunused-variable]
      108 |  struct timespec ts; 
          |                  ^~  
      LD [M]  /var/lib/dkms/zfs/0.8.3/build/module/avl/zavl.o
      CC [M]  /var/lib/dkms/zfs/0.8.3/build/module/icp/api/kcf_cipher.o
    In Datei, eingebunden von /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/condvar.h:33,
                     von /var/lib/dkms/zfs/0.8.3/build/include/sys/zfs_context.h:38,
                     von /var/lib/dkms/zfs/0.8.3/build/include/sys/lua/lua.h:13,
                     von /var/lib/dkms/zfs/0.8.3/build/module/lua/lapi.c:12:
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h:88:15: Fehler: unbekannter Typname: »time_t«
       88 | static inline time_t
          |               ^~~~~~
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h: In Funktion »gethrtime«:
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h:108:18: Fehler: Speichergröße von »ts« ist unbekannt
      108 |  struct timespec ts; 
          |                  ^~  
    In Datei, eingebunden von /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/condvar.h:33,
                     von /var/lib/dkms/zfs/0.8.3/build/include/sys/zfs_context.h:38,
                     von /var/lib/dkms/zfs/0.8.3/build/include/sys/crypto/common.h:39,
                     von /var/lib/dkms/zfs/0.8.3/build/module/icp/illumos-crypto.c:35:
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h:88:15: Fehler: unbekannter Typname: »time_t«
       88 | static inline time_t
          |               ^~~~~~
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h: In Funktion »gethrtime«:
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h:108:18: Fehler: Speichergröße von »ts« ist unbekannt
      108 |  struct timespec ts; 
          |                  ^~  
    /var/lib/dkms/zfs/0.8.3/build/include/spl/sys/time.h:109:2: Fehler: Implizite Deklaration der Funktion »getrawmonotonic« [-Werror=implicit-function-declaration]
      109 |  getrawmonotonic(&ts);
...

@eschwartz:

this issue is caused by firejail:

[@manjaro ~/build/zfs-dkms]$ ll /usr/local/bin/patch
lrwxrwxrwx 1 root root 17 Mar 28 14:56 /usr/local/bin/patch -> /usr/bin/firejail

==> Starting prepare()...
patch is /usr/local/bin/patch
patch is /usr/bin/patch
/usr/bin/patch: **** Can't open patch file    ../2fcab8795c7c493845bfa277d44bc443802000b8.patch : No such file or directory

Applying patches using stdin however still works with firejail:

# fix compilation on kernel 5.5 https://github.com/openzfs/zfs/issues/9745
patch -p1 < ../2fcab8795c7c493845bfa277d44bc443802000b8.patch

This can also be fixed by adding $srcdir to /etc/firejail/patch.local

whitelist /path/to/makepkg/sources

added to the wiki

That doesn't really make much sense, and it works fine here.

Can you try modifying the PKGBUILD with this change:

prepare()() {
    type -a patch
    cd "${srcdir}"/${pkgname%-dkms}-${pkgver}

   # rest of existing prepare goes here...
}

And tell me what the output is?

Thanks @Achelous - done, this is exactly the problem and knowing it's 1/32 means I can at least fix to 8GB for now.

@iusrlinearb

I noticed this bug in zfs a few months ago. It doesn't let you set zfs_arc_max to a value less than the default arc_c_min, which is 1/32 of all RAM.

I've raised a GitHub issue here:

https://github.com/openzfs/zfs/issues/10157

Please feel free to comment on the issue if you think you're seeing the same thing.

I'm struggling to stop zfs from consuming lots of RAM.

# cat /proc/spl/kstat/zfs/arcstats | grep c_max
c_max                           4    135097968640

If I look at arcstats, I see it growing rapidly towards c_max:

# cat /proc/spl/kstat/zfs/arcstats | grep size
size                            4    89817294664
[snipped the rest]

I've tried the obvious things. E.g. adding options zfs zfs_arc_max=5368709120 into /etc/modprobe.d/zfs.conf (and rebooting), adding zfs.zfs_arc_max=5368709120 to the end of my GRUB_CMDLINE_LINUX_DEFAULT and grub-mkconfig, rebooting.

I can see that the values are correctly being picked up - e.g. # cat /sys/module/zfs/parameters/zfs_arc_max 5368709120

Have looked at the wiki, for example https://wiki.archlinux.org/index.php/ZFS#ZFS_is_using_too_much_RAM

Also searched forums for zfs_arc_max but no useful messages. Anywhere else I should look? Thanks.

@LinuxIsBest,

Comment deleted, next time you attempt personal attacks on a Trusted User I'll just suspend your account.

iusrlinearb,

Doesn't appear to build, at least on my system.

==> Verifying source file signatures with gpg...
zfs-0.8.3.tar.gz ... FAILED (unknown public key 6AD860EED4598027)
==> ERROR: One or more PGP signatures could not be verified!

...

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.

I'm using zfs-dkms on x86_64 5.4.25-2-lts is it normal to see the following in boot logs?

mars 16 07:04:09 smicro kernel: zlua: loading out-of-tree module taints kernel.
mars 16 07:04:09 smicro kernel: zlua: module license 'MIT' taints kernel.
mars 16 07:04:09 smicro kernel: Disabling lock debugging due to kernel taint
mars 16 07:04:09 smicro kernel: zlua: module verification failed: signature and/or required key missing - tainting kernel

Great idea adding the 5.5 patch. Now that ZFS fixed SIMD support I upgraded for the first time in over a year from kernel 4.19 and it was painless. Thank you.

@sphere101: went from 5.4.15-arch1-1 to the latest today (5.5.7.arch1-1) and it built just fine.

Has anyone tested this latest zfs-dkms 0.8.3-2 with the 5.5.X kernel and latest gcc? If so, what is the process? Upgrade zfs-dkms and zfs-utils followed by a system update pacman -Syyu? Thank you.

@mikeyyve: compiles. The filesystem is mountable

Anyone tried kernel 5.5 with the changes eschwartz uploaded?

Upstream landed a patch that is supposed to fix compilation on kernel 5.5, which I am in the process of cherry-picking.

EDIT: uploaded

my kernel is compiled with 9.2.1 and I have gcc 9.2.1 but this is still not working. empty modules

% cat /proc/version
Linux version 5.4.21-1-lts (linux-lts@archlinux) (gcc version 9.2.1 20200130 (Arch Linux 9.2.1+20200130-2)) #1 SMP Thu, 20 Feb 2020 18:23:19 +0000
% gcc --version
gcc (Arch Linux 9.2.1+20200130-2) 9.2.1 20200130

update: downgrade to 9.2.0 does not fix it, however the cc1 error is no longer there.

more update: the new patch with kernel 5.5.6 also doesn't work. the error is in config.log

configure: exit 1
WARNING: modpost: missing MODULE_LICENSE() in /var/lib/dkms/zfs/0.8.3/build/build/conftest/conftest.o
see include/linux/module.h for more information

I just tried zfs-dkms-git, and it worked for the LTS kernel (not 5.5 yet), guess I'm using that for a while

Thank you, I was able to get zfs-dkms-0.8.3 running with 5.4.8 and gcc-9.2.0-4 with gcc-libs-9.2.0-4 Zpool is back online!

For those who tried to go back to an older kernel (because zfs-dkms is not compiling for kernel 5.5), only to find that the zfs-dkms doesn't compile there either with an error saying "Unable to build an empty module".

The issue seems to be related to GCC actually:

cc1: error: incompatible gcc/plugin versions
cc1: error: fail to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so

For me gcc got upgraded along with kernel and other packages when I did a pacman -Syu.

I downgraded my gcc to the previous version (9.2.0) and the module compiled properly for kernel 5.4.x.

Thanks for coming up with this. Would you mind to use Markdown next time? It makes pasted code far more readable

like this

Please do a full system upgrade. The gcc version you compile the dkms module with has to match the version the kernel has been compiled with.

In a jam , the following

Packages (1) zfs-dkms-0.8.3-1

Total Installed Size:  12.36 MiB
Net Upgrade Size:       0.00 MiB

:: Proceed with installation? [Y/n] Y
(1/1) checking keys in keyring                                                 [#############################################] 100%
(1/1) checking package integrity                                               [#############################################] 100%
(1/1) loading package files                                                    [#############################################] 100%
(1/1) checking for file conflicts                                              [#############################################] 100%
(1/1) checking available disk space                                            [#############################################] 100%
:: Running pre-transaction hooks...
(1/1) Remove DKMS modules
:: Processing package changes...
(1/1) reinstalling zfs-dkms                                                    [#############################################] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Install DKMS modules
==> dkms install zfs/0.8.3 -k 5.4.8-arch1-1
configure: error: 
    *** Unable to build an empty module.

Error! Bad return status for module build on kernel: 5.4.8-arch1-1 (x86_64)
Consult /var/lib/dkms/zfs/0.8.3/build/make.log for more information.

On [root@thor zfs-dkms]# uname -a Linux thor 5.4.8-arch1-1 #1 SMP PREEMPT Sat, 04 Jan 2020 23:46:18 +0000 x86_64 GNU/Linux

any suggestions?

Can anyone confirm that zfs-dkms is working with the 5.5.X kernel? Thank you,

No, it is not yet working with the 5.5.x kernel, at least when I tried this past weekend. If you rebuild your own kernel, there's a workaround:

https://github.com/zfsonlinux/zfs/issues/9745#issuecomment-573205923

You can follow this GitHub issue to find out when there is a resolution and what ZFSonLinux release will have the fix.

Can anyone confirm that zfs-dkms is working with the 5.5.X kernel? Thank you,

@freswa Thanks for the hint. I guess that was part of the problem.

After downgrading gcc to 9.2.0, the zfs modules for 5.4.15 compiled just fine again. Lifting gcc to 9.2.1 and installing the latest lts kernel and headers, then reinstalling zfs-dkms and updating the grub config enabled me to successfully switch to the lts kernel with archzfs/zfs-dkms.

@SRossi Make sure the version of gcc compiling the zfs code is the same that compiled the kernel. GCC Version of the running kernel can be looked up in /proc/version

In that case, may as well try aur/zfs-dkms?

@fryfrog I'm actually using archzfs/zfs-dkms. Looks like I'm barking up the wrong tree... ;)

As a point of comparison, have you tried archzfs/zfs-dkms? While they're similar, they are slightly different.

Another option would be building the kernel yourself too, w/ the couple of patches to help ZFS.

https://hastebin.com/zuyolixaru.diff

^ This is what I'm currently applying to my self built kernel.

@eschwartz No matter what I do - reinstalling all related zfs packages including kernel and kernel headers etc. - I can't get the modules to build or install. Even worse, I can't get it to work with kernel 5.4.15 anymore either, the kernel that the system (booting from zfs) is currently running with. It looks like a bug upstream or some issue with some package hooks maybe, where stuff gets pulled from underneat dkms leaving it in a bad state?

As a workaround I replaced zfs-dkms with zfs-linux for now. I will try with the long-term kernel again after a reboot later today and maybe be able to provide more information.

@SRossi,

It builds fine for me. Did you try manually running sudo dkms install zfs/0.8.3 -k 5.4.18-1-lts?

I used to run stable kernels with zfs-dkms but since 5.5.x is not working with zfs, I would like to switch to the lts kernel tree.

(3/4) Install DKMS modules ==> dkms install zfs/0.8.3 -k 5.4.18-1-lts configure: error: *** Unable to build an empty module.

Is there any chance to get this done?

Build on 5.4.8 seems to be working flawlessly.

My installed version is: aur/zfs-dkms 0.8.3-1 (+90 2.98%) (Installed)

Any news on the 5.5.2 kernel release?

Build for zen kernel 5.4.15 fails with weird errors

/var/lib/dkms/zfs/0.8.3/build/configure: 13381: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_COMMON+= --define "$(DEBUG_KMEM_ZFS) 1": not found
/var/lib/dkms/zfs/0.8.3/build/configure: 13382: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_COMMON+= --define "$(DEBUG_KMEM_TRACKING_ZFS) 1": not found
/var/lib/dkms/zfs/0.8.3/build/configure: 13383: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_COMMON+= --define "$(DEBUGINFO_ZFS) 1": not found
/var/lib/dkms/zfs/0.8.3/build/configure: 13384: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_COMMON+= --define "$(ASAN_ZFS) 1": not found
/var/lib/dkms/zfs/0.8.3/build/configure: 13403: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_UTIL+= $(DEFINE_INITRAMFS): not found
/var/lib/dkms/zfs/0.8.3/build/configure: 13404: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_UTIL+= $(DEFINE_SYSTEMD): not found
/var/lib/dkms/zfs/0.8.3/build/configure: 13405: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_UTIL+= $(DEFINE_PYZFS): not found
/var/lib/dkms/zfs/0.8.3/build/configure: 13406: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_UTIL+= $(DEFINE_PYTHON_VERSION): not found
/var/lib/dkms/zfs/0.8.3/build/configure: 13407: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_UTIL+= $(DEFINE_PYTHON_PKG_VERSION): not found
/var/lib/dkms/zfs/0.8.3/build/configure: 13418: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_KMOD+= --define "ksrc $(LINUX)": not found
/var/lib/dkms/zfs/0.8.3/build/configure: 13419: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_KMOD+= --define "kobj $(LINUX_OBJ)": not found
/var/lib/dkms/zfs/0.8.3/build/configure: 13420: /var/lib/dkms/zfs/0.8.3/build/configure: RPM_DEFINE_KMOD+= --define "_wrong_version_format_terminate_build 0": not found
configure: error:
    *** Unable to build an empty module.

Error! Bad return status for module build on kernel: 5.4.15-zen1-1-zen (x86_64)

Build of zfs-dkms is failing again with kernel 5.5.1:

FATAL: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol '__rcu_read_unlock'
make[2]:  [scripts/Makefile.modpost:94: __modpost] Error 1
make[1]:  [Makefile:1606: modules] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.5.1-arch1-1/build'
make: *** [Makefile:30: modules] Error 2
make: Leaving directory '/var/lib/dkms/zfs/0.8.3/build/module'

Linux 5.5.1 breaks ZFS 0.8.3. If you're willing to patch your kernel there's a workaround here: https://github.com/zfsonlinux/zfs/issues/9745#issuecomment-573205923

It is assumed by all AUR packages that base-devel is installed.

I think this needs build depends on automake and autoconf? Thank you for maintaining this.

Kernel 5.4 is working fine.

Does anyone know if zfs-dkms will work with the linux 5.4 Kernel?? Thank you.

@Tom_B I've manually tried the compilation, seems zfs configure does a lot compilation test and the configure process is single threaded, so no matter how powerful you machine is, it takes considerable time to complete.

Scratch my previous comment. It just takes a significant amount of time to install the module. Other DMKS modules I have installed take 10-15 seconds. ZFS takes around 10-15 minutes. I've no idea why this is but is why it appears to hang during a kernel upgrade. It doesn't hang, it just takes a lot longer than I'd expect.

Every time I get a kernel update, the dkms install hangs:

: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Install DKMS modules
==> dkms install zfs/0.8.2 -k 5.4.3-arch1-1

Previously, ctrl-c to exit exited the install and I could modprobe zfs as expected. Now though I get this error:

Error! Bad return status for module build on kernel: 5.4.3-arch1-1 (x86_64)
Consult /var/lib/dkms/zfs/0.8.2/build/make.log for more information.

The log it mentions:

DKMS make.log for zfs-0.8.2 for kernel 5.4.3-arch1-1 (x86_64)
Mon 16 Dec 13:36:46 GMT 2019
make: Entering directory '/var/lib/dkms/zfs/0.8.2/build/module'
make: *** No targets specified and no makefile found.  Stop.
make: Leaving directory '/var/lib/dkms/zfs/0.8.2/build/module'

Do I just need to wait for an update or am I missing something?

Hi, quick noob question. I am currently using zfs-dkms-git and want to switch back to zfs-dkms on an encrypted ZFS root. Everytime I try this I cannot boot anymore and I am dropped into the emergency shell with "filesystem 'rpool/ROOT/arch' can not be mounted: Permission denied". I can mount the pool inside the emergency shell just fine. Any ideas on how to fix this would greatly appreciated! Thanks

@Y5Lf8U0y5wFg4ktU is correct, the packages are designed so that you can build them without the other installed, but you need to pacman -U them both at the same time when upgrading. Most AUR helpers don't know how to do that, so you could try looking for one that does know how. Off the top of my head, aurutils does know how to behave properly here.

It is easiest to build both packages and then upgrade them both at the same time. No need to remove anything.

If you use yaourt, just ignore the pacman errors, the packages will remain in your temp dir. Afterwards install them from there.

Had to remove both pacakges, then re-install utils and then zfs-dkms... Thanks

Hi,

It's pretty safe to remove the zfs-utils package then install the new version. It won't damage any zfs installation you have. I do it now and again!

Of course, don't trust any random stranger posting here, do test beforehand (if possible!). All I can say is that when I went from zfs 0.8.1 to zfs 0.8.2, I had to remove the previous dkms (things are still in-memory, so zfs still works), then just reinstall the ones that where upgraded...

Are you maybe using archzfs/zfs-dkms and now you're trying to install aur/zfs-dkms? I had this issue when I was trying to switch from one to the other. I just removed zfs-utils and then specifically installed aur/zfs-dkms which pulled in aur/zfs-utils correctly. I had to go back to archzfs/zfs-dkms though, due to difference in the initcpio stuff. :(

A bit of a noob question, Trying to upgrade with yay and running into dependencies with zfs-util.. resolving dependencies... looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: installing zfs-utils (0.8.2-2) breaks dependency 'zfs-utils=0.8.1' required by zfs-dkms

Any recommendations?

I indeed just saw the new zfs 0.8.2 release, but at the moment the tarball is missing a PGP signature.

https://github.com/zfsonlinux/zfs/pull/9161#issuecomment-535729519

Fixed, hunted down and grabbed commits from master instead.

Tonyhutter rebased his PR branch so the Github links don't work anymore. Maybe we better include them in our repo.

Does it still break with 5.3 kernel?

I get an error during make: https://pastebin.com/D4hBXPeK

"The requested URL returned error: 406 Not Acceptable."

Timezone is CEST. Anyone else with this problem? (or is it on my side?)

Subscribed to the zfsonlinux issue -- any update on getting that merged any time soon???

There are four patches on that list marked as "Linux 5.3 compat", so if an 0.8.2 release does not look imminent we can try backporting those, which should hopefully be enough.

And the future 0.8.2 release looks like it should solve it.

https://github.com/zfsonlinux/zfs/pull/9161

linux 5.3.arch1-1 breaks ZFS

https://bugs.archlinux.org/task/63864 https://github.com/zfsonlinux/zfs/issues/9332

@edacval thanks for the link! Already did my research a few days ago and did not check before posting, sorry … :)

@patrickh : https://github.com/zfsonlinux/zfs/issues/9133

I just wanted to ask, if anyone had the luck to get this working together with linux-mainline kernel (version 5.3-rc3 or other rc versions)? I would like to try new hardware, that will be supported in 5.3 only, therefore I am trying things out.

I know that this is probably not yet officially supported, but I was wondering, if the build errors that I see are a result of missing support for 5.3 on the ZFS side for now, or if it is just that the dkms build process is not compatible with the linux-mainline package here in general?

Here is my /var/lib/dkms/zfs/git/build/make.log: https://gist.github.com/c529e36107dc0f93a04b7e4c5612f24b ¹

Maybe someone who understands the dkms build process better than me could give me a hint, if it makes sense to report this to upstream or if I should just wait for official 5.3 release of core/linux package?

Thanks and best regards!

¹ sorry for the German "Notice" messages in the log. I changed my LC_ALL, but it didn't seem to work. But as far as I understand, the real issue is right at the end here:

make[2]: *** No rule to make target 'module/Module.symvers', needed by 'all-am'.  Stop.

@eschwartz: It might be worth updating the .patch so it applies cleanly.

patching file scripts/dkms.mkconf
Hunk #1 succeeded at 25 with fuzz 2.
Hunk #2 succeeded at 59 with fuzz 1 (offset -4 lines).

In case anyone wants to know if the current version (0.8.1) will install on kernel 5.2, it will. Only up to 5.1 is supported for now but I'm running it successfully on 5.2, and it's been reported that the test suite passes (see https://github.com/zfsonlinux/zfs/issues/9014#issuecomment-510265743).

See https://github.com/zfsonlinux/zfs/issues/8697#issuecomment-490163919

This should be getting queued for an upcoming spl-0.7.14

In the meantime I have backported the fix from https://github.com/zfsonlinux/zfs/pull/8479 and pushed a new dkms pkgrel, which builds fine for me on 5.1.2.arch1-1.

Recent kernel change did away with get_ds() in favor of KERNEL_DS.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.1.3&id=736706bee329

If you need to, edit line 611 of /usr/src/spl-0.7.13/module/spl/spl-vnode.c and change:

set_fs(get_ds());

to

set_fs(KERNEL_DS);

then run

dkms install spl/0.7.13 -k $(uname -r)

dkms install zfs/0.7.13 -k $(uname -r)

0.7.13 only compatible with kernels up to 5.0, not 5.1. See here ... https://github.com/zfsonlinux/zfs You should wait for 0.8 release of ZoL before using kernel 5.1

@eblau I have this too. These spl- and zfs- dkms packages often break when a new kernel comes out. Just downgrade your kernel (linux, linux-headers) until spl-dkms is updated.

You may want to consider adding linux and linux-headers to IgnorePkg= in /etc/pacman.conf. Just update them manually, once you see that spl and zfs are working.

I'm hitting build errors after upgrading to linux-5.1.2.arch1-1:

/var/lib/dkms/spl/0.7.13/build/module/spl/spl-vnode.c: In function ‘vn_set_pwd’:
/var/lib/dkms/spl/0.7.13/build/module/spl/spl-vnode.c:611:9: error: implicit declaration of function ‘get_ds’; did you mean ‘get_fs’? [-Werror=implicit-function-declaration]
  set_fs(get_ds());
         ^~~~~~
         get_fs
/var/lib/dkms/spl/0.7.13/build/module/spl/spl-vnode.c:611:9: error: incompatible type for argument 1 of ‘set_fs’
  set_fs(get_ds());
         ^~~~~~~~
In file included from ./include/linux/uaccess.h:11,
                 from ./include/linux/poll.h:12,
                 from ./include/linux/ring_buffer.h:7,
                 from ./include/linux/trace_events.h:6,
                 from ./include/trace/syscall.h:7,
                 from ./include/linux/syscalls.h:86,
                 from /var/lib/dkms/spl/0.7.13/build/include/sys/vnode.h:29,
                 from /var/lib/dkms/spl/0.7.13/build/module/spl/spl-vnode.c:28:
./arch/x86/include/asm/uaccess.h:29:40: note: expected ‘mm_segment_t’ {aka ‘struct <anonymous>’} but argument is of type ‘int’
 static inline void set_fs(mm_segment_t fs)
                           ~~~~~~~~~~~~~^~
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:276: /var/lib/dkms/spl/0.7.13/build/module/spl/spl-vnode.o] Error 1

I assume this is an issue on the ZFS on Linux side but a quick search on the Github repo doesn't show anything. Anyone else hitting this?

@milaxnuts,

This will never, ever be implemented. See https://wiki.archlinux.org/index.php/User:Apg#makepkg:_shallow_git_clones for more details on why makepkg cannot do this, and the long list of rejections.

The only option that is acceptable is if you convince upstream to sign their tarballs. Currently, checking PGP signatures for the zfsonlinux project requires using git, but there's no other reason to prefer it. This would drop the download size to 6.5MB (8MB for the 0.8 release candidate).

EDIT: they may in fact do this: https://github.com/zfsonlinux/zfs/issues/8557

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

@greencopper,

This package requires reading the documentation on how to run the makepkg command. There are no exceptions.

UPDATE: Sorry, I complete forgot about the key part when using AUR.

==> Verifying source file signatures with gpg...
    zfs git repo ... FAILED (unknown public key 6AD860EED4598027)
==> ERROR: One or more PGP signatures could not be verified!

@eschwartz: I've uninstalled all 3 packages: spl-dkms, zfs-dkms and zfs-utils and then reinstalled zfs-dkms. It looks fine now.

That would do it, I guess.

The manpage for dkms install observes regarding dependencies that "Note that this directive is only advisory; missing or broken dependencies cause non-fatal warnings."

The pacman hook implements its own sort ordering by checking dkms status for dependencies, and will fail if dependencies are missing, which is unlike the default dkms behavior.

Thank you kindly for the advice Eli, it resolved my issue! I had an old version of spl-dkms kicking around for some reason, after I manually removed it with

dkms remove spl/0.7.9 --all

then the pacman install worked perfectly as usual! I have no idea how that went wrong, it looks like dkms gets confused when there are multiple versions as you suspected. Thanks again!

ps. I also have no idea why that specific version of spl was left behind? Perhaps a failed upgrade earlier. I will leave this comment in case somebody else encounters an issue that they should check what dkms modules are available.

@karcher,

AUR helpers are notoriously unreliable when it comes to handling versioned dependencies. You will not be able to partially update the zfs packages; you need to build them without installing them, then install the whole set together... (EDIT: Or alternatively, uninstall zfs-dkms in order to allow its dependencies to be updated, then reinstall the new version of zfs-dkms.)

@vanja_z,

It is impossible for the zfs module to build if the spl module is not built, but if the spl module is built, then the pacman hook will work. I do know that it works for me... without being able to troubleshoot the internal state of dkms, I cannot say more.

However, it definitely has nothing to do with dkms-sorted.

So as far as I can tell, what you're saying is happening is... not impossible, but nearly so. I don't know why the pacman hook would not work, but dkms might work if it is incorrectly and dangerously building against an old built version of spl, as the zfs-dkms build system might be fooled into thinking that the old version is sufficient.

In general, reinstalling both spl-dkms and zfs-dkms will cause the hooks to trigger again, thereby doing a dkms install for first spl, then zfs -- which should work, as you're setting it up to rebuild from scratch.

Not sure what else to say.

Hi all,

I'm getting an error during the latest update:

...
:: 3 Packages to upgrade.
3  aur/spl-dkms   0.7.12-1 -> 0.7.13-1
2  aur/zfs-dkms   0.7.12-2 -> 0.7.13-1
1  aur/zfs-utils  0.7.12-1 -> 0.7.13-1

...
loading packages...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing spl-dkms (0.7.13-1) breaks dependency 'spl-dkms=0.7.12' required by zfs-dkms

Any ideas what's wrong?

I do understand that this is how the process is meant to work however it is not working on my system. My system is up to date and I have the matching version of spl-dkms (0.7.13). ZFS works fine after I manually dkms install the module. Does anybody have any ideas what could be going wrong or how to trouble shoot? Does this have something to do with the dkms-sorted package that used to exist?

That means that when dkms executed, the spl module, which is a dependency, did not yet exist for the desired kernel. This is usually impossible, as the pacman hook is supposed to respect dependency ordering to ensure spl is built first during a single transaction, and this package depends on a strictly versioned spl-dkms package.

I have been running zfs-dkms for many versions and something new has gone wrong. Installation fails with the following output:

(1/2) Install DKMS modules

==> Unable to install module zfs/0.7.13 for kernel 5.0.0-arch1-1-ARCH: Missing dependency.

If I manually install the dkms module it works,

dkms install zfs/0.7.13

...

DKMS: install completed.

Any ideas? I would like to avoid having to manually run dkms install for every kernel update.

Hey there, right now it is required to apply this patch to get it to compile 0.7.12 under kernel 4.20: https://github.com/zfsonlinux/zfs/pull/8227.diff

Here is a one-liner to apply the patch:

curl -sSL https://github.com/zfsonlinux/zfs/pull/8227.diff | sudo patch -p1 -d /usr/src/zfs-0.7.12 && sudo dkms autoinstall

@eschwartz: "Are you using some alternative packages that do not come from the AUR?" No.

I reinstalled spl-dkms, zfs-dkms and zfs-utils and then I could remove spl-utils. Thanks again!

Are you using some alternative packages that do not come from the AUR?

The spl-utils package contains some command-line tools used for running the spl module testsuite in case you are a zfsonlinux developer, whereas the zfs-utils package contains command-line tools which are actually useful to end-users in order to administrate a zfs filesystem.

As a result, I've dropped the spl-utils package altogether. If anyone wants to create a package installing these tools, they can... But you don't need it as a dependency of spl-dkms. However: you somehow have an spl-dkms package that does depend on it. It's possible that you've manually bumped the pkgver of the old package before it was updated.

Uninstalling them all and reinstalling from the AUR would fix it, but only because of the reinstall. You should just as easily be able to reinstall them without uninstalling first.

• After reinstalling spl-dkms from the AUR, it will no longer depend on the missing spl-utils package and you can safely remove it.
• If you have not rebuilt zfs-utils or zfs-dkms since I took over maintenance, you should rebuild those as well, for example in order to obtain the initcpio hook updates.

@eschwartz: thanks!

I've updated to the latest version but now when I try to update I see this:

$ aurman -Su --always_edit --show_changes --solution_way                                   
:: Starting full system upgrade...
there is nothing to do

~~ initializing aurman...
~~ the following packages are neither in known repos nor in the aur
:: spl-utils-0.7.11-1
~~ calculating solutions...
:: nothing to do... everything is up to date

and when I try to remove spl-utils:

$ aurman -R spl-utils         
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: spl-dkms: removing spl-utils breaks dependency 'spl-utils=0.7.11-1'

or with the dependencies:

$ aurman -Rc spl-utils                                          
checking dependencies...

Packages (4) spl-dkms-0.7.11-1  zfs-dkms-0.7.11-2  znapzend-0.19.0-1  spl-utils-0.7.11-1

Total Removed Size:  14.46 MiB

:: Do you want to remove these packages? [Y/n] n

Should I remove them all and reinstall zfs-dkms? Or what else can I do to fix it?

To solve the "Unknown public key" issue, just add the PGP keys of the ZFS on Linux maintainers like described here: https://github.com/zfsonlinux/zfs/wiki/Signing-Keys.

If you get the message 'Unknown public key 6AD860EED4598027' when trying to install this, see here: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking . You need to import the mentioned key first. ( A (not very satisfying and usually a bad idea) workaround is to remove the '?signed' at the end of the repo URL. )

I don't understand this thing at all, as splat.ko is provided by spl-dkms alongside the spl module itself, but splat is also a binary which interacts with the kernel module of the same name.

And splat is a testsuite, it certainly doesn't need to be in the initcpio. The error message should be harmless-ish, mkinitcpio is just warning you that it couldn't find one of the files and therefore if your boot process actually relies on the file in question, then it will have errors.

But, this should really be removed from the install hook altogether, along with a couple python scripts that I literally don't comprehend their presence.

There is still one issue. I have a machine with root on ZFS. With the current packages, I cannot build the initial ramdisk, because the module splat, formerly provided by spl-utils, is missing.

~ [1]$ sudo mkinitcpio -p linux-zen
==> Building image from preset: /etc/mkinitcpio.d/linux-zen.preset: 'default'
  -> -k /boot/vmlinuz-linux-zen -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-zen.img
==> Starting build: 4.17.14-zen1-1-zen
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [encrypt]
  -> Running build hook: [zfs]
==> ERROR: file not found: `splat'
  -> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-zen.img
==> WARNING: errors were encountered during the build. The image may not be complete.

The provides has been re-added, as also mentioned in the zfs-utils comments.

I'm not going to remove security checks though, especially not for a high-profile package like a kernel module. If following the instructions from https://wiki.archlinux.org/index.php/Makepkg#Signature_checking is a show-stopper for people, then so be it. Hopefully this won't be a big problem for people, though, especially as zfs is a fairly technical thing to use to begin with.

Hi,

in the latest version the "provides=("zfs")" was deleted and so I wasn't able to update the packages since the zfs-snap-manager has a dependency on zfs.

An addition I had to add the pgp keys like described here: https://github.com/zfsonlinux/zfs/wiki/Signing-Keys. This might be a stopper for a lot of people.

Best regards, othiman

Sorry for the momentary absence of the package. I split it out because I didn't see the purpose of combining them, but while I successfully uploaded the new dkms package, the replacement utils package failed to upload because of my current terrible internet situation.

It's up now and should work, although as I don't use zfs I can only test that the modules compile successfully. But it's hopefully a lot more generic and better split.

@eschwartz: Am I correct to assume that zfs-utils is now replaced by zfs-utils-common, or are you going to upload a new version of zfs-utils? BTW: Thanks for maintaining this!

@allspark : Thanks!

I finally tried to built zfs-dkms and spl-dkms (v0.7.11) with clean-chroot-manager and installed the 4 generated packages successfully. I had to use the -f option to import my zvols but after I rebooted one more time everything seems to be OK.

i changed the version in the PKGBUILD, built and installed it

@bus & @lilydjwg: Thanks! I have to be 100% sure that it works. My work relies on it and my system is running now with 4.14 kernel.

@allspark: Could you please tell us how did you install it?

Honestly I just use the arch-zfs repo. They provide prebuilt binaries for all the kernels available in the official Arch repos (so less headaches and time wasted compiling) as well as DKMS versions and are fast at updating their builds to new kernel or ZFS versions as well as applying patches to make them buildable for newer kernel/compiler versions.

i'm using zfs with version 0.7.11 without problems

from https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.7.10 Updated 9/17/18: We've found a serious regression in 0.7.10 (#7906 #7899). Please use 0.7.9 or 0.7.11.

so 0.7.11 should be ok

@bus yeah, I sent a orphan request again. I got some spare time to maintain this package in time. I don't see why he should keep this package if he has no spare time.

in this package /etc/sudoers.d/ permission is 755 but in system it is 750

@karcher it actually works. In this way I get an updated package automatically when there is a new release.

@karcher At this point I don't think it's possible -- there must be a reason to wait weeks to change the pkgver after every ZFS release.

I don't like being a whiny asshole about this again, but it has been a problem for too long. Having to submit a request to orphan the package every time it's been sitting out of date for a month doesn't really feel in line with the "bleeding edge" ways of Arch.

Looks like isiachi has too little time to update this and the zfs package in time :(

zfs-0.7.11 is compatible with 4.18 kernel. Is it possible to simply modify the pkgver and sha256sums accordingly in the PKGBUILD and install it?

0.7.11 has been released. Changing pkgver should be sufficient to get it working with current kernels.

@Kaedo As far as I know dkms-sorted is no longer necessary, since dkms in extra has this functionality now (https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/dkms&id=efcb54fb735b22c1bc405b255dbe9f8decc8bb8d).

About the kernel panic: We recently changed the hook a bit which might cause your boot problems. Please open an issue at http://github.com/archzfs/archzfs with more details (This AUR package is not archzfs).

Yesterday I installed:

• archzfs/zfs-dkms 0.7.10-1
• archzfs/spl-dkms 0.7.10-1
• core/linux 4.18.6.arch1-1
• core/linux-headers 4.18.6.arch1-1

I got an failed build when build dkms with version 2.5-3 due to Missing Dependencies.

I resolved the build issue with dkms-sorted 2.5-2, but on reboot I got the problem that my zfs pool could not be imported by the mkinitcpio zfs hook.

Always got kernel panic.

With live USB stick there were no problem during import of the zfs pool.

After checking every possible config mistag I downgraded to:

• core/linux 4.17.13.arch1-1 (base)
• core/linux-headers 4.17.13.arch1-1
• archzfs/spl-dkms 0.7.9-3 (archzfs-dkms)
• archzfs/spl-utils-common 0.7.9-2 (archzfs-linux)
• archzfs/zfs-utils-common 0.7.9-2 (archzfs-linux)
• archzfs/zfs-dkms 0.7.9-3 (archzfs-dkms)

Now every thing works fine. I guess the root cause of the problem is: - archzfs/zfs-dkms 0.7.10-1.

Does anybody else encountered the same problem?

0.7.10 was just released and appears to fix this problem.

Updating the spl/zfs packages to 0.7.10 should resolve the issue described by ultdev and teejar below:

https://github.com/zfsonlinux/zfs/releases

It's now critical that these packages be updated ASAP, as the most recent upgrade broke the SPL compile/build, and the only solution currently is to downgrade the kernel, which is a pain.

@isiachi: Any idea when you'll have time to update these packages?

This package is likely to fail on 4.18 kernels due to the change in timespec. There's currently an open pull request for a compatibility fix on the zfsonlinux github page:

https://github.com/zfsonlinux/zfs/issues/7785 https://github.com/zfsonlinux/zfs/pull/7792 https://github.com/zfsonlinux/spl/pull/707

@teejer This issue is due to changes in timespec introduced in the 4.18 kernel.

There's currently an open pull request for a compatibility fix on the zfsonlinux github page:

https://github.com/zfsonlinux/zfs/issues/7785

https://github.com/zfsonlinux/zfs/pull/7792

https://github.com/zfsonlinux/spl/pull/707

I'm getting an error when building this for the 4.18.1 kernel.

Here's the make.log

KMS make.log for spl-0.7.9 for kernel 4.18.1-arch1-1-ARCH (x86_64) Fri Aug 17 16:27:46 MDT 2018 make all-recursive make[1]: Entering directory '/var/lib/dkms/spl/0.7.9/build' Making all in include make[2]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include' Making all in fs make[3]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include/fs' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include/fs' Making all in linux make[3]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include/linux' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include/linux' Making all in rpc make[3]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include/rpc' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include/rpc' Making all in sharefs make[3]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include/sharefs' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include/sharefs' Making all in sys make[3]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include/sys' Making all in fm make[4]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include/sys/fm' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include/sys/fm' Making all in fs make[4]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include/sys/fs' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include/sys/fs' make[4]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include/sys' make[4]: Nothing to be done for 'all-am'. make[4]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include/sys' make[3]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include/sys' Making all in util make[3]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include/util' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include/util' Making all in vm make[3]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include/vm' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include/vm' make[3]: Entering directory '/var/lib/dkms/spl/0.7.9/build/include' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include' make[2]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/include' Making all in rpm make[2]: Entering directory '/var/lib/dkms/spl/0.7.9/build/rpm' Making all in generic make[3]: Entering directory '/var/lib/dkms/spl/0.7.9/build/rpm/generic' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/rpm/generic' Making all in redhat make[3]: Entering directory '/var/lib/dkms/spl/0.7.9/build/rpm/redhat' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/rpm/redhat' make[3]: Entering directory '/var/lib/dkms/spl/0.7.9/build/rpm' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/rpm' make[2]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/rpm' Making all in module make[2]: Entering directory '/var/lib/dkms/spl/0.7.9/build/module' make -C /usr/lib/modules/4.18.1-arch1-1-ARCH/build SUBDIRS=pwd CONFIG_SPL=m modules make[3]: Entering directory '/usr/lib/modules/4.18.1-arch1-1-ARCH/build' CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-ctl.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/spl/spl-proc.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/spl/spl-kmem.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-kmem.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/spl/spl-kmem-cache.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-taskq.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-random.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/spl/spl-vmem.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-mutex.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/spl/spl-thread.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-condvar.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/spl/spl-taskq.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-thread.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/spl/spl-rwlock.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/spl/spl-vnode.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-rwlock.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/spl/spl-err.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-time.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/spl/spl-kobj.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-vnode.o /var/lib/dkms/spl/0.7.9/build/module/spl/spl-vnode.c: In function \u2018vn_getattr\u2019: /var/lib/dkms/spl/0.7.9/build/module/spl/spl-vnode.c:308:16: error: incompatible types when assigning to type \u2018struct timespec\u2019 from type \u2018struct timespec64\u2019 vap->va_atime = stat.atime; ^ /var/lib/dkms/spl/0.7.9/build/module/spl/spl-vnode.c:309:16: error: incompatible types when assigning to type \u2018struct timespec\u2019 from type \u2018struct timespec64\u2019 vap->va_mtime = stat.mtime; ^ /var/lib/dkms/spl/0.7.9/build/module/spl/spl-vnode.c:310:16: error: incompatible types when assigning to type \u2018struct timespec\u2019 from type \u2018struct timespec64\u2019 vap->va_ctime = stat.ctime; ^ make[5]: [scripts/Makefile.build:317: /var/lib/dkms/spl/0.7.9/build/module/spl/spl-vnode.o] Error 1 make[5]: Waiting for unfinished jobs.... CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-kobj.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-atomic.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-list.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-generic.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-cred.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-zlib.o CC [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat-linux.o make[4]: [scripts/Makefile.build:558: /var/lib/dkms/spl/0.7.9/build/module/spl] Error 2 make[4]: Waiting for unfinished jobs.... LD [M] /var/lib/dkms/spl/0.7.9/build/module/splat/splat.o make[3]: [Makefile:1500: module/var/lib/dkms/spl/0.7.9/build/module] Error 2 make[3]: Leaving directory '/usr/lib/modules/4.18.1-arch1-1-ARCH/build' make[2]: [Makefile:11: modules] Error 2 make[2]: Leaving directory '/var/lib/dkms/spl/0.7.9/build/module' make[1]: [Makefile:609: all-recursive] Error 1 make[1]: Leaving directory '/var/lib/dkms/spl/0.7.9/build' make: [Makefile:490: all] Error 2

@sudoBash418

The tarball update was done silently, so it could have taken a while of users thinking the source is compromised in some way for the package maintainer to notice and update.

@sylveon Wouldn't a tarball update like that justify a pkgrel bump and updated checksums?

The zfs maintainers once had to update the tarballs on an existing release, so using the signature is a better idea than using a checksum.

I agree with @RubenKelevra that checksums should be used.

@Eschwartz: security wasn't mentioned in his comment, but if he had mentioned it, he would have been right to.

A checksum would ensure that the source hasn't changed since the package maintainer downloaded it. This:

(1) Protects users against targeted MitM attacks (e.g. an oppressive government pretending to be GitHub), and

(2) Protects against an attacker taking over the zfsonlinux GitHub account, and pointing the existing tag at some malicious code (as long as the breach happens after the AUR maintainer downloads the source).

That sounds like a security improvement to me!

As @RubenKelevra notes, there's also a PGP signed .asc file available, and there's no good reason why this shouldn't be used.

As for the pointless whatabout-ism, yes there may be other (higher-profile) packages which make the same mistake, but that's no reason not to fix it here. It shouldn't be necessary to comment on every single one to be allowed the privilege of commenting here.

Checksums don't add security, that's why they're the "integrity check", not the "security check". Do you know how many [core] packages don't have PGP signatures available at all? Those are used on far more devices.

Granted, using PGP when available is always nice. But I don't see you screeching at the non-dkms package maintainer to fix his packages...

Edit: to clarify, I even like strong integrity checks myself, because they're definitely better than nothing and it can only help. But you're going about this totally the wrong way and you should also consider the old saying about people who live in glass houses.

Checksums don't add security, that's why they're the "integrity check", not the "security check". Do you know how many [core] packages don't have PGP signatures available at all? Those are used on far more devices.

Granted, using PGP when available is always nice. But I don't see you screeching at the non-dkms package maintainer to fix his packages...

Edit: to clarify, I even like strong integrity checks myself, because they're definitely better than nothing and it can only help. But you're going about this totally the wrong way and you should also consider the old saying about people who live in glass houses.

Please add some kind of checksum checking to this package. Currently, the source integrity fully relies on a valid https certificate and the server behind it returning the right data. This doesn't sound right for a kernel module used in thousands of devices.

You can switch to a download link of the release, instead of a git clone (which also reduces the download time and the server load) like this:

https://github.com/zfsonlinux/zfs/releases/download/zfs-0.7.8/zfs-0.7.8.tar.gz

Then you can just add a checksum for this archive.

Since they also provide a .asc file, it should be loaded and used to verify the sources too.

Please add some kind of checksum checking to this package. Currently, the source integrity fully relies on a valid https certificate and the server behind it returning the right data. This doesn't sound right for a kernel module used in thousands of devices.

You can switch to a download link of the release, instead of a git clone (which also reduces the download time and the server load) like this:

https://github.com/zfsonlinux/spl/archive/spl-0.7.8.tar.gz

Then you can just add a checksum for this archive.

Doesn't seem to make sense to hold these packages hostage if you do not have the time to increment a few digits in response to a major data-corrupting regression within 2 weeks. You're just letting people down with consistently late updates.

I would highly recommend using the archzfs repository with pacman instead of this package as it is updated much faster.

Please bump to 0.7.8 as there was a major regression in 0.7.7 https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.7.8

Could the aarch64 architecture be added to the PKGBUILD? The ZFS on Linux projects states that the arch is supported (https://github.com/zfsonlinux/zfs/wiki/FAQ) and I've been using a modified PKGBUILD compiled on aarch64 successfully for some time as well.

Could the aarch64 architecture be added to the PKGBUILD? The ZFS on Linux projects states that the arch is supported (https://github.com/zfsonlinux/zfs/wiki/FAQ) and I've been using a modified PKGBUILD compiled on aarch64 successfully for some time as well.

Why is the package not updated to 0.7.6? It does not apply to recent kernels and manually hacking the PKGBUILD each time is just stupid.

7.5 version is causing an init_timer error on build.

At least until the packages are updated here do the following:

The 7.6 version of spl and zfs fixes the issue. when installing spl-dkms or zfs-dkms edit the PKGBUILD.

in both zfs-dkms and spl-dkms, Change the variable pkgver=0.7.5 to pkgver=0.7.6

continue building.. it should install properly.

@risto3

At least until the packages are updated here do the following:

The 7.6 version of spl and zfs fixes the issue. when installing spl-dkms or zfs-dkms edit the PKGBUILD.

in both zfs-dkms and spl-dkms, Change the variable pkgver=0.7.5 to pkgver=0.7.6

continue building.. it should install properly.

Gulp, I just got the following upgrading today:

==> dkms install spl/0.7.5 -k 4.15.1-2-ARCH Error! Bad return status for module build on kernel: 4.15.1-2-ARCH (x86_64) Consult /var/lib/dkms/spl/0.7.5/build/make.log for more information. ==> dkms install acpi_call/1.1.0 -k 4.15.1-2-ARCH ==> WARNING: Cannot resolve dependencies for module zfs/0.7.5, kernel version 4.15.1-2-ARCH (3/5) Updating linux initcpios...

the error is: /var/lib/dkms/spl/0.7.5/build/module/spl/spl-taskq.c: Dans la fonction « taskq_dispatch »: /var/lib/dkms/spl/0.7.5/build/module/spl/spl-taskq.c:593:16: error: « struct timer_list » n'a pas de membre nommé « data » t->tqent_timer.data = 0; ^ /var/lib/dkms/spl/0.7.5/build/module/spl/spl-taskq.c: Dans la fonction « taskq_dispatch_delay »: /var/lib/dkms/spl/0.7.5/build/module/spl/spl-taskq.c:643:16: error: « struct timer_list » n'a pas de membre nommé « data » t->tqent_timer.data = (unsigned long)t; ^ /var/lib/dkms/spl/0.7.5/build/module/spl/spl-taskq.c:644:26: error: affectation depuis un type pointeur incompatible [-Werror=incompatible-pointer-types] t->tqent_timer.function = task_expire; ^ CC [M] /var/lib/dkms/spl/0.7.5/build/module/splat/splat-condvar.o /var/lib/dkms/spl/0.7.5/build/module/spl/spl-taskq.c: Dans la fonction « taskq_init_ent »: /var/lib/dkms/spl/0.7.5/build/module/spl/spl-taskq.c:735:2: error: déclaration implicite de la fonction « init_timer »; vouliez-vous utiliser « init_timers » ? [-Werror=implicit-function-declaration] init_timer(&t->tqent_timer); ^~~~~~~~~~

(excuse my French :-)

needs spl-0.7.6 for 4.15 patches

Regarding my last comment below: I resolved this issue by enabling the new "zfs-import.target" systemd unit.

I have installed spl-dkms & zfs-dkms 0.7.5 with the latest kernel 4.14.10-1 but for some reason the zfs kernel modules are not loading during boot. If I run '/sbin/modprobe zfs' then the modules load and I can mount the zpool. Anybody else had this issue?

They are available in the archlinuxcn repo too (scroll one page up).

@bus I noticed that zfs-dkms and spl-dkms are available as pre-built packages in the archzfs repo. https://wiki.archlinux.org/index.php/Unofficial_user_repositories#archzfs

Simply replacing "0.7.3" with "0.7.4" in the PKGBUILD seems to work for me. (When used with zfs-dkms, I did the same there and uninstalled both packages prior to reinstalling the newer versions.)

broken with linux 4.14

upstream issue: https://github.com/zfsonlinux/spl/issues/656, https://github.com/zfsonlinux/spl/pull/659