[workaround] zfs-2.2.5 incompatible with kmod-33

cryptearth · 2024-08-17 09:09:39

// the issue is the update of kmod from 32 to 33 - workaround: don't update kmod

So over on archzfs github repo there's a depmod issue on the final packaging - it affects both the current standard kernel as well as the lts kernel.
As the actual build itself completes but only the packaging fails I doubt it's any issue with zfs, archzfs or the kernel push 6.10.5 but rather some change in some part of the toolchain that got push along with 6.10.5.
The issue is specific to the depmod stage which somehow slips in an extra "/usr":

DEPMOD  /build/zfs-linux/pkg/zfs-linux/usr/lib/modules/6.10.5-arch1-1
depmod: ERROR: could not open directory /build/zfs-linux/pkg/zfs-linux/usr/usr/lib/modules/6.10.5-arch1-1: No such file or directory

DEPMOD  /build/zfs-linux-lts/pkg/zfs-linux-lts/usr/lib/modules/6.6.46-1-lts
depmod: ERROR: could not open directory /build/zfs-linux-lts/pkg/zfs-linux-lts/usr/usr/lib/modules/6.6.46-1-lts: No such file or directory

Up until 14/08/24 building 2.2.5 for 6.10.4 worked smoothly and I'm currently running it right now.
Unfortunate I don't have any other kernel module to build "on food" to test if this is some upstream issue (which I guess as it also affects LTS - so if this issue would be anyhow related to 6.10.5 the LTS would still work - if it's zfs specific can only be tested by some other out-of-tree kernel module).

Last edited by cryptearth (2024-08-18 10:44:19)

gromit · 2024-08-17 09:11:59

It seems like somehow the build path from the chroot ends up in the finished executable hmm

cryptearth · 2024-08-17 22:21:19

//update: with a VM set to 14.08.24 it works fine again - so some update at either 15.08.24 or 16.08.24 along with the release of 6.10.5 is the cause here

So I spun up a VM and tried makepkg the regular way instead of in clean-chroot-manager - the issue persists even there.
When I modify the PKGBUILD from

INSTALL_MOD_PATH=${pkgdir}/usr

to

INSTALL_MOD_PATH=${pkgdir}

the error changes to

DEPMOD  /build/zfs-linux/pkg/zfs-linux/lib/modules/6.10.5-arch1-1
depmod: ERROR: could not open directory /build/zfs-linux/pkg/zfs-linux/usr/lib/modules/6.10.5-arch1-1: No such file or directory

So - from this: There's still an additional "/usr" slipping in.
I also tried to modify the ./configure and removed every "/usr" - but that didn't change anything.
I'll try to setup a VM from the archive in a state before 15th but still with kernel 6.10.5 - if that works than there sure is some change in some toolchain causing that somehow - this could give at least a lead.

Last edited by cryptearth (2024-08-17 23:11:34)

seth · 2024-08-17 23:27:58

Why would the packaging run depmod? That's relevant on the target system (on installation)
(The answer is likely that the zfs provided make script invokes that)

Have you tried/considered the dkms package?

loqs · 2024-08-17 23:40:33

https://gitlab.archlinux.org/archlinux/ … 6933f5b99d ?

cryptearth · 2024-08-17 23:42:44

that's the PKGBUILD from archzfs

# Maintainer: Jan Houben <jan@nexttrex.de>
# Contributor: Jesus Alvarez <jeezusjr at gmail dot com>
#
# This PKGBUILD was generated by the archzfs build scripts located at
#
# http://github.com/archzfs/archzfs
#
# ! WARNING !
#
# The archzfs packages are kernel modules, so these PKGBUILDS will only work with the kernel package they target. In this
# case, the archzfs-linux packages will only work with the default linux package! To have a single PKGBUILD target many
# kernels would make for a cluttered PKGBUILD!
#
# If you have a custom kernel, you will need to change things in the PKGBUILDS. If you would like to have AUR or archzfs repo
# packages for your favorite kernel package built using the archzfs build tools, submit a request in the Issue tracker on the
# archzfs github page.
#
pkgbase="zfs-linux"
pkgname=("zfs-linux" "zfs-linux-headers")
_zfsver="2.2.5"
_kernelver="6.10.5.arch1-1"
_kernelver_full="6.10.5.arch1-1"
_extramodules="${_kernelver_full/.arch/-arch}"

pkgver="${_zfsver}_$(echo ${_kernelver} | sed s/-/./g)"
pkgrel=1
makedepends=("linux-headers=${_kernelver}")
arch=("x86_64")
url="https://openzfs.org/"
source=("https://github.com/openzfs/zfs/releases/download/zfs-${_zfsver}/zfs-${_zfsver}.tar.gz")
sha256sums=("2388cf6f29cd75e87d6d05e4858a09d419c4f883a658d51ef57796121cd08897")
license=("CDDL")
depends=("kmod" "zfs-utils=${_zfsver}" "linux=${_kernelver}")

build() {
    cd "${srcdir}/zfs-${_zfsver}"
    ./autogen.sh
    ./configure --prefix=/usr --sysconfdir=/etc --sbindir=/usr/bin --libdir=/usr/lib \
                --datadir=/usr/share --includedir=/usr/include --with-udevdir=/usr/lib/udev \
                --libexecdir=/usr/lib --with-config=kernel \
                --with-linux=/usr/lib/modules/${_extramodules}/build \
                --with-linux-obj=/usr/lib/modules/${_extramodules}/build
    make
}

package_zfs-linux() {
    pkgdesc="Kernel modules for the Zettabyte File System."
    install=zfs.install
    provides=("zfs" "spl")
    groups=("archzfs-linux")
    conflicts=("zfs-dkms" "zfs-dkms-git" "zfs-dkms-rc" "spl-dkms" "spl-dkms-git" 'zfs-linux-git' 'zfs-linux-rc' 'spl-linux')
    replaces=("spl-linux")
    cd "${srcdir}/zfs-${_zfsver}"
    make DESTDIR="${pkgdir}" INSTALL_MOD_PATH=${pkgdir}/usr INSTALL_MOD_STRIP=1 install
    # Remove src dir
    rm -r "${pkgdir}"/usr/src
}

package_zfs-linux-headers() {
    pkgdesc="Kernel headers for the Zettabyte File System."
    provides=("zfs-headers" "spl-headers")
    conflicts=("zfs-headers" "zfs-dkms" "zfs-dkms-git" "zfs-dkms-rc" "spl-dkms" "spl-dkms-git" "spl-headers")
    cd "${srcdir}/zfs-${_zfsver}"
    make DESTDIR="${pkgdir}" install
    rm -r "${pkgdir}/lib"
    # Remove reference to ${srcdir}
    sed -i "s+${srcdir}++" ${pkgdir}/usr/src/zfs-*/${_extramodules}/Module.symvers
}

all that archzfs does is to wrap the makepkg in a clean-chroot environment - but I can also run makepkg without ccm
as for now it still works with repo set to archive from 15.08.24
when set to 16.08.24 the only 3 packages the system wants to update are fakeroot, gnutls and kmod - and I can rule out gnutls (not related) and fakeroot (aleady tried a build with an older version) - so likely only the update from kmod-32-1 to kmod-33-1 is what's left for testing
why makepkg calls depmod - I don't know - I'm not so deep into kernel module development - but as it's not caused by zfs nor archzfs but a simple regular makepkg with the given PKGBUILD points to either the makefile - which is almost 1MB in size and WAY to complicated for me to analyze - or something within the regular packaging of any makepkg but cause by it being a kernel module?

as for DKMS: tried it - causes issues - was able to fix them by using kernel version specific packages - doing the build myself than rely on the repo is the maintainer was/is on vacation and the buildbot somehow died again

///

loqs wrote:

https://gitlab.archlinux.org/archlinux/ … 6933f5b99d ?

looks like it - question: how to change the PKGBUILD to workaround/fix this?

Last edited by cryptearth (2024-08-17 23:56:03)

loqs · 2024-08-18 00:19:42

As seth observed the depmod called is not needed; is is covered by a libalpm hook provided by the kmod package. So symlink depmod to true and have that symlinks location be first in $PATH so the calls do nothing but report success.

diff --git a/PKGBUILD b/PKGBUILD
index 0a2cf04..c484573 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -17,9 +17,9 @@
 #
 pkgbase="zfs-linux"
 pkgname=("zfs-linux" "zfs-linux-headers")
-_zfsver="2.2.4"
-_kernelver="6.9.7.arch1-1"
-_kernelver_full="6.9.7.arch1-1"
+_zfsver="2.2.5"
+_kernelver="6.10.5.arch1-1"
+_kernelver_full="6.10.5.arch1-1"
 _extramodules="${_kernelver_full/.arch/-arch}"
 
 pkgver="${_zfsver}_$(echo ${_kernelver} | sed s/-/./g)"
@@ -28,11 +28,13 @@ makedepends=("linux-headers=${_kernelver}")
 arch=("x86_64")
 url="https://openzfs.org/"
 source=("https://github.com/openzfs/zfs/releases/download/zfs-${_zfsver}/zfs-${_zfsver}.tar.gz")
-sha256sums=("9790905f7683d41759418e1ef3432828c31116654ff040e91356ff1c21c31ec0")
+sha256sums=('2388cf6f29cd75e87d6d05e4858a09d419c4f883a658d51ef57796121cd08897')
 license=("CDDL")
 depends=("kmod" "zfs-utils=${_zfsver}" "linux=${_kernelver}")
 
 build() {
+    ln -s /usr/bin/true depmod
+    PATH="$PWD:$PATH"
     cd "${srcdir}/zfs-${_zfsver}"
     ./autogen.sh
     ./configure --prefix=/usr --sysconfdir=/etc --sbindir=/usr/bin --libdir=/usr/lib \

Last edited by loqs (2024-08-18 00:20:06)

cryptearth · 2024-08-18 00:58:17

As archzfs executes the build in a clean-chroot-manager environment the depmod symlink doesn't transfer into it - also it doesn't matter what kmod is on the host as the ccm environment pulls in the most recent from the mirrors.
So, I'm not sure if can be fixed just by modifying the PKGBUILD of archzfs but likely something that has to be fixed upstream zfs so the Makefile works.
Why depmod is even called - can't tell - wasn't able to find a call in the Makefile or in any of archzfs scripts - and as it also happens when not using the archzfs script to call makepkg in ccm but on the host itself hints to it's something that happens inside makepkg - makes this issue arch specific.

loqs · 2024-08-18 02:20:10

Do my changes allow the package to build for you? If so does the produced package install and function correctly? Simpler way to disable depmod as used in the linux PKGBUILD adapted as `make modules_install` is called from module/Makefile:

    sed -ri 's|(KERNELRELEASE=@LINUX_VERSION@)|\1 DEPMOD=/doesnt/exist|' module/Makefile.in

seth · 2024-08-18 07:35:48

As archzfs executes the build in a clean-chroot-manager environment the depmod symlink doesn't transfer into it

loqs' suggestion manipulates symlink and path in the build context.

Why depmod is even called - can't tell

If #7 and #9 don't work out, wrap the make install calls in "set -x" and "set +x", nb. that this will most likely generate a humongous output, but in there you'll find the way to depmod.

cryptearth · 2024-08-18 10:43:15

Again: I am NOT the maintainer of https://github.com/archzfs/archzfs nor do I know anything about how packaging on arch (or any distro as deb or rpm) work nor why the build thinks depmod is required - all I can tell is this: With kmod-32-1 I can build the pkg by manual run makepkg - updating to kmod-33-1 causes the additional "/usr" mentioned in the OP.
It also doesn't matter if or how I manipulate the PKGBUILD or the Makefile - it does NOT work with kmod-33-1 AT ALL. Why? For as far as I was able to figure out because kmod itself adds the additional "/usr" no matter what's given as input path.
If I change the pkgbuild as in #3 it results in the files end up in the wrong place - so depmod fails anyway.
Again: Neither do I know why or where depmod is called nor was I able to stop it by the suggested change to the build file. Also the error is transparent no matter if I use the archzfs script which runs all the stuff inside a clean-chroot environment or just call makepkg without CCM. I also don't know if this is arch specific as I don't really understand the change to kmod - or why it happens now in august although the linked PR is from "half a year ago" (gitlab doesn't show a date).
In the end I now was able to build the package this way:
1) setup a VM with repo set to 15/08/24 which installs 6.10.4 and kmod-32
2) manual install 6.10.5
3) clone the repo and let it fail - as either the clean-chroot environment is unable to pull in 6.10.4 or if I change the repo to 16/08/24 it pulls in kmod-33 along 6.10.5
4) build the package "by hand" by nor using the archzfs build script but regular makepkg which uses kmod-32 of the OS but with 6.10.5 which results in a clean successfull build which then I can install on my main system along with 6.10.5 and now that without issues

again: I don't know IF or HOW it might be possible to fix this arch-specific issue within the archzfs project or if this somehow has to be patched upstream by https://github.com/openzfs/zfs or what the hell is going on - I don't understand the change of kmod and I don't care
"yea, use LTS" is NOT an option as this still uses kmod-33 which is the root cause of that issue here - aside from that: as I use my system mostly for gaming and not everything is backported I would miss out on a few updates of the amdgpu driver which in fact does impact performance noticeable

also: as I don't know any other out-of-tree module from the top of my head aside from the nvidia proprietary drivers I can't test if the kmod change affects any other packages - as for some reason whatever I pull in for nvidia does not call depmod
unformately ZFS upstream only supports DEB and RPM packaging - hence achrzfs exists in the first place
one of the major downsides - and this somewhat reminds me to was it curl or wget? - even the archwiki only links to this project - I wasn't able to find any information how to build the zfs-utils and zfs-linux packages "from scratch" by just using the zfs upstream repo - hence "build it yourself" is a bit of "yea, if you teach me how?" chicken-egg problem

I am just a USER of zfs - not a DEV! all I can do is to report what's going wrong and try to investigate by somewhat "bisect" the workflow - by which i figured it was the simultaneous release of both 6.10.5 and kmod-33 which is the issue here
it's up to devs and maintainers to take this and hopefully figure out a fix - until then it seems I have to keep using my method with kmod-32 to build the packages until that starts to break by some change upstream again

Bronek · 2024-08-18 12:42:07

Hi guys; I am also affected. Probably any external linux module that happens to invoke depmod on Arch is, it's just that openzfs recently released version 2.2.5 and people are trying to build it with archzfs.

Anyway, I might have slightly more experience than @cryptearth but unfortunately my expertise is not in building Arch packages, even though I've been building my own versions of kernel and several other packages for almost 10 past years. I hope to be able to either fix this problem in the archzfs itself, or help to test a fix elsewhere if that's needed.

First question - since regular makepkg of linux package produces the output like below

  ZSTD    /build/linux/pkg/linux/usr/lib/modules/6.9.12-1/kernel/net/qrtr/qrtr-mhi.ko.zst                                                                            
  DEPMOD  /build/linux/pkg/linux/usr/lib/modules/6.9.12-1                                                                                                            
Warning: 'make modules_install' requires /doesnt/exist. Please install it.                                                                                           
This is probably in the kmod package.                                             
==> Tidying install...                                                            
  -> Removing libtool files...

... I want to make sure that the warning is expected and nothing needs to be done about it. I believe it comes from this https://github.com/archlinux/svntogit-p … 0a91c115f1 , so it's by design.

Second, assuming the above is correct, I have done what #9 suggested (thanks @loqs !) so my archzfs has this local change

diff --git a/src/zfs/PKGBUILD.sh b/src/zfs/PKGBUILD.sh
index 0644023..70389b5 100755
--- a/src/zfs/PKGBUILD.sh
+++ b/src/zfs/PKGBUILD.sh
@@ -21,6 +21,11 @@ sha256sums=("${zfs_src_hash}")
 license=("CDDL")
 depends=("kmod" "${zfs_utils_pkgname}" ${linux_depends})
 
+prepare() {
+    cd "${zfs_workdir}"
+    sed -ri 's|(KERNELRELEASE=@LINUX_VERSION@)|\1 DEPMOD=/doesnt/exist|' module/Makefile.in
+}
+
 build() {
     cd "${zfs_workdir}"

... which seems to have fixed the problem, since now the archzfs build output looks like this (excerpt from the part which used to report an error)

make -C /usr/lib/modules/6.6.46-1-lts/build M="$PWD" modules_install \                                                                                               
        INSTALL_MOD_PATH=/build/zfs-linux-lts/pkg/zfs-linux-lts-headers \                                                                                            
        INSTALL_MOD_DIR=extra \                                                                                                                                      
        KERNELRELEASE=6.6.46-1-lts DEPMOD=/doesnt/exist                                                                                                              
make[2]: Entering directory '/usr/lib/modules/6.6.46-1-lts/build'                                                                                                    
  INSTALL /build/zfs-linux-lts/pkg/zfs-linux-lts-headers/lib/modules/6.6.46-1-lts/extra/spl.ko                                                                       
  INSTALL /build/zfs-linux-lts/pkg/zfs-linux-lts-headers/lib/modules/6.6.46-1-lts/extra/zfs.ko                                                                       
  SIGN    /build/zfs-linux-lts/pkg/zfs-linux-lts-headers/lib/modules/6.6.46-1-lts/extra/spl.ko                                                                       
  SIGN    /build/zfs-linux-lts/pkg/zfs-linux-lts-headers/lib/modules/6.6.46-1-lts/extra/zfs.ko                                                                       
At main.c:167:                                                                                                                                                       
- SSL error:FFFFFFFF80000002:system library::No such file or directory: crypto/bio/bss_file.c:67                                                                     
- SSL error:10000080:BIO routines::no such file: crypto/bio/bss_file.c:75                                                                                            
sign-file: ./certs/signing_key.pem                                                
At main.c:167:                                                                                                                                                       
- SSL error:FFFFFFFF80000002:system library::No such file or directory: crypto/bio/bss_file.c:67
- SSL error:10000080:BIO routines::no such file: crypto/bio/bss_file.c:75
sign-file: ./certs/signing_key.pem                                                
  ZSTD    /build/zfs-linux-lts/pkg/zfs-linux-lts-headers/lib/modules/6.6.46-1-lts/extra/spl.ko.zst
  ZSTD    /build/zfs-linux-lts/pkg/zfs-linux-lts-headers/lib/modules/6.6.46-1-lts/extra/zfs.ko.zst
  DEPMOD  /build/zfs-linux-lts/pkg/zfs-linux-lts-headers/lib/modules/6.6.46-1-lts
Warning: 'make modules_install' requires /doesnt/exist. Please install it.
This is probably in the kmod package.
make[2]: Leaving directory '/usr/lib/modules/6.6.46-1-lts/build'

I guess I do not need to worry about missing sign-file: ./certs/signing_key.pem

Thanks for your help !

WorMzy · 2024-08-18 13:01:41

Mod note: Moving to AUR Issues.

0strodamus · 2024-08-21 04:24:40

loqs wrote:

https://gitlab.archlinux.org/archlinux/ … 6933f5b99d ?

This commit was causing the issue for me during the package array of a custom kernel. The error I was getting was:

depmod: ERROR: could not open directory /<snipped>/linux-ccs-5.10.224-1/pkg/linux-ccs/usr/usr/lib/modules/99.98.5.10.224-1-ccs: No such file or directory

The path should be the following without the "99.98.":

/<snipped>/linux-ccs-5.10.224-1/pkg/linux-ccs/usr/usr/lib/modules/5.10.224-1-ccs

I compiled kmod-33 locally without commit https://gitlab.archlinux.org/archlinux/ … 6933f5b99d and was able to successfully complete the kernel build. kmod-32 also runs depmod without any issue here.

loqs · 2024-08-21 15:48:32

@0strodamus what if you adjusted the PKGBUILD so it does not run depmod as in the linux PKGBUILD?

severach · 2024-08-21 17:35:14

The faulty DEPMOD is in upper case so is generated by the kernel module build, not zfs Makefile or PKGBUILD.

Adding V=1 to src/zfs/module/Makefile let me find the mystery "99.98." in /usr/lib/modules/6.1.106-1-lts61/build/scripts/depmod.sh. Present in all these versions:

4.19.320-1-lts419/build/scripts/depmod.sh
5.10.224-1-lts510/build/scripts/depmod.sh
5.15.165-1-lts515/build/scripts/depmod.sh
5.4.282-1-lts54/build/scripts/depmod.sh  
6.1.106-1-lts61/build/scripts/depmod.sh

Not present in 6.6 or 6.10. These versions have removed all the depmod_hack_needed code.

Adding set -x to depmod.sh lets me see the commands. Setting depmod_hack_needed=false gets rid of the unwanted string which reveals a new problem. zfs installs to $DESTDIR/lib then depmod runs in $DESTDIR/usr/lib

  DEPMOD  /tmp/makepkg-chris/zfs-linux-git/src/inst/lib/modules/6.1.106-1-lts61
+ test 2 -ne 2
+ DEPMOD=depmod
+ KERNELRELEASE=6.1.106-1-lts61
+ test -r System.map
+ PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/sbin
++ command -v depmod
+ '[' -z /usr/bin/depmod ']'
+ depmod_hack_needed=false
++ mktemp -d /tmp/depmod.XXXXXX
+ tmp_dir=/tmp/depmod.L4gsUo
+ mkdir -p /tmp/depmod.L4gsUo/lib/modules/6.1.106-1-lts61
+ depmod -b /tmp/depmod.L4gsUo 6.1.106-1-lts61
+ rm -rf /tmp/depmod.L4gsUo
+ false
+ set -- -ae -F System.map
+ test -n /tmp/makepkg-chris/zfs-linux-git/src/inst
+ set -- -ae -F System.map -b /tmp/makepkg-chris/zfs-linux-git/src/inst
+ depmod -ae -F System.map -b /tmp/makepkg-chris/zfs-linux-git/src/inst 6.1.106-1-lts61
depmod: ERROR: could not open directory /tmp/makepkg-chris/zfs-linux-git/src/inst/usr/lib/modules/6.1.106-1-lts61: No such file or directory
depmod: FATAL: could not search modules: No such file or directory
+ ret=1
+ false
+ exit 1
make[2]: *** [Makefile:1937: modules_install] Error 1

Makefile are inconsistent whether they generate the doubled /usr/usr and right now I'm not getting them.

loqs · 2024-08-21 18:02:02

@severach what is your use case for running depmod at build time?

severach · 2024-08-21 18:24:12

The PKGBUILD isn't running depmod. It's run automatically by the kernel module build. As seen in your link, Linux 6.6 and 6.10 "# Suppress depmod" by setting the bogus DEPMOD.

The zfs module Makefile does run depmod, but only after the kernel module build has already crashed. If it's not needed once, don't know why it's needed again.

loqs · 2024-08-21 18:39:21

From https://github.com/openzfs/zfs/blob/mas … akefile.in

modules_install-Linux: modules_uninstall-Linux-legacy
	@# Install the kernel modules
	$(MAKE) -C @LINUX_OBJ@ M="$$PWD" modules_install \
		INSTALL_MOD_PATH=$(INSTALL_MOD_PATH) \
		INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) \
		KERNELRELEASE=@LINUX_VERSION@

That call to make modules_install calls `depmod` but does not support passing through `DEPMOD=/doesnt/exist modules_install`. `make modules_install-Linux` could be replaced by `make modules-Linux` and copying the modules to `"${pkgdir}/usr/lib/modules/${_kernver}/extramodules"` there are also my other previous solutions.
Edit:
https://gitlab.archlinux.org/archlinux/ … -/issues/3

Last edited by loqs (2024-08-21 18:49:06)

severach · 2024-08-21 21:07:13

Don't worry about it for the kernels. Linux 6.1 and 5.15 build fine with the bogus DEPMOD. I added it to 5.4 and it builds. I'll add it to the lower kernels and patch away the depmod_hack_needed code to get rid of 99.98 errors.

The problem is all the other kernel packages. I was able to fix the zfs build with this patch in /usr/lib/modules/*/build/Makefile.

diff -pNaru5 6.1.106-1-lts61.old/build/Makefile 6.1.106-1-lts61/build/Makefile
--- 6.1.106-1-lts61.old/build/Makefile  2024-08-21 16:03:32.767969260 -0400
+++ 6.1.106-1-lts61/build/Makefile  2024-08-21 16:04:11.138329241 -0400
@@ -1159,11 +1159,11 @@ export INSTALL_DTBS_PATH ?= $(INSTALL_PA
 # INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
 # relocations required by build roots.  This is not defined in the
 # makefile but the argument can be passed to make if needed.
 #

-MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
+MODLIB = $(INSTALL_MOD_PATH)/usr/lib/modules/$(KERNELRELEASE)
 export MODLIB

 PHONY += prepare0

 export extmod_prefix = $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/)

This isn't zfs's fault. Are we ready to mass patch that across all kernels? That will make a compatibility divide so something better than that would be needed. Maybe find more ways to defeat DEPMOD?

KMODDIR := $(INSTALL_MOD_PATH)/lib/modules/6.1.106-1-lts61
modules_install-Linux: modules_uninstall-Linux-legacy
  @# Install the kernel modules
  $(MAKE) -C /usr/lib/modules/6.1.106-1-lts61/build M="$$PWD" modules_install \
    INSTALL_MOD_PATH=$(INSTALL_MOD_PATH) \
    INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) \
    KERNELRELEASE=6.1.106-1-lts61 DEPMOD=/bogus

This built zfs fine for me in 6.1 and 6.6.

6.1 and 6.6 depmod.sh detect DEPMOD differently.

DEPMOD=$1 # 6.1 command line option from a make variable
: ${DEPMOD:=depmod} # 6.6 and 6.10 from an env variable

KMODDIR := $(INSTALL_MOD_PATH)/lib/modules/6.6.46-1-lts
modules_install-Linux: modules_uninstall-Linux-legacy
  @# Install the kernel modules
  DEPMOD=/bogus $(MAKE) -C /usr/lib/modules/6.6.46-1-lts/build M="$$PWD" modules_install \
    INSTALL_MOD_PATH=$(INSTALL_MOD_PATH) \
    INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) \
    KERNELRELEASE=6.6.46-1-lts
  @# Remove extraneous build products when packaging

This built in 6.6 but not 6.1.

Does that really solve the problem? Why does Linus and crew want to run DEPMOD?

As you asked, what is the use case for running DEPMOD? Would it be better to permanently patch it out of build/Makefile so we don't need to patch hundreds of kernel packages?

Edit: maybe running DEPMOD is a bug. It should be done with "make install" but not with "make install DESTDIR=...". It's worked so well that noone noticed that we shouldn't be running DEPMOD when packaging.

Last edited by severach (2024-08-21 21:20:06)

loqs · 2024-08-21 21:46:41

This does look like unintended breakage that none of the maintainers noticed as nothing in the official repositories triggered the issue.

From my perspective as /usr/share/libalpm/hooks/60-depmod.hook will trigger depmod to be executed when a kernel module is installed/upgraded/removed there is no need to run depmod at build time.

0strodamus · 2024-08-22 01:03:13

loqs wrote:

@0strodamus what if you adjusted the PKGBUILD so it does not run depmod as in the linux PKGBUILD?

Yes, that worked. Thanks for the tip!

severach · 2024-08-22 01:30:38

export DEPMOD=/doesnt/exist in /etc/makepkg.conf works for newer kernels, and older kernels after I patch them.

This patch may be the complete solution.

diff -pNaru5 6.1.106-1-lts61.old/build/Makefile 6.1.106-1-lts61/build/Makefile
--- 6.1.106-1-lts61.old/build/Makefile  2024-08-19 11:34:34.000000000 -0400
+++ 6.1.106-1-lts61/build/Makefile  2024-08-21 20:53:05.445616163 -0400
@@ -1933,12 +1933,14 @@ quiet_cmd_depmod = DEPMOD  $(MODLIB)
                    $(KERNELRELEASE)

 modules_install:
  $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
 ifndef modules_sign_only
+ifeq ($(INSTALL_MOD_PATH),/)
  $(call cmd,depmod)
 endif
+endif

 else # CONFIG_MODULES

 # Modules not configured
 # ---------------------------------------------------------------------------

That will leave all the different scripts and their with or without /usr hacks all unfixed.

0strodamus · 2024-08-22 01:51:44

severach wrote:

Adding V=1 to src/zfs/module/Makefile let me find the mystery "99.98."

Thanks for shedding some light for me on where the 99.98. was coming from and also for maintaining the LTS packages in the AUR!

severach · 2024-08-22 21:07:47

4.19, 5.10, and 6.1 are all updated. I'd update 5.4 but it hasn't worked for weeks on Arch or Manjaro. The final depmod patch is better than the one above. DEPMOD=/doesnt/exist can be removed. It shows a real message, not some pithy error "Warning: 'make modules_install' requires $DEPMOD. Please install it."

Arch Linux

#1 2024-08-17 09:09:39

[workaround] zfs-2.2.5 incompatible with kmod-33

#2 2024-08-17 09:11:59

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#3 2024-08-17 22:21:19

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#4 2024-08-17 23:27:58

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#5 2024-08-17 23:40:33

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#6 2024-08-17 23:42:44

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#7 2024-08-18 00:19:42

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#8 2024-08-18 00:58:17

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#9 2024-08-18 02:20:10

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#10 2024-08-18 07:35:48

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#11 2024-08-18 10:43:15

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#12 2024-08-18 12:42:07

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#13 2024-08-18 13:01:41

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#14 2024-08-21 04:24:40

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#15 2024-08-21 15:48:32

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#16 2024-08-21 17:35:14

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#17 2024-08-21 18:02:02

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#18 2024-08-21 18:24:12

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#19 2024-08-21 18:39:21

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#20 2024-08-21 21:07:13

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#21 2024-08-21 21:46:41

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#22 2024-08-22 01:03:13

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#23 2024-08-22 01:30:38

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#24 2024-08-22 01:51:44

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

#25 2024-08-22 21:07:47

Re: [workaround] zfs-2.2.5 incompatible with kmod-33

Board footer