Arch Linux User Repository

This package will be kept in sync with the openzfs latest stable release and the kernels officially supported by it.

For the supported kernel versions, refer to the respective openzfs release notes (LINK).

E.g. openzfs 2.3.1 supports kernel versions 4.18 - 6.13. When kernel 6.14 is released for Arch, zfs-linux will not be updated until the openzfs project announces that it's compatible. This will most likely happen with the next openzfs release.

The kernel compatibility of the upcoming openzfs release can be seen in their META file (LINK).

For those wishing to use openzfs with unsupported kernels, do note that this could lead to serious issues, including data loss, even though such a zfs-linux package might build and install cleanly. Have reliable backups and use such a package at your peril.

Please do not mark this package as out of date without checking the kernel compatibility first. Thank you!

I've been using this package for a while now, and it did happen earlier. You were just lucky not to update until it got sorted out.

@predmijat Yeah, that's the way it has always worked for me as long as I've been using the zfs packages from demizer over the past year. It wouldn't update the linux kernel as long as the zfs packages were out-of-date. Maybe something changed in 0.6.5.8_4.8.12_2-1 ?

Why is this happening each couple of updates? Can it be set up so that it always requires a specific version? Is there a situation where you wouldn't want that?

This morning when I did a system upgrade, linux upgraded to linux-4.8.12-3-x86_64 but the zfs packages stayed at version 0.6.5.8_4.8.12_2-1. When mkinitcpio ran, it failed: ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default' -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img ==> Starting build: 4.8.12-3-ARCH -> Running build hook: [base] -> Running build hook: [udev] -> Running build hook: [resume] -> Running build hook: [autodetect] -> Running build hook: [modconf] -> Running build hook: [block] -> Running build hook: [keyboard] -> 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' -> Running build hook: [filesystems] -> Running build hook: [fsck] ==> Generating module dependencies ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img ==> WARNING: errors were encountered during the build. The image may not be complete. Just a warning to others. This could render systems unbootable. I downgraded to linux-4.8.12-2 and everything seems fine, but it seems that something is not right in the package dependencies.

Point release versions of the kernel are bug/security fixes. No new features are added. I modified his packages to use the extramodules-* folder like the nvidia package and have been using zfs compiled all the way back at 4.8.4. Working great on 4.8.12 right now. I sent him these modifications. Hopefully he implements for 4.9. vermagic: 4.8.4-1-ARCH

Broken for linux 4.8.8-2... Please also add the pkgrel so linux=4.8.8-2 instead of linux=4.8.8 . Thanks

For anyone stuck with a system-wide upgrade, here's the trick. Add these lines to /etc/pacman.conf: IgnorePkg=linux IgnorePkg=linux-headers IgnorePkg=spl-linux IgnorePkg=spl-utils-linux IgnorePkg=zfs-linux IgnorePkg=zfs-utils-linux Both kernel and ZFS-related updates will be ignored, the rest should upgrade just fine. When the new packages are available, just comment these lines. It works for me more than fine. @demizer, thank you for your packages!

@demizer Please keep up the good work. Release only when you have concluded it is "safe enough". @danlamanna, @ahyadude The NVidia driver is not comparable to a filesystem. I don't mind fiddling around to get a graphic interface. It has no bearing on the rest of the system/network. A corrupt filesystem on the other hand is pure agony. It takes much longer to determine the date and time the corruption occurred and to restore the correct backups. And during this time none of the clients can login.

+1 for pinning this to a kernel minor version (similar to nvidia) rather than a specific release.