Summary: | sys-kernel/gentoo-kernel-bin-6.6.57 unable to load zfs module from sys-fs/zfs-kmod-2.2.5 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Fredrik Eriksson <gentoo> |
Component: | Current packages | Assignee: | Distribution Kernel Project <dist-kernel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gentoo, ionen, julien, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Fredrik Eriksson
2024-10-24 17:07:33 UTC
Hm. Do you have pahole installed? (In reply to Sam James from comment #1) > Hm. Do you have pahole installed? Yes, it seems I have dev-util/pahole-1.27-r1 installed. Not anything I'm familiar with, but looks like a dependency for zfs-kmod. I was thinking of the changes we made in e.g. commit f3bb6bb643e02c3957e2f99cfefa1e2d3fd3c4cc Author: Sam James <sam@gentoo.org> Date: Thu Sep 5 12:50:50 2024 +0100 sys-kernel/gentoo-kernel-bin: BDEPEND on dev-util/pahole Without this, if CONFIG_DEBUG_INFO_BTF_MODULES is enabled, as it is by default since 49e0de80b0d0b9bd5767d438dae773194d838525, while g-k-bin will seem to install fine, it's installed incorrectly. It also leads to external modules later not being loadable with relocation errors from unhandled BTF: ``` [ 1648.352993] module: x86/modules: Invalid relocation target, existing value is nonzero for type 1, loc 00000000bc2721ed, val ffffffffc11e7850 ``` Thanks-to: Ionen Wolkens <ionen@gentoo.org> Reported-by: Sebastian Engel <sighunter@gmx.de> Signed-off-by: Sam James <sam@gentoo.org> but if it's installed, then it doesn't make sense to be hitting that same problem (it only happened if it *wasn't* installed, as BTF couldn't be processed). Off the top of my head, the only thing I can possibly think of is pahole not being installed on a system where you built a zfs-kmod binpkg or something, but I don't see how that's doable with a fresh binpkg or anything built against a new just-built kernel anyway because of the eclass dependencies. Well, it *is* on a package builder VM and it does auto-update, so it wouldn't be entirely unlikely that something happened in the wrong order leading to this situation. But during the troubleshooting I disabled binary packages (they were on the unavailable zfs filesystem anyway). Just to be safe I rebuilt the packages again in this order: 1. pahole 2. zfs-kmod 3. gentoo-kernel-bin 4. zfs-kmod No luck after 2 or 3, but after rebuilding zfs-kmod the second time the module loaded successfully! So my best guess is that pahole was needed when gentoo-kernel-bin was originally upgraded but wasn't pulled in until afterwards for some reason? Some additional info: I'm using this VM to build binpkgs for a few profiles. The packages are build periodically in chroots in the VM. The packages are stored locally and when the nightly auto update for the VM runs it will install binpkg from the local storage if the packages has already been built. I hadn't bothered to exclude binary ebuilds (such as gentoo-kernel-bin) from building binpkg, so when the VM was upgraded it most likely used a binpkg built from within one of the chroots. Since the quoted commit sets pahole as a BDEPEND to gentoo-kernel-bin I guess this is likely to be related. For now I will exclude both gentoo-kernel-bin and zfs-kmod from building and using binpkg. (In reply to Fredrik Eriksson from comment #5) > So my best guess is that pahole was needed when gentoo-kernel-bin was > originally upgraded but wasn't pulled in until afterwards for some reason? I'd like to say that this shouldn't happen because it BDEPEND on pahole.. but only 6.11.4 and 6.11.5 has it in BDEPEND (6.6.57 does not). So.. that's likely what happened. Hi, Just to confirm this issue, unrelated to zfs, I need out-of-tree kernel modules for my laptop webcam that I rebuild every kernel upgrade and upgrading to 6.6.57 lead to all modules being built successfully but all refusing to load with the error Exec format error. After installing pahole and re-emerging gentoo-kernel-bin and @module-rebuild, everything works fine again. So yeah, pahole presence seems required to build any module on this version while it wasn't previously. Thanks. I'll be fixing the dep shortly. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=389519b911cb85e7138045bb202c5109a1d532a8 commit 389519b911cb85e7138045bb202c5109a1d532a8 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-10-25 21:24:14 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-10-25 21:24:14 +0000 sys-kernel/gentoo-kernel-bin: add pahole BDEPEND Same as we did in f3bb6bb643e02c3957e2f99cfefa1e2d3fd3c4cc but we missed this for 6.6.x when we made the change to default to debug there too recently. Closes: https://bugs.gentoo.org/942087 Signed-off-by: Sam James <sam@gentoo.org> ...oo-kernel-bin-6.6.57.ebuild => gentoo-kernel-bin-6.6.57-r1.ebuild} | 3 ++- ...oo-kernel-bin-6.6.58.ebuild => gentoo-kernel-bin-6.6.58-r1.ebuild} | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) |