Package Details: zfs-dkms 2.1.5-1

Git Clone URL: https://aur.archlinux.org/zfs-dkms.git (read-only, click to copy)
Package Base: zfs-dkms
Description: Kernel modules for the Zettabyte File System.
Upstream URL: https://zfsonlinux.org/
Licenses: CDDL
Conflicts: spl-dkms
Provides: spl-dkms, SPL-MODULE, zfs, ZFS-MODULE
Replaces: spl-dkms
Submitter: isiachi
Maintainer: eschwartz (jonathon)
Last Packager: jonathon
Votes: 137
Popularity: 5.75
First Submitted: 2015-08-31 12:01 (UTC)
Last Updated: 2022-06-23 23:39 (UTC)

Latest Comments

habys commented on 2022-06-17 19:09 (UTC)

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

Erin-Allison commented on 2022-06-07 16:13 (UTC)

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.

Klowner commented on 2022-06-07 16:11 (UTC) (edited on 2022-06-07 16:11 (UTC) by Klowner)

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

jongeduard commented on 2022-06-05 23:24 (UTC)

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

habys commented on 2022-06-04 12:04 (UTC)

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.

jongeduard commented on 2022-05-31 23:27 (UTC)

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

kstolp commented on 2022-05-31 17:56 (UTC) (edited on 2022-05-31 17:57 (UTC) by kstolp)

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

itoffshore commented on 2022-05-31 17:03 (UTC) (edited on 2022-05-31 17:05 (UTC) by itoffshore)

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

jongeduard commented on 2022-05-31 16:47 (UTC) (edited on 2022-05-31 16:55 (UTC) by jongeduard)

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

bazzawill commented on 2022-05-31 12:57 (UTC)

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

jongeduard commented on 2022-05-29 14:40 (UTC) (edited on 2022-05-29 14:41 (UTC) by jongeduard)

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

fryfrog commented on 2022-05-29 02:54 (UTC)

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

Erin-Allison commented on 2022-05-29 02:41 (UTC) (edited on 2022-05-29 02:41 (UTC) by Erin-Allison)

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

itoffshore commented on 2022-04-26 21:01 (UTC)

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

daemonjax commented on 2022-04-26 20:27 (UTC) (edited on 2022-04-26 21:34 (UTC) by daemonjax)

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.

itoffshore commented on 2022-03-13 22:52 (UTC) (edited on 2022-03-24 12:14 (UTC) by itoffshore)

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

jongeduard commented on 2022-02-15 17:23 (UTC)

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

jonathon commented on 2022-02-15 16:14 (UTC)

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.

jongeduard commented on 2022-02-15 15:05 (UTC) (edited on 2022-02-15 17:17 (UTC) by jongeduard)

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.

edacval commented on 2022-02-15 07:27 (UTC)

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

maxyarch commented on 2022-02-15 04:39 (UTC)

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

pgeorgiadis commented on 2022-02-13 08:23 (UTC)

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?

razielgn commented on 2022-02-11 19:55 (UTC)

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.

baalajimaestro commented on 2022-01-13 15:48 (UTC)

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.

fryfrog commented on 2022-01-13 15:35 (UTC)

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

baalajimaestro commented on 2022-01-13 13:59 (UTC)

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.

iio7 commented on 2021-11-29 22:53 (UTC)

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.

fryfrog commented on 2021-11-29 22:49 (UTC)

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.

debohman commented on 2021-11-22 22:03 (UTC) (edited on 2021-11-22 22:06 (UTC) by debohman)

@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

jongeduard commented on 2021-11-22 20:45 (UTC) (edited on 2021-11-22 20:46 (UTC) by jongeduard)

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

debohman commented on 2021-11-22 17:42 (UTC) (edited on 2021-11-22 17:47 (UTC) by debohman)

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.

johno commented on 2021-10-02 19:08 (UTC)

thank you for the update! Great! :-)

jstrom commented on 2021-10-02 09:12 (UTC)

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

dhathaway commented on 2021-10-01 20:07 (UTC)

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

fryfrog commented on 2021-10-01 20:00 (UTC)

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

dhathaway commented on 2021-10-01 19:43 (UTC)

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

fryfrog commented on 2021-10-01 18:26 (UTC)

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

dhathaway commented on 2021-10-01 18:24 (UTC)

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.

jongeduard commented on 2021-10-01 16:10 (UTC)

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

fryfrog commented on 2021-09-28 22:12 (UTC)

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.

jongeduard commented on 2021-09-28 21:59 (UTC)

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

itoffshore commented on 2021-09-28 02:44 (UTC) (edited on 2021-09-28 22:09 (UTC) by itoffshore)

@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

fryfrog commented on 2021-09-28 02:32 (UTC)

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

johno commented on 2021-09-28 00:57 (UTC)

Hello,

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

Best regards, johno

HellishINC commented on 2021-09-21 20:52 (UTC)

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

Zod commented on 2021-09-21 12:22 (UTC) (edited on 2021-09-21 12:47 (UTC) by Zod)

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.

HellishINC commented on 2021-09-21 06:58 (UTC) (edited on 2021-09-21 07:01 (UTC) by HellishINC)

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.

fryfrog commented on 2021-09-18 18:53 (UTC)

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

jongeduard commented on 2021-09-18 18:35 (UTC)

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.

yurikoles commented on 2021-09-16 14:50 (UTC)

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

yurikoles commented on 2021-09-16 14:50 (UTC)

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

jongeduard commented on 2021-09-15 23:07 (UTC) (edited on 2021-09-15 23:12 (UTC) by jongeduard)

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

johnhamelink commented on 2021-09-14 19:09 (UTC) (edited on 2021-09-14 19:10 (UTC) by johnhamelink)

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.

Yann.O commented on 2021-09-14 11:38 (UTC)

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

FrederickZh commented on 2021-09-10 08:48 (UTC)

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

Ranguvar commented on 2021-09-09 02:19 (UTC)

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.

fryfrog commented on 2021-07-22 03:51 (UTC)

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

nesv commented on 2021-07-22 03:45 (UTC)

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.

itoffshore commented on 2021-06-29 20:29 (UTC) (edited on 2021-07-29 10:37 (UTC) by itoffshore)

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

eschwartz commented on 2021-06-08 15:32 (UTC)

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.

eschwartz commented on 2021-06-08 12:17 (UTC)

No

tuxzz commented on 2021-06-08 11:44 (UTC)

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

bone commented on 2021-05-25 18:25 (UTC)

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!

fryfrog commented on 2021-05-07 14:57 (UTC)

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

iusrlinearb commented on 2021-05-07 06:37 (UTC)

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?

eschwartz commented on 2021-05-06 14:30 (UTC)

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.

thaewrapt commented on 2021-05-06 12:24 (UTC)

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.

risto3 commented on 2021-05-06 12:12 (UTC)

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?

lysergia commented on 2021-04-01 19:11 (UTC)

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.

qs9rx commented on 2021-04-01 18:50 (UTC)

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.

Ranguvar commented on 2021-03-11 05:07 (UTC) (edited on 2021-03-11 05:07 (UTC) by Ranguvar)

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

eschwartz commented on 2021-02-14 03:30 (UTC)

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.

lysergia commented on 2021-02-13 18:21 (UTC)

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

andrej commented on 2021-02-13 18:05 (UTC)

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.

thedanbob commented on 2021-02-07 20:10 (UTC)

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

Ranguvar commented on 2021-02-06 02:05 (UTC) (edited on 2021-02-06 02:08 (UTC) by Ranguvar)

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

greencopper commented on 2021-02-06 01:36 (UTC)

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

Zepman commented on 2021-02-05 07:32 (UTC) (edited on 2021-02-05 07:51 (UTC) by Zepman)

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.

Ranguvar commented on 2021-02-03 04:59 (UTC)

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

eschwartz commented on 2021-01-29 00:07 (UTC)

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.

gammy commented on 2021-01-25 13:25 (UTC)

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

2G_Storm commented on 2021-01-19 08:48 (UTC)

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

iusrlinearb commented on 2021-01-13 16:20 (UTC)

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

eschwartz commented on 2021-01-13 16:08 (UTC)

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

iusrlinearb commented on 2021-01-13 15:48 (UTC)

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

2G_Storm commented on 2021-01-13 08:36 (UTC)

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

bobobo1618 commented on 2021-01-05 16:28 (UTC)

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.

compkronos commented on 2021-01-01 19:56 (UTC)

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

edacval commented on 2020-12-30 07:13 (UTC) (edited on 2020-12-30 07:13 (UTC) by edacval)

@Ranguvar Upstream Issue

Ranguvar commented on 2020-12-27 19:53 (UTC)

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.

lockheed commented on 2020-12-10 09:38 (UTC)

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

greencopper commented on 2020-12-09 22:38 (UTC)

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

fryfrog commented on 2020-12-09 22:19 (UTC)

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.

greencopper commented on 2020-12-09 22:07 (UTC)

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

khampf commented on 2020-10-18 01:01 (UTC) (edited on 2020-10-18 01:01 (UTC) by khampf)

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.

2G_Storm commented on 2020-10-14 15:22 (UTC)

@fryfrog i will try now, thanks a lot

fryfrog commented on 2020-10-14 15:21 (UTC)

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.

2G_Storm commented on 2020-10-14 15:18 (UTC) (edited on 2020-10-14 15:21 (UTC) by 2G_Storm)

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

fryfrog commented on 2020-10-14 15:10 (UTC)

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

2G_Storm commented on 2020-10-14 07:43 (UTC)

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

Asgaroth commented on 2020-08-22 14:23 (UTC)

try:

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

eschwartz commented on 2020-08-21 19:29 (UTC)

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

utsi commented on 2020-08-20 08:00 (UTC) (edited on 2020-08-20 08:02 (UTC) by utsi)

@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

FrederickZh commented on 2020-08-20 07:56 (UTC)

Have some of you guys blocked me or what? lol

greencopper commented on 2020-08-20 07:20 (UTC)

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

greencopper commented on 2020-08-20 07:04 (UTC)

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

cdesai commented on 2020-08-19 14:14 (UTC)

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

2G_Storm commented on 2020-08-19 10:11 (UTC)

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

utsi commented on 2020-08-18 11:28 (UTC)

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 :)

greencopper commented on 2020-08-18 10:13 (UTC) (edited on 2020-08-18 12:51 (UTC) by greencopper)

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'

melkor217 commented on 2020-08-17 20:50 (UTC)

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.

borgman_jeremy commented on 2020-08-17 15:04 (UTC)

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

FrederickZh commented on 2020-08-15 13:41 (UTC)

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

fryfrog commented on 2020-06-17 20:27 (UTC)

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?

sphere101 commented on 2020-06-17 20:25 (UTC)

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

sunflsks commented on 2020-06-02 16:20 (UTC)

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

itoffshore commented on 2020-06-02 16:01 (UTC) (edited on 2020-06-02 16:02 (UTC) by itoffshore)

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

sunflsks commented on 2020-06-02 14:10 (UTC)

Question, how did you downgrade gcc?

itoffshore commented on 2020-06-02 11:43 (UTC) (edited on 2020-06-02 15:59 (UTC) by itoffshore)

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

jjb2016 commented on 2020-05-24 07:51 (UTC) (edited on 2020-05-24 11:52 (UTC) by jjb2016)

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

pacman -R zfs-dkms zfs-utils
And then ...
yay -S zfs-dkms
Reboot after that. zfs-utils will be automatically installed as a dependency. This has always worked for me when I've needed to do it. The only thing to note is that the /etc/zfs/zed.d/zed.rc file will be replaced with a new default file, so if you've made any changes in there for the zed service (for example for email notifications) then you will have to edit that file again, or restore it from a backup.

Marius_Elvenwood commented on 2020-05-24 01:01 (UTC)

@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

FrederickZh commented on 2020-05-24 00:22 (UTC)

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.

Marius_Elvenwood commented on 2020-05-24 00:17 (UTC) (edited on 2020-05-24 00:17 (UTC) by Marius_Elvenwood)

@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

FrederickZh commented on 2020-05-23 23:24 (UTC)

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.

fryfrog commented on 2020-05-23 22:37 (UTC)

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

Marius_Elvenwood commented on 2020-05-23 22:34 (UTC)

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?

sfranchi commented on 2020-05-11 18:06 (UTC) (edited on 2020-05-11 18:07 (UTC) by sfranchi)

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

eschwartz commented on 2020-05-11 17:59 (UTC)

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

sfranchi commented on 2020-05-11 17:54 (UTC) (edited on 2020-05-11 17:56 (UTC) by sfranchi)

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?

eschwartz commented on 2020-05-01 15:53 (UTC)

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

Zod commented on 2020-05-01 15:50 (UTC)

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.

sfranchi commented on 2020-05-01 14:16 (UTC) (edited on 2020-05-01 15:51 (UTC) by eschwartz)

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.

dmshimself commented on 2020-04-16 00:41 (UTC)

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.

fryfrog commented on 2020-04-15 23:42 (UTC) (edited on 2020-04-15 23:42 (UTC) by fryfrog)

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.

dmshimself commented on 2020-04-15 23:36 (UTC)

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.

dmshimself commented on 2020-04-15 19:32 (UTC)

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.

itoffshore commented on 2020-04-15 10:44 (UTC)

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

ck2katAUR commented on 2020-04-15 09:45 (UTC) (edited on 2020-04-15 11:56 (UTC) by ck2katAUR)

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

wjlafrance commented on 2020-04-15 06:08 (UTC)

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

dmshimself commented on 2020-04-14 21:42 (UTC)

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

eschwartz commented on 2020-04-14 20:19 (UTC) (edited on 2020-04-14 20:24 (UTC) by eschwartz)

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.

freswa commented on 2020-04-14 17:50 (UTC)

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

fryfrog commented on 2020-04-14 14:18 (UTC)

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

itoffshore commented on 2020-04-14 14:09 (UTC) (edited on 2020-04-15 10:33 (UTC) by itoffshore)

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

ck2katAUR commented on 2020-04-14 13:40 (UTC)

@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

fryfrog commented on 2020-04-07 02:40 (UTC)

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

FrederickZh commented on 2020-04-07 02:35 (UTC)

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

Atomisirsi commented on 2020-04-06 19:40 (UTC)

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

itoffshore commented on 2020-04-01 07:52 (UTC) (edited on 2020-04-14 13:58 (UTC) by itoffshore)

@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

eschwartz commented on 2020-03-31 22:30 (UTC)

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?

iusrlinearb commented on 2020-03-26 21:17 (UTC)

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

Achelous commented on 2020-03-26 19:58 (UTC)

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

iusrlinearb commented on 2020-03-25 15:36 (UTC) (edited on 2020-03-25 16:13 (UTC) by iusrlinearb)

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.

eschwartz commented on 2020-03-23 15:52 (UTC) (edited on 2020-03-23 15:52 (UTC) by eschwartz)

@LinuxIsBest,

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

eschwartz commented on 2020-03-22 16:01 (UTC) (edited on 2020-03-22 16:03 (UTC) by eschwartz)

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.

risto3 commented on 2020-03-17 08:20 (UTC)

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

SenileAnimal commented on 2020-03-14 01:49 (UTC)

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.

xerxes commented on 2020-03-04 20:01 (UTC)

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

sphere101 commented on 2020-03-04 13:46 (UTC)

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.

vk77de commented on 2020-03-01 21:43 (UTC)

@mikeyyve: compiles. The filesystem is mountable

mikeyyve commented on 2020-03-01 21:21 (UTC)

Anyone tried kernel 5.5 with the changes eschwartz uploaded?

eschwartz commented on 2020-02-28 17:29 (UTC) (edited on 2020-02-28 17:44 (UTC) by eschwartz)

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

tleydxdy commented on 2020-02-26 18:00 (UTC) (edited on 2020-02-29 04:33 (UTC) by tleydxdy)

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

sphere101 commented on 2020-02-23 13:33 (UTC)

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!

pgeorgiadis commented on 2020-02-23 10:25 (UTC) (edited on 2020-02-23 10:27 (UTC) by pgeorgiadis)

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.

freswa commented on 2020-02-22 10:03 (UTC)

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.

sphere101 commented on 2020-02-22 03:45 (UTC) (edited on 2020-02-26 18:16 (UTC) by eschwartz)

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?

eblau commented on 2020-02-20 13:35 (UTC) (edited on 2020-02-20 13:35 (UTC) by eblau)

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.

sphere101 commented on 2020-02-20 13:15 (UTC)

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

SRossi commented on 2020-02-12 13:25 (UTC)

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

freswa commented on 2020-02-12 10:57 (UTC)

@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

fryfrog commented on 2020-02-12 07:54 (UTC)

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

SRossi commented on 2020-02-12 07:46 (UTC)

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

fryfrog commented on 2020-02-12 07:38 (UTC) (edited on 2020-02-12 07:39 (UTC) by fryfrog)

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.

SRossi commented on 2020-02-12 06:14 (UTC)

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

eschwartz commented on 2020-02-11 15:02 (UTC)

@SRossi,

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

SRossi commented on 2020-02-11 14:08 (UTC)

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?

2G_Storm commented on 2020-02-11 10:05 (UTC)

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?

tleydxdy commented on 2020-02-04 19:36 (UTC)

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)

ceratophllum commented on 2020-02-04 13:02 (UTC) (edited on 2020-02-04 13:04 (UTC) by ceratophllum)

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'

thedanbob commented on 2020-02-04 13:00 (UTC)

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

fryfrog commented on 2020-01-14 21:06 (UTC)

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

cyounkins commented on 2020-01-14 19:38 (UTC)

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

freswa commented on 2020-01-07 13:44 (UTC)

Kernel 5.4 is working fine.

sphere101 commented on 2020-01-07 13:43 (UTC)

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

xiaoliniess commented on 2019-12-27 12:03 (UTC)

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

Tom_B commented on 2019-12-20 23:04 (UTC)

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.

Tom_B commented on 2019-12-16 13:40 (UTC)

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?

archfroggy commented on 2019-11-14 15:11 (UTC)

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

eschwartz commented on 2019-10-02 01:12 (UTC)

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

Y5Lf8U0y5wFg4ktU commented on 2019-10-01 09:36 (UTC)

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.

sphere101 commented on 2019-09-30 19:50 (UTC)

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

dharrigan commented on 2019-09-30 18:53 (UTC)

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

fryfrog commented on 2019-09-30 16:21 (UTC) (edited on 2019-09-30 16:22 (UTC) by fryfrog)

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

sphere101 commented on 2019-09-30 16:19 (UTC)

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?

eschwartz commented on 2019-09-27 00:08 (UTC)

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

eschwartz commented on 2019-09-24 11:43 (UTC)

Fixed, hunted down and grabbed commits from master instead.

freswa commented on 2019-09-24 11:28 (UTC) (edited on 2019-09-24 11:28 (UTC) by freswa)

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

2G_Storm commented on 2019-09-24 08:21 (UTC) (edited on 2019-09-24 08:24 (UTC) by 2G_Storm)

Does it still break with 5.3 kernel?

bone commented on 2019-09-24 07:37 (UTC) (edited on 2019-09-24 07:42 (UTC) by bone)

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?)

eschwartz commented on 2019-09-20 18:29 (UTC)

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.

fryfrog commented on 2019-09-20 18:21 (UTC)

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

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

vk77de commented on 2019-09-20 18:19 (UTC)

linux 5.3.arch1-1 breaks ZFS

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

patrickh commented on 2019-08-11 11:02 (UTC) (edited on 2019-08-11 11:05 (UTC) by patrickh)

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

edacval commented on 2019-08-11 09:56 (UTC)

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

patrickh commented on 2019-08-11 07:48 (UTC) (edited on 2019-08-11 07:49 (UTC) by patrickh)

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.

fryfrog commented on 2019-07-25 18:40 (UTC)

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

thedanbob commented on 2019-07-11 10:57 (UTC)

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

eschwartz commented on 2019-05-19 03:30 (UTC)

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.

rwha commented on 2019-05-18 15:09 (UTC) (edited on 2019-05-18 15:10 (UTC) by rwha)

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)

jjb2016 commented on 2019-05-18 13:12 (UTC)

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

ceratophllum commented on 2019-05-18 13:06 (UTC) (edited on 2019-05-18 13:07 (UTC) by ceratophllum)

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

eblau commented on 2019-05-18 12:13 (UTC) (edited on 2019-05-18 12:13 (UTC) by eblau)

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?

eschwartz commented on 2019-03-29 06:50 (UTC) (edited on 2019-04-02 17:12 (UTC) by eschwartz)

@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

milaxnuts commented on 2019-03-29 06:08 (UTC)

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

eschwartz commented on 2019-03-28 18:28 (UTC)

@greencopper,

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

greencopper commented on 2019-03-28 00:23 (UTC) (edited on 2019-04-01 13:47 (UTC) by greencopper)

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!

karcher commented on 2019-03-11 19:10 (UTC)

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

eschwartz commented on 2019-03-11 05:42 (UTC)

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.

vanja_z commented on 2019-03-11 04:40 (UTC) (edited on 2019-03-11 04:46 (UTC) by vanja_z)

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.

eschwartz commented on 2019-03-11 02:25 (UTC) (edited on 2019-03-11 19:12 (UTC) by eschwartz)

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

karcher commented on 2019-03-11 01:42 (UTC)

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?

vanja_z commented on 2019-03-08 13:28 (UTC)

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?

eschwartz commented on 2019-03-07 17:52 (UTC)

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.

vanja_z commented on 2019-03-07 10:36 (UTC) (edited on 2019-03-07 10:37 (UTC) by vanja_z)

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.

T4cC0re commented on 2018-12-31 22:06 (UTC) (edited on 2019-01-01 06:57 (UTC) by T4cC0re)

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

karcher commented on 2018-11-05 23:43 (UTC) (edited on 2018-11-05 23:49 (UTC) by karcher)

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

eschwartz commented on 2018-11-05 22:55 (UTC)

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.

karcher commented on 2018-11-05 22:37 (UTC) (edited on 2018-11-05 22:39 (UTC) by karcher)

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

othiman commented on 2018-11-02 21:30 (UTC)

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.

mrueg commented on 2018-11-02 21:05 (UTC) (edited on 2018-11-02 21:28 (UTC) by mrueg)

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

eschwartz commented on 2018-10-31 15:38 (UTC)

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.

solnce commented on 2018-10-31 14:05 (UTC)

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.

eschwartz commented on 2018-10-30 20:20 (UTC)

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.

othiman commented on 2018-10-30 15:05 (UTC)

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

eschwartz commented on 2018-10-30 02:28 (UTC)

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.

solnce commented on 2018-10-28 22:06 (UTC) (edited on 2018-10-28 22:09 (UTC) by solnce)

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

karcher commented on 2018-10-25 18:45 (UTC)

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

allspark commented on 2018-10-24 20:10 (UTC)

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

karcher commented on 2018-10-23 09:57 (UTC)

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

sylveon commented on 2018-10-21 16:21 (UTC)

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.

allspark commented on 2018-10-20 09:09 (UTC)

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

RubenKelevra commented on 2018-10-18 03:23 (UTC)

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

hzhangxyz commented on 2018-10-15 14:40 (UTC)

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

lilydjwg commented on 2018-10-12 07:44 (UTC)

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

bus commented on 2018-10-11 17:19 (UTC) (edited on 2018-10-11 17:19 (UTC) by bus)

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

RubenKelevra commented on 2018-10-11 05:20 (UTC)

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

karcher commented on 2018-10-07 09:14 (UTC)

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?

adlerweb commented on 2018-09-25 08:47 (UTC)

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

minextu commented on 2018-09-10 09:07 (UTC)

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

Kaedo commented on 2018-09-10 08:46 (UTC) (edited on 2018-09-10 08:47 (UTC) by Kaedo)

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?

pgoetz commented on 2018-09-09 12:23 (UTC)

0.7.10 was just released and appears to fix this problem.

pgoetz commented on 2018-09-08 17:11 (UTC) (edited on 2018-09-08 17:12 (UTC) by pgoetz)

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?

ultdev commented on 2018-08-18 01:39 (UTC)

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

ultdev commented on 2018-08-18 00:58 (UTC) (edited on 2018-08-18 00:58 (UTC) by ultdev)

@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

teejer commented on 2018-08-17 22:31 (UTC)

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

sylveon commented on 2018-08-06 03:40 (UTC)

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

sudobash418 commented on 2018-08-04 06:25 (UTC)

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

sylveon commented on 2018-06-10 16:39 (UTC)

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.

Achelous commented on 2018-06-09 17:04 (UTC)

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.

eschwartz commented on 2018-05-06 17:02 (UTC) (edited on 2018-05-06 21:29 (UTC) by eschwartz)

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.

eschwartz commented on 2018-05-06 17:02 (UTC) (edited on 2018-05-06 21:29 (UTC) by eschwartz)

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.

RubenKelevra commented on 2018-05-05 13:41 (UTC)

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.

RubenKelevra commented on 2018-05-05 13:38 (UTC)

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.

bus commented on 2018-04-22 17:31 (UTC)

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.

zlima12 commented on 2018-04-12 04:39 (UTC)

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

breul99 commented on 2018-04-11 18:31 (UTC)

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

leothrix commented on 2018-03-24 03:38 (UTC)

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.

leothrix commented on 2018-03-24 03:37 (UTC)

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.

Haggy commented on 2018-02-28 08:52 (UTC)

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.

planetes commented on 2018-02-10 20:56 (UTC)

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.

planetes commented on 2018-02-10 20:53 (UTC)

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

risto3 commented on 2018-02-06 16:35 (UTC) (edited on 2018-02-06 16:57 (UTC) by risto3)

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

jjb2016 commented on 2018-01-02 15:42 (UTC)

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

jjb2016 commented on 2018-01-02 11:15 (UTC)

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?

lilydjwg commented on 2017-12-22 00:29 (UTC)

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

misanthropist commented on 2017-12-21 16:50 (UTC)

@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

mrueg commented on 2017-12-14 23:24 (UTC)

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

codyps commented on 2017-12-04 21:17 (UTC) (edited on 2017-12-04 21:17 (UTC) by codyps)

broken with linux 4.14

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

jcstryker commented on 2017-11-28 18:46 (UTC)

Would it be a good idea to have this package support the zfs-utils-common package along with spl-utils-common?

sylveon commented on 2017-11-06 02:37 (UTC)

No, a stable release has not made it with encryption yet. You're probably searching for zfs-dkms-git if you want encryption.

francoism90 commented on 2017-11-05 19:13 (UTC) (edited on 2017-11-05 19:13 (UTC) by francoism90)

I'm a bit confused should this release not include encryption?

zhangyoufu commented on 2017-08-21 10:03 (UTC) (edited on 2017-08-21 10:04 (UTC) by zhangyoufu)

zfs datasets mounted by zfs.initcpio.hook got incorrect options. The line related: mount -t zfs -o "zfsutil,${rwopt_exp}" "${dataset}" "${node}${mountpoint}" Calling mount manually ignores several options set on the zfs dataset. For example, I set zfs option atime=no on my rootfs and the result is relatime enabled. (showing as temporary in zfs get) I made a small utility(~11K binary) doing what zfs mount does and put it inside initramfs. See https://github.com/zhangyoufu/zfs_mount I changed `mount -t zfs -o` to my `zfs_mount` and get this problem fixed. A better solution would be providing something similar to altroot for zfs mount command, which requires upstream changes.

zhangyoufu commented on 2017-08-19 06:10 (UTC)

@isiachi zfs.initcpio.hook has a typo 2&>1 creates a file with name '1' at initrd root

isiachi commented on 2017-08-13 08:27 (UTC)

Hi all, I'm back home today from my holidays. I will push an update later today. Isiachi

demizer commented on 2017-08-02 01:19 (UTC)

Hello! We just added support to the archzfs project and repository for these PKGBUILDS. Could we discuss adding the archzfs maintainers on as co-maintainers to this AUR package? See https://github.com/archzfs/archzfs/issues/157

demizer commented on 2017-08-02 01:18 (UTC)

Hello! We just added support to the archzfs project and repository for these PKGBUILDS. Could we discuss adding the archzfs maintainers on as co-maintainers to this AUR package? See https://github.com/archzfs/archzfs/issues/157

sylveon commented on 2017-07-21 16:56 (UTC)

Quite easy actually. Run "dkms install {spl,zfs}/0.6.5.10 -k 4.11.9-1-vfio" and regenerate your initramfs (mkinitcpio -p linux-vfio)

ram4444 commented on 2017-07-21 14:54 (UTC) (edited on 2017-07-21 15:21 (UTC) by ram4444)

Same error as gkjarch commented on 2017-06-25 10:43 when installing linux-vfio kernel :: Running pre-transaction hooks... (1/1) Remove DKMS modules ==> dkms remove zfs/0.6.5.10 -k 4.11.9-1-vfio ==> dkms remove spl/0.6.5.10 -k 4.11.9-1-vfio :: Processing package changes... (1/3) reinstalling linux-vfio [######################] 100% >>> Updating module dependencies. Please wait ... (2/3) reinstalling linux-vfio-docs [######################] 100% (3/3) reinstalling linux-vfio-headers [######################] 100% :: Running post-transaction hooks... (1/3) Install DKMS modules ==> dkms install zfs/0.6.5.10 -k 4.11.9-1-vfio configure: error: *** Please make sure the kmod spl devel <kernel> package for your *** distribution is installed then try again. If that fails you *** can specify the location of the spl objects with the *** '--with-spl-obj=PATH' option. Error! Bad return status for module build on kernel: 4.11.9-1-vfio (x86_64) Consult /var/lib/dkms/zfs/0.6.5.10/build/make.log for more information. ==> dkms install spl/0.6.5.10 -k 4.11.9-1-vfio as it forced to remove spl & zfs first and then install them one by one again (with zfs comes first) I have tried to run zfs-dkms install alone and get the same error. It is shown that the installaion knows the spl dependency, but installation cant continue after zfs as dependency may be in wrong order. Here comes the error code: -------------------------------------------------- checking kernel source version... 4.11.9-1-vfio checking kernel file name for module symbols... Module.symvers checking spl source directory... /usr/src/spl-0.6.5.10 checking spl build directory... /var/lib/dkms/spl/0.6.5.10/4.11.9-1-vfio/x86_64 configure: error: *** Please make sure the kmod spl devel <kernel> package for your *** distribution is installed then try again. If that fails you *** can specify the location of the spl objects with the *** '--with-spl-obj=PATH' option. Building module: cleaning build area...(bad exit status: 2) make -j12 KERNELRELEASE=4.11.9-1-vfio...(bad exit status: 2) Error! Bad return status for module build on kernel: 4.11.9-1-vfio (x86_64) Consult /var/lib/dkms/zfs/0.6.5.10/build/make.log for more information. ------------------------------------------------------------- Talked Maintainer of linux-vfio. He told me here to ask for help. Could any body help? Thank you very much

minextu commented on 2017-07-08 21:17 (UTC)

Please remove zlib_deflate in zfs.initcpio.install, to get rid of the error message during mkinitcpio

jjb2016 commented on 2017-07-06 08:07 (UTC)

Skjeggape - I had this issue when I upgraded zfs to the git version and then tried to install the 0.6.5.10 version. 0.7 version has some new features which aren't supported in 0.6.5.10. Did you upgrade to 0.7?

skjeggape commented on 2017-07-04 20:56 (UTC)

After latest update my system wont boot, normal recover procedure wont solve the issue. at boot i get following error: https://goo.gl/photos/AZ4xTEHVJFPpCdg46 This pool uses the following feature(s) not supported by this system: org.zfsonlinux:userobj_accounting (User/Group object accounting.) All unsupported features are only required for writing to the pool. The pool can be imported using '-o readonly=on'. cannot import 'poolname' error failed to mount real root etc etc.

isiachi commented on 2017-06-29 23:26 (UTC)

The spl-dkms package contains a patch to build on gcc 7.1. @gkjarch You have to install spl-dkms, spl-utils, zfs-dkms, zfs-utils all together or install spl-dkms and spl-utils with the -d option of pacman.

gkjarch commented on 2017-06-25 02:43 (UTC)

1. When upgrading from 0.6.5.9 to 0.6.5.10, the spl-dkms upgrade succefully, but zfs-dkms got an error something like break dependence between spl-dkms 0.6.5.10 and zfs-dkms 0.6.5.9 . Therefore I have to use "pacman -Rns zfs-dkms" and reinstall. I can not get the log. 2. When upgrading linux-lts, dkms can not resolve dependence. Log: :: Processing package changes... (1/2) upgrading linux-lts [####################################] 100% >>> Updating module dependencies. Please wait ... (2/2) upgrading linux-lts-headers [####################################] 100% :: Running post-transaction hooks... (1/3) Install DKMS modules ==> dkms install zfs/0.6.5.10 -k 4.9.34-1-lts configure: error: *** Please make sure the kmod spl devel <kernel> package for your *** distribution is installed then try again. If that fails you *** can specify the location of the spl objects with the *** '--with-spl-obj=PATH' option. Error! Bad return status for module build on kernel: 4.9.34-1-lts (x86_64) Consult /var/lib/dkms/zfs/0.6.5.10/build/make.log for more information. ==> dkms install vboxguest/5.1.22_OSE -k 4.9.34-1-lts Job for systemd-modules-load.service failed because the control process exited with error code. See "systemctl status systemd-modules-load.service" and "journalctl -xe" for details. ==> dkms install vboxhost/5.1.22_OSE -k 4.9.34-1-lts Job for systemd-modules-load.service failed because the control process exited with error code. See "systemctl status systemd-modules-load.service" and "journalctl -xe" for details. ==> dkms install spl/0.6.5.10 -k 4.9.34-1-lts Job for systemd-modules-load.service failed because the control process exited with error code. See "systemctl status systemd-modules-load.service" and "journalctl -xe" for details. (2/3) Updating linux-lts initcpios

RubenKelevra commented on 2017-06-25 02:15 (UTC) (edited on 2017-06-25 02:17 (UTC) by RubenKelevra)

@charlesmilette I did the out of date flag to notify him, that there is already a patch available for building SPL and ZFS with GCC7.1 again. But it seemed to have overlapped with his update push - so thanks! :)

sylveon commented on 2017-06-24 14:20 (UTC)

Poor package maintainer. It's already been flagged out of date.

RubenKelevra commented on 2017-06-24 14:15 (UTC)

A shorter reaction time of the package maintainer would be nice.

Zazzman commented on 2017-06-22 16:31 (UTC)

The solution I'm using? I edit the PKGBUILDs to use: https://github.com/tonyhutter/zfs.git https://github.com/tonyhutter/spl.git that's the guy who's patching upstream for gcc-7.1 ;)

emacsomancer commented on 2017-06-22 00:07 (UTC)

I've been running with zfs-0.6.5.10/spl-0.6.5.10 on Void Linux, and it seems to work fine with the latest 4.11 kernel. FYI.

jjb2016 commented on 2017-06-20 19:14 (UTC)

The AUR package should be updated for 0.6.5.10 but in the meantime I have been able to successfully build and install spl-dkms & zfs-dkms 0.6.5.10 for linux 4.11.6. You need downgrade gcc to version <= 6.3.1 first. Download the snapshot for spl-dkms & zfs-dkms and edit the pkgver from 0.6.5.9 to 0.6.5.10 in the PKGBUILD files for each.

hawk07 commented on 2017-06-20 18:29 (UTC)

Please upgrade https://github.com/zfsonlinux/spl/releases/tag/spl-0.6.5.10

hawk07 commented on 2017-06-20 18:24 (UTC)

please upgrade https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.6.5.10

lilydjwg commented on 2017-06-17 14:32 (UTC)

I encountered this too. I bypassed this bug by removing all instances of "-Werror" in /usr/src/spl-0.6.5.9/configure.

scott32 commented on 2017-06-12 21:05 (UTC)

upstream bug: https://github.com/zfsonlinux/spl/issues/620

teejer commented on 2017-06-12 17:15 (UTC) (edited on 2017-06-12 17:16 (UTC) by teejer)

This doesn't seem to be able to compile with the new gcc 7 release. The log said something about treating warnings as errors. I don't have the log file anymore unfortunately. I ended up reverting to gcc-6.3.1-2 to get this to compile successfully. This was with kernel 4.9.30 and .31

ecraven commented on 2017-05-26 18:27 (UTC) (edited on 2017-05-26 18:32 (UTC) by ecraven)

This fails for me when building with 4.11.2-1-ARCH (x86_64) .... checking whether CONFIG_ZLIB_INFLATE is defined... yes checking whether CONFIG_ZLIB_DEFLATE is defined... yes checking whether zlib_deflate_workspacesize() wants 2 args... yes checking whether struct shrink_control exists... yes checking whether struct rw_semaphore member wait_lock is raw... yes checking whether struct rw_semaphore has member activity... no checking whether struct rw_semaphore has atomic_long_t member count... yes checking whether header linux/sched/rt.h exists... yes checking whether vfs_getattr() wants... configure: error: unknown Building module: cleaning build area...(bad exit status: 2) make -j2 KERNELRELEASE=4.11.2-1-ARCH...(bad exit status: 2) Error! Bad return status for module build on kernel: 4.11.2-1-ARCH (x86_64) Consult /var/lib/dkms/spl/0.6.5.9/build/make.log for more information. $ cat /var/lib/dkms/spl/0.6.5.9/build/make.log DKMS make.log for spl-0.6.5.9 for kernel 4.11.2-1-ARCH (x86_64) Fri 26 May 20:21:31 CEST 2017 make: *** No targets specified and no makefile found. Stop. Also see github: https://github.com/zfsonlinux/spl/issues/618

sulaweyo commented on 2017-05-23 16:40 (UTC) (edited on 2017-05-23 16:41 (UTC) by sulaweyo)

4.11 kernel support is in 0.7.0 release of zol. Guess we will have to wait for a release or go with the current RC which is might be a bit dangerous for a filesystem. https://github.com/zfsonlinux/zfs/releases

bus commented on 2017-05-21 05:34 (UTC)

dkms install fails on 4.11.2-1-ck-sandybridge. make.log reports: make: *** No targets specified and no makefile found. Stop.

Horus commented on 2017-05-05 07:03 (UTC)

For me it works fine with 4.10.11.

saivert commented on 2017-05-04 12:47 (UTC) (edited on 2017-05-04 12:47 (UTC) by saivert)

No update since kernel 4.10 came out a while ago? Are we just to assume it works with any newer kernel?

dreieck commented on 2017-04-13 11:22 (UTC) (edited on 2017-04-13 11:36 (UTC) by dreieck)

@Iaec: I made a patch for the PKGBUILD (can be used with customizepkg(-scripting)) implementing your suggestions: http://ix.io/qvF The two files you suggest are at 60-dkms-install-zfs.hook::http://ix.io/qvu and dkms-install-spl-zfs.sh::http://ix.io/qvv respectively (although I do not install the bash script to /usr/share/libalpm/hooks/, rather to /usr/lib/dkms/. Does anyone know where it should really belong?)

dreieck commented on 2017-04-13 10:47 (UTC) (edited on 2017-04-13 11:16 (UTC) by dreieck)

For the package 'zfs-dkms', please add conflicts=('zfs-linux') (It does, in fact) and provices=("zfs-linux=${pkgver}") (it does, in fact, and is needed by other packages depending on zfs-linux). (I am referencing to conflicts and dependencies with the packages at the repository [archzfs] Server = http://archzfs.com/$repo/x86_64) For the package 'zfs-utils', please add conflicts=('zfs-utils-linux') (It does, in fact) and provices=("zfs-utils-linux=${pkgver}") (it does, in fact, and is needed by other packages depending on zfs-linux). (I am referencing to conflicts and dependencies with the packages at the repository [archzfs] Server = http://archzfs.com/$repo/x86_64)

dreieck commented on 2017-04-13 10:45 (UTC) (edited on 2017-04-13 11:17 (UTC) by dreieck)

For the package "spl-dkms", please add conflicts=('spl-linux') (It does, in fact) and provices=("spl-linux=${pkgver}") (it does, in fact, and is needed by other packages depending on spl-linux). For the package "spl-utils", please add conflicts=('spl-utils-linux') (It does, in fact) and provices=("spl-utils-linux=${pkgver}") (it does, in fact, and is needed by other packages depending on spl-linux). (I am referencing to conflicts and dependencies with the packages at the repository [archzfs] Server = http://archzfs.com/$repo/x86_64)

commented on 2017-04-12 09:31 (UTC)

@masteroman I have the same issue, I use an alpm hook (https://www.archlinux.org/pacman/alpm-hooks.5.html) to workaround it: 1. Place this hook in /usr/share/libalpm/hooks/60-dkms-install-zfs.hook, this should execute before the default 70-dkms-install.hook [Trigger] Operation = Install Operation = Upgrade Type = File Target = usr/src/sql-*/dkms.conf Target = usr/src/zfs-*/dkms.conf Target = usr/lib/modules/*/kernel/ [Action] Description = Installing ZFS Depends = dkms When = PostTransaction Exec = /usr/share/libalpm/hooks/dkms-install-zfs 2. Place this script in the same directory as the hook and make it executable: #!/bin/bash set -o errexit set -o nounset set -o xtrace install_module() { local module="${1}" local kernel="${2}" for m in $(ls /usr/src); do if [[ "${m}" =~ ^"${module}"-(.*)$ ]]; then dkms install "${module}/${BASH_REMATCH[1]}" -k "${kernel}" fi done } for kernel in $(ls /usr/lib/modules); do if [[ -d "/usr/lib/modules/${kernel}/kernel" ]]; then install_module spl "${kernel}" install_module zfs "${kernel}" fi done this will make sure spl gets installed before zfs, it works for my setup. @isiachi would you consider adding something like this to be part of this package to make it work out of the box?

masteroman commented on 2017-04-07 10:05 (UTC)

Am I wrong or there's wrong order of DKMS installations? Every upgrade of the kernel on my machine fails because of the missing SPL which happens because there's following order of commands: 1. DKMS removes spl and zfs kernel modules 2. DKMS installs zfs kernel module --> fails because of the missing spl module 3. DKMS installs spl module Then I need to manually issue dkms install zfs module.

RubenKelevra commented on 2017-03-13 16:55 (UTC)

@thunderforce I don't try to _install_ but update the package, don't know how you got the thought I would try to install it. @isiachi Nope, you package is broken not an aurhelper script. This is a plane stupid "works for me" reason from your side. If you say "my package need version=xyz" and you want to upgrade the package and the next version has the dependency "I need version=abc" it cannot be upgraded. As well as the dependency cannot be upgraded, because it's a needed dependency with this version for an installed version. I would say, yes this could be fixed in pacman, if they add a layer of complexity: copy all installed package versions, change them to the new versions and checking all constrains. But since this is not done, your package uses a not compatible way of adding a constrain. Since you update both packages at the same time, you could simply add a "higher than xyz" on the zfs package and it would work while updating.

RubenKelevra commented on 2017-03-13 16:44 (UTC)

This package is now again not working with the official kernel package since the compability patches for Linux 4.10 are missing. Please fix this

bus commented on 2017-03-12 17:05 (UTC)

@fow0ryl I use zfs-dkms and I have no problem installing zfs-auto-snapshot-git either with pacaur or with makepkg. Try downloading the PKGBUILD file and installing it with makepkg.

fow0ryl commented on 2017-03-10 19:23 (UTC)

I'm new on manjaro (arch based linux). So I may be wrong. But to me, it looks like that "provides zfs" in zfs-dkms doesn't work. I have zfs running, so I'm sure that zfs-dkms works as expected. But when I try to install i.e. zfs-auto-snapshot-git, which depends on zfs it doesn't recognise "zfs" and try's to install linux...-zfs. Then when I remove depends('zfs') or change is to depends('zfs-dkms') in PKGBUILD of zfs-auto-snapshot-git everything went fine. When I do a "pacman -R zfs" I get "not found" too.

isiachi commented on 2017-02-20 20:47 (UTC)

@thunderforce Thanks for the help! I have already explained that is a aur helper related problem in this comment: isiachi commented on 2016-09-20 19:45

thunderforce commented on 2017-02-20 07:55 (UTC)

@RubenKelevra, not sure why you're trying to install this package, but while trying to use VirtualBox and a google search I ended up here. This fixed the DKMS hook for me: wget https://archive.archlinux.org/packages/l/linux-headers/linux-headers-4.9.8-1-x86_64.pkg.tar.xz sudo pacman -U linux-headers-4.9.8-1-x86_64.pkg.tar.xz .. :: Running post-transaction hooks... (1/2) Install DKMS modules ==> dkms install vboxhost/5.1.14_OSE -k 4.9.8-1-ARCH (2/2) Arming ConditionNeedsUpdate... .. hope it's helpful

RubenKelevra commented on 2017-02-14 02:58 (UTC)

Still issues with a simple update because this PKGBUILD depends on a given version: loading packages... resolving dependencies... looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: zfs-dkms: installing spl-dkms (0.6.5.9-1) breaks dependency 'spl-dkms=0.6.5.8'

RubenKelevra commented on 2017-02-12 14:55 (UTC)

Friday is now two days gone, so where's the update, mate?

RubenKelevra commented on 2017-02-08 22:33 (UTC)

Still no update? Why does it take 5 days for a simple subversion update, which only needs a checksum-push?

isiachi commented on 2017-02-07 00:23 (UTC)

There will be an update in friday.

ShaunPC commented on 2017-02-06 14:57 (UTC)

@scott32 zfs-dkms has not implemented dependency hooks or has implemented them incorrectly as dkms itself has the capability yet zfs will try to build before spl.

scott32 commented on 2017-02-06 13:46 (UTC)

@ShaunPC: "On investigation it appears that dkms already has a module dependency check implemented" ... when I look into /usr/share/libalpm/hooks/70-dkms-install.hook and /usr/lib/dkms/alpm-hook, I don't see any dependency, or module build ordering checks there. What did you mean?

fermatslast commented on 2017-02-06 02:37 (UTC)

To use with a 4.9 kernel, edit the PKGBUILD for both spl-dkms and zfs-dkms, change pkgver to 0.6.5.9

fermatslast commented on 2017-02-06 02:33 (UTC)

To use with a 4.9 kernel, edit the PKGBUILD for both spl-dkms and zfs-dkms, change pkgver to 0.6.5.9

Anton.Latukha commented on 2017-01-30 14:51 (UTC)

Reporting problem I encountered. Upon update, modules not created. Looks like they fail on building. SPL fails first, and then goes ZFS. # dkms autoinstall ===== Results in next errors: ... Building module: cleaning build area... make -j4 KERNELRELEASE=4.9.6-1-ARCH.....(bad exit status: 2) Error! Bad return status for module build on kernel: 4.9.6-1-ARCH (x86_64) Consult /var/lib/dkms/spl/0.6.5.8/build/make.log for more information. ... checking spl build directory... /var/lib/dkms/spl/0.6.5.8/4.9.6-1-ARCH/x86_64 configure: error: *** Please make sure the kmod spl devel <kernel> package for your *** distribution is installed then try again. If that fails you *** can specify the location of the spl objects with the *** '--with-spl-obj=PATH' option. Building module: cleaning build area...(bad exit status: 2) make -j4 KERNELRELEASE=4.9.6-1-ARCH...(bad exit status: 2) Error! Bad return status for module build on kernel: 4.9.6-1-ARCH (x86_64) Consult /var/lib/dkms/zfs/0.6.5.8/build/make.log for more information. Here is logs: ===== dkms-spl-0.6.5.8-build-make.log: https://ghostbin.com/paste/9wart Here hell breaks loose after first error: /var/lib/dkms/spl/0.6.5.8/build/module/spl/spl-cred.c: In function ‘cr_groups_search’: /var/lib/dkms/spl/0.6.5.8/build/module/spl/spl-cred.c:53:20: error: implicit declaration of function ‘GROUP_AT’ [-Werror=implicit-function-declaration] KGID_TO_SGID(GROUP_AT(group_info, mid)); ... dkms-zfs-0.6.5.8-build-make.log: https://ghostbin.com/paste/2rw3k Is almost empty, as I think, because SPL was not found. I can't draw conclusions, ask your judgement. Additional information: ==== $ uname -a Linux Host 4.9.6-1-ARCH #1 SMP PREEMPT Thu Jan 26 09:22:26 CET 2017 x86_64 GNU/Linux Full output of dkms-autoinstall: https://ghostbin.com/paste/js3k3 Hope this is in some help. Thank you, isiachi, for your support.

spheenik commented on 2017-01-27 18:31 (UTC)

Error on 4.9.6-1-ARCH: http://pastebin.com/isjCWxVE

teejer commented on 2017-01-27 15:03 (UTC)

This is failing on the new 4.9 kernel make -j8 KERNELRELEASE=4.9.6-1-ARCH....(bad exit status: 2) Error! Bad return status for module build on kernel: 4.9.6-1-ARCH (x86_64) Consult /var/lib/dkms/spl/0.6.5.8/build/make.log for more information. Here is the make.log file DKMS make.log for spl-0.6.5.8 for kernel 4.9.6-1-ARCH (x86_64) Fri Jan 27 07:59:58 MST 2017 make all-recursive make[1]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build' Making all in include make[2]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include' Making all in fs make[3]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include/fs' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include/fs' Making all in linux make[3]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include/linux' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include/linux' Making all in rpc make[3]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include/rpc' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include/rpc' Making all in sharefs make[3]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include/sharefs' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include/sharefs' Making all in sys make[3]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include/sys' Making all in fm make[4]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include/sys/fm' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include/sys/fm' Making all in fs make[4]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include/sys/fs' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include/sys/fs' Making all in sysevent make[4]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include/sys/sysevent' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include/sys/sysevent' make[4]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include/sys' make[4]: Nothing to be done for 'all-am'. make[4]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include/sys' make[3]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include/sys' Making all in util make[3]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include/util' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include/util' Making all in vm make[3]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include/vm' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include/vm' make[3]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/include' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include' make[2]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/include' Making all in rpm make[2]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/rpm' Making all in generic make[3]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/rpm/generic' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/rpm/generic' Making all in redhat make[3]: Entering directory '/var/lib/dkms/spl/0.6.5.8/build/rpm/redhat' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/var/lib/dkms/spl/0.6.5.8/build/rpm/redhat'

ShaunPC commented on 2016-12-19 15:50 (UTC)

@salvert I too have been having trouble with dkms installing the modules in the wrong order. There does not seem to be an order implemented by the zfs module. On investigation it appears that dkms already has a module dependency check implemented. So my guess is that the zfs module is not using the dkms dependency check correctly. I've been rerunning the dkms install for zfs manually after my updates and then rerunning mkinitcpio to regenerate my kernel images. That has worked for me till this problem gets fixed.

saivert commented on 2016-12-14 13:50 (UTC)

On a recent upgrade to linux 4.8.13-1, the hook for building DKMS modules somehow tried to build zfs before spl and zfs depends on spl.. :: Running post-transaction hooks... ( 1/10) Install DKMS modules ==> dkms install zfs/0.6.5.8 -k 4.8.13-1-ARCH configure: error: *** Please make sure the kmod spl devel <kernel> package for your *** distribution is installed then try again. If that fails you *** can specify the location of the spl objects with the *** '--with-spl-obj=PATH' option. Error! Bad return status for module build on kernel: 4.8.13-1-ARCH (x86_64) Consult /var/lib/dkms/zfs/0.6.5.8/build/make.log for more information. ==> dkms install spl/0.6.5.8 -k 4.8.13-1-ARCH ( 2/10) Updating linux initcpios Is there a way to specify ordering of DKMS modules when building them or is this a problem with this package?

brando56894 commented on 2016-12-13 01:17 (UTC)

You should change the shebang to /usr/bin/python2, when it gets to the L2 summary it crashes for me using python 3.x

lilydjwg commented on 2016-11-04 12:28 (UTC)

You left out a "&" here: https://aur.archlinux.org/cgit/aur.git/tree/zfs.initcpio.hook?h=zfs-dkms#n42

seschwar commented on 2016-10-23 19:31 (UTC)

You can find fixes for my complaints at https://gitlab.com/seschwar/zfs-dkms/commits/master There's also support for GRUB's root=ZFS=mypool/myfs kernel command line syntax.

seschwar commented on 2016-09-22 21:34 (UTC)

@isachi: You updated the initcpio hook to mount all child data sets of the dataset mounted on /. See line 59 in /usr/lib/initcpio/hooks/zfs. This is quite problematic since the script completely ignores the canmount property. Therefore datasets with canmount=off and canmount=noauto get mounted as well. This completely breaks the semantics of these properties. The manual page of the zfs command has the following sentence in it: > Setting this property [canmount] to off allows datasets to be used solely as a mechanism to inherit properties. I had a dataset for /var with canmount=off for exactly this purpose. Imagine my surprise when this empty dataset got mounted leaving me with an almost empty /var. Quite the breaking change you introduced there. I'm not quite sure about the motivation behind this. It could be useful for boot environments. Something similar was discussed recently on a FreeBSD mailing list: https://marc.info/?t=146967172100002&r=1&w=2 However they should be careful when repurposing an established setting of property. Changing how the mounting of datasets work would break backwards compatibility.

isiachi commented on 2016-09-20 19:45 (UTC)

| Upgrading this package from the previous version does not work, you have to remove it and readd to your system. | | The issue is some kind of dependency circle between this package and the spl-dkms: This is because you have to build all the packages on your own and install all of them together. Otherwise you have to install the spl packages with the -d option. # pacman -Ud spl-dkms### spl-utils### This is a AUR helper problem. It's not my fault. Stop saying things that have no sense and learn how to use pacman.

isiachi commented on 2016-09-20 19:36 (UTC)

@RubenKelevra We are talking of a filesystem and this is a stable branch. I've already said that I wasn't going to add a single commit from the master branch, too much things were changed. Unfortunately I wasn't able to lock the package to a specific kernel version because the kernel is not a dependecy. And also take a breath and calm down.

RubenKelevra commented on 2016-09-20 19:34 (UTC) (edited on 2016-09-20 19:34 (UTC) by RubenKelevra)

@utsi just use a conflict constraint for such cases: conflict linux>4.6.xx etc. :)

RubenKelevra commented on 2016-09-20 19:31 (UTC)

Upgrading this package from the previous version does not work, you have to remove it and readd to your system. The issue is some kind of dependency circle between this package and the spl-dkms: Sorry that it is in german: Fehler: Konnte den Vorgang nicht vorbereiten (Kann Abhängigkeiten nicht erfüllen) :: zfs-dkms: das Installieren von spl-dkms (0.6.5.8-1) löscht ein benötigtes Packet von 'spl-dkms=0.6.5.7'

utsi commented on 2016-09-19 08:49 (UTC)

@RubenKelevra Ah, so sorry I misunderstood the issue! As far as accepting the patch I can understand why he would not accept it, only official releases. As for limiting to kernels <4.7, which kernels specifically? linux? linux-lts? linux-ck?

RubenKelevra commented on 2016-09-19 07:12 (UTC) (edited on 2016-09-19 07:15 (UTC) by RubenKelevra)

@babarnescocke I actually dislike if I hit update and my system does not boot up again. This is not a stable behaviour, this is just a broken dependency. This maintainer does not want to fix this or add the 4.7 patch which was provided several weeks ago. If he wants only to support LTS-Kernels he should create a LTS-ZFS package and this is fine, else I would expect more than just a I-dont-like-to-patch behaviour, without fixing the actually dependency issue.

utsi commented on 2016-09-18 23:26 (UTC)

@RubenKelevra It took quite a bit of time for for ZOL to be ready for 4.7. Taking that into account is waiting a few more days for the AUR package to get updated _that_ bad? As babarnescocke said, this is a freaking filesystem, of all the things that should not bug out, this is probably the most important next to the kernel itself. Also thanks to the maintainer, been enjoying your DKMS packages for a while now without issues! :)

isiachi commented on 2016-09-17 17:44 (UTC) (edited on 2016-09-17 17:45 (UTC) by isiachi)

@babarnescocke Thanks I really appreciated!

babarnescocke commented on 2016-09-17 17:05 (UTC)

@RubenKelevra Calm down. I don't want my filesystem on the fritz because people don't want to wait for updates. To be clear, I am not 100% sure what is going on, why the maintainer believes/is right to to think that the PKGBUILD to fix 4.7 linux is unstable - and maybe I would prefer this behavior more in a zfs-lts branch - but this is what you get with the AUR. If you wanted bulletproof support you should have gone to another repo. Maintainer - keep on keeping on, I look forward to the future updates. Thanks for your hardwork.

RubenKelevra commented on 2016-09-15 09:46 (UTC)

No reaction, no update ... what the heck is wrong with the maintainer? :(

RubenKelevra commented on 2016-09-15 09:45 (UTC)

This package is now also out of date for serveral weeks, no kernel support has been added and the new version which is out for a week is also not added. This would add new kernel support...

RubenKelevra commented on 2016-09-11 11:52 (UTC)

This package is completely useless in the current state, might someone else please consider to maintain it? The current approach is not useful at all.

RubenKelevra commented on 2016-09-08 13:18 (UTC)

I have some troubles to install this package on my system: make[1]: Verzeichnis „/tmp/yaourt-tmp-ruben/aur-spl-dkms/src/spl/lib“ wird betreten make[2]: Verzeichnis „/tmp/yaourt-tmp-ruben/aur-spl-dkms/src/spl/lib“ wird betreten make[2]: Für das Ziel „install-exec-am“ ist nichts zu tun. make[2]: Für das Ziel „install-data-am“ ist nichts zu tun. make[2]: Verzeichnis „/tmp/yaourt-tmp-ruben/aur-spl-dkms/src/spl/lib“ wird verlassen make[1]: Verzeichnis „/tmp/yaourt-tmp-ruben/aur-spl-dkms/src/spl/lib“ wird verlassen Making install in cmd make[1]: Verzeichnis „/tmp/yaourt-tmp-ruben/aur-spl-dkms/src/spl/cmd“ wird betreten make[2]: Verzeichnis „/tmp/yaourt-tmp-ruben/aur-spl-dkms/src/spl/cmd“ wird betreten /usr/bin/mkdir -p '/tmp/yaourt-tmp-ruben/aur-spl-dkms/pkg/spl-utils/usr/bin' /bin/sh ../libtool --silent --mode=install ../0 splat '/tmp/yaourt-tmp-ruben/aur-spl-dkms/pkg/spl-utils/usr/bin' ../libtool: line 1720: ../0: No such file or directory make[2]: *** [Makefile:404: install-sbinPROGRAMS] Fehler 127 make[2]: Verzeichnis „/tmp/yaourt-tmp-ruben/aur-spl-dkms/src/spl/cmd“ wird verlassen make[1]: *** [Makefile:586: install-am] Fehler 2 make[1]: Verzeichnis „/tmp/yaourt-tmp-ruben/aur-spl-dkms/src/spl/cmd“ wird verlassen make: *** [Makefile:588: install-recursive] Fehler 1 ==> FEHLER: Ein Fehler geschah in package_spl-utils(). Breche ab... ==> FEHLER:Makepkg konnte spl-dkms nicht erstellen. ==> Erstellen von spl-dkms neu starten?[j/N]

commented on 2016-09-03 06:31 (UTC)

The inability of the package to block the system upgrade due to unsupported kernel version is really troublesome. (Although I do not know if it can be done without adding a dependency on a particular kernel package name.)

isiachi commented on 2016-08-29 08:55 (UTC)

@fermatslast I'm not going to add your patch. This is a stable branch. Use the 4.6 kernel or switch to zfs-dkms-git.

akgrant0710 commented on 2016-08-28 20:18 (UTC)

@fermatslast Thanks for your patch, very much appreciated.

roobre commented on 2016-08-23 23:07 (UTC)

I'm unable to compile it for 4.7.1-1-ARCH, even with the patch @fermatslast supplied. Does anyone have a patch for .1? /var/lib/dkms/spl/0.6.5.7/build/include/linux/file_compat.h:79:45: error: ‘struct inode’ has no member named ‘i_mutex’; did you mean ‘i_mode’? #define spl_inode_lock(ip) mutex_lock(&(ip)->i_mutex)

jrb commented on 2016-08-23 22:42 (UTC)

I just noticed due to differences in service names between RH/Fedora and Arch, /usr/lib/systemd/system/zfs-share.service incorrectly references 'smb.service' instead of 'smbd.service'. I have a patch for the systemd unit in question, as well as a patch for the pkgbuild applying the systemd unit patch (both trivial, obviously), but am unsure of the correct way to submit them.

RubenKelevra commented on 2016-08-16 23:02 (UTC)

Would be great if this package can be guarded with something like linux < 4.7 to avoid an incompatible update because the package-maintainer is sleeping.

escentrix commented on 2016-08-15 13:52 (UTC) (edited on 2016-08-15 13:52 (UTC) by escentrix)

@fermatslast Great! That patch gets me working for now until the upstream stuff gets done. Thanks for your help!

saghm commented on 2016-08-15 05:26 (UTC)

Thanks a bunch! This (and your patch for zfs-dkms) worked beautifully

fermatslast commented on 2016-08-15 04:36 (UTC)

Here's a patch for the pkgbuild that adds a linux 4.7 compatibility patch to the build: https://gist.github.com/burberger/3c966a089529b33714fd8827c4b12e49 This is a temporary fix until the zfsonlinux upstream release has 4.7 support.

fermatslast commented on 2016-08-15 04:33 (UTC)

Here's a patch for the pkgbuild that adds a linux 4.7 compatibility patch to the build: https://gist.github.com/burberger/8fec05e2e8ac5e7a2e59eac270f39629 This is a temporary fix until the zfsonlinux upstream release has 4.7 support.

saghm commented on 2016-08-14 00:35 (UTC)

I'm unable to get the spl module to compile with the newest kernel update (4.7.0-1). I seem to be getting the same issue as https://github.com/zfsonlinux/zfs/issues/4927, but the solution given there requires having the Linux source available. Any idea if/how I can fix this?

escentrix commented on 2016-08-12 20:02 (UTC)

Arch has now moved to 4.7.0 kernel, causing this package some trouble. What all needs to be done to bring this up to speed?

lockheed commented on 2016-08-04 07:44 (UTC)

@isiachi Thanks. However, after compiling the new kernel and installing it, I get this: -> Running build hook: [zfs] ==> ERROR: module not found: `zavl' ==> ERROR: module not found: `znvpair' ==> ERROR: module not found: `zunicode' ==> ERROR: module not found: `zcommon' ==> ERROR: module not found: `zfs' ==> ERROR: module not found: `zpios' ==> ERROR: module not found: `spl' ==> ERROR: module not found: `splat'

isiachi commented on 2016-07-28 11:14 (UTC)

@lockheed If you remove the zfs package the old module are still loaded so you can simple install zfs-dkms.

lockheed commented on 2016-07-27 16:55 (UTC)

I have a technical question, sort of removing the tablecloth underneath the dinner set... I have a server with ZFS on root which runs on regular zfs packages (non-dkms). I need to migrate to zfs-dkms (and friends) to get support for non-stock Arch kernel. The question is: how can I do that? To install -dkms packages, I need to remove regular packages. But if I do that, I am afraid I will not be able to boot (or even operate on root prior to reboot) anymore because the whole root is on ZFS. Can someone propose some sane course of action?

isiachi commented on 2016-07-02 15:11 (UTC) (edited on 2016-07-02 15:12 (UTC) by isiachi)

@seschwar Thanks for the advices. This package is using and will use git to fetch the source. For the alpm-hooks it's not a bad idea. I've already thought about but right now the kernel package updates the initcpio with the old .install script. So basically the initcpio it's always updated before dkms. I'm following this bug report and see what they want to do. (https://bugs.archlinux.org/task/49052)

seschwar commented on 2016-07-01 22:42 (UTC)

When using the tarball instead of Git you wouldn't have to download the whole history of the repository: source=(https://github.com/zfsonlinux/zfs/releases/download/zfs-$pkgver/zfs-$pkgver.tar.gz) Also alpm-hooks(5) for rebuilding the initcpio when the DMKS modules have been rebuilt would be useful if your / is on ZFS.

bazzawill commented on 2016-05-21 05:31 (UTC)

Is it possible to remove the hard version for spl-dkms=0.6.5.7 to allow for higher versions as this would allow upgrades to progress easier

cschwarz commented on 2016-05-08 22:24 (UTC)

Disabling checksum-checking is a bad idea (since 0.6.5.6-2, commit 8f9f7d54b520e920d1561a49b76ee092f6c13d4f). If you don't want to use the tarballs, you should use the commit SHA1,e.g. source=("git+https://github.com/zfsonlinux/zfs.git#commit=<sha1ofrelease>" Otherwise, since the tags are not signed, they could be changed by upstream, rendering inconsistent versioning of this package. Please change this back in all (zfs|spl)-(dkms|utils).

isiachi commented on 2016-04-04 12:52 (UTC)

It's all about build not dep. Upgrade your packages with -d flag.

bazzawill commented on 2016-04-04 07:03 (UTC)

This package is creating dependency hell. Due to spl-dkms. Attempting to update spl-dkms first gives the error "zfs-dkms: installing spl-dkms (0.6.5.6-1) breaks dependency 'spl-dkms=0.6.5.4" However attempting to update zfs-dkms first gives the error that spl-dkms 0.6.5.6 is required (sorry no direct error message). I had to uninstall update spl-dkms then install to bypass.

WoefulDerelict commented on 2015-10-03 05:05 (UTC)

Users can find updated resources for this package at the following URLs while the maintainer is indisposed. https://gist.github.com/WoefulDerelict/2b50b04772a8a74bb913 https://gist.github.com/WoefulDerelict/4d9d715594cb633f0d18

isiachi commented on 2015-09-23 15:43 (UTC)

In the weekend I will update it. Sorry but tomorrow I've got my degree so I'm a little busy.

seblu commented on 2015-09-22 21:05 (UTC)

Could you bump this package, is doesn't works with 4.2 kernels!