Description of problem: I installed xtables-addons on epel10 system and I don't have xt_geoip module available, like happens in epel9. Raised ticket to rpmfusion, we get that akmods has omitted .x86_64_v2 Additional info: https://bugzilla.rpmfusion.org/show_bug.cgi?id=7315
Do you have any means to detect that we are in x86_64_v2 ? Is "uname -r" ending with x86_64_v2 the only and good way forward ? Can you output uname -m and uname -r ?
also can you test with: bash -x akmodsbuild --target x86_64_v2 /usr/src/akmods/xtables*.latest
BTW can you assign epel maintainer to you in https://src.fedoraproject.org/rpms/akmods page ? Thanks
(In reply to Nicolas Chauvet (kwizart) from comment #1) > Do you have any means to detect that we are in x86_64_v2 ? > Is "uname -r" ending with x86_64_v2 the only and good way forward ? > > > Can you output uname -m and uname -r ? uname -m: `x86_64` uname -a: `Linux test 6.12.0-55.30.1.el10_0.x86_64_v2 #1 SMP PREEMPT_DYNAMIC Tue Sep 9 12:35:34 UTC 2025 x86_64 GNU/Linux`
(In reply to Nicolas Chauvet (kwizart) from comment #2) > also can you test with: > > bash -x akmodsbuild --target x86_64_v2 /usr/src/akmods/xtables*.latest using this command, it works! I added stdout to a log file and I get: Rebuilding /usr/src/akmods/xtables-addons-kmod.latest for kernel(s) 6.12.0-55.30.1.el10_0.x86_64_v2: prep build install clean; Successfull; Saved kmod-xtables-addons-6.12.0-55.el10_0-3.28-2.el10.x86_64_v2.rpm in /var/cache/akmods/`
Hello, (In reply to Nicolas Chauvet (kwizart) from comment #1) > Do you have any means to detect that we are in x86_64_v2 ? Don't know if this below is accurate in this particular case, but maybe this command should help, if available in el10: /lib64/ld-linux-x86-64.so.2 --help Feel free to make any comment. Cordially, -- NVieville
> BTW can you assign epel maintainer to you in https://src.fedoraproject.org/rpms/akmods page ? Done > using this command, it works! Good, so it should be easy to fix I hope. > /lib64/ld-linux-x86-64.so.2 --help It is, but it will only approximate what is needed. One can run alma rebuild for x86_64_v2 while having a x86_64_v3 or v4 arch (make little sense, but it possible). Looking at "uname -r ending" (at least in almalinux case) is likely what will be needed to determine the appropriate option. @bitchecker Can you check the output of: - rpm -E %{_target_cpu} - /lib64/ld-linux-x86-64.so.2 --help - rpm --showrc # attached in a file in this ticket.
Created attachment 2106813 [details] rpm --showrc
(In reply to Nicolas Chauvet (kwizart) from comment #7) > @bitchecker > > Can you check the output of: > - rpm -E %{_target_cpu} x86_64 > - /lib64/ld-linux-x86-64.so.2 --help Usage: /lib64/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You have invoked 'ld.so', the program interpreter for dynamically-linked ELF programs. Usually, the program interpreter is invoked automatically when a dynamically-linked executable is started. You may invoke the program interpreter program directly from the command line to load and run an ELF executable file; this is like executing that file itself, but always uses the program interpreter you invoked, instead of the program interpreter specified in the executable file you run. Invoking the program interpreter directly provides access to additional diagnostics, and changing the dynamic linker behavior without setting environment variables (which would be inherited by subprocesses). --list list all dependencies and how they are resolved --verify verify that given object really is a dynamically linked object we can handle --inhibit-cache Do not use /etc/ld.so.cache --library-path PATH use given PATH instead of content of the environment variable LD_LIBRARY_PATH --glibc-hwcaps-prepend LIST search glibc-hwcaps subdirectories in LIST --glibc-hwcaps-mask LIST only search built-in subdirectories if in LIST --inhibit-rpath LIST ignore RUNPATH and RPATH information in object names in LIST --audit LIST use objects named in LIST as auditors --preload LIST preload objects named in LIST --argv0 STRING set argv[0] to STRING before running --list-tunables list all tunables with minimum and maximum values --list-diagnostics list diagnostics information --help display this help and exit --version output version information and exit This program interpreter self-identifies as: /lib64/ld-linux-x86-64.so.2 Shared library search path: (libraries located via /etc/ld.so.cache) /lib64 (system search path) /usr/lib64 (system search path) Subdirectories of glibc-hwcaps directories, in priority order: x86-64-v4 x86-64-v3 x86-64-v2 (supported, searched) > - rpm --showrc # attached in a file in this ticket. rpm.txt attachment :)
FEDORA-2025-37e985b13a (akmods-0.6.1-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2025-37e985b13a
FEDORA-2025-37e985b13a (akmods-0.6.1-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-b18a85b925 (akmods-0.6.1-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-b18a85b925
FEDORA-2025-d5be7c00c4 (akmods-0.6.1-2.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-d5be7c00c4
FEDORA-EPEL-2025-33ea68b80b (akmods-0.6.1-2.el10_2) has been submitted as an update to Fedora EPEL 10.2. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-33ea68b80b
FEDORA-EPEL-2025-b5c526537e (akmods-0.6.1-2.el10_0) has been submitted as an update to Fedora EPEL 10.0. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-b5c526537e
FEDORA-EPEL-2025-08996c0ee3 (akmods-0.6.1-2.el10_1) has been submitted as an update to Fedora EPEL 10.1. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-08996c0ee3
FEDORA-2025-d5be7c00c4 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-d5be7c00c4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-d5be7c00c4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-08996c0ee3 has been pushed to the Fedora EPEL 10.1 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-08996c0ee3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-33ea68b80b has been pushed to the Fedora EPEL 10.2 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-33ea68b80b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-b5c526537e has been pushed to the Fedora EPEL 10.0 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-b5c526537e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-b18a85b925 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-b18a85b925` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-b18a85b925 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Why this was CLOSED? I see only that packages are on Testing repos.
(In reply to bitchecker from comment #22) > Why this was CLOSED? > > I see only that packages are on Testing repos. This is the normal process with a candidate for fix. Please test and only re-open if it doesn't fix.
(was closed because already in stable for f44)
Please test with akmods-0.6.1 from epel-testing repository.
FEDORA-2025-d5be7c00c4 (akmods-0.6.1-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-b18a85b925 (akmods-0.6.1-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-33ea68b80b (akmods-0.6.1-2.el10_2) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-08996c0ee3 (akmods-0.6.1-2.el10_1) has been pushed to the Fedora EPEL 10.1 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-b5c526537e (akmods-0.6.1-2.el10_0) has been pushed to the Fedora EPEL 10.0 stable repository. If problem still persists, please make note of it in this bug report.
Hi, build logs for module build and install is completely the same after updates: 2025/10/01 09:19:28 akmods: Checking kmods exist for 6.12.0-55.34.1.el10_0.x86_64_v2 2025/10/01 09:19:28 akmods: Building and installing xtables-addons-kmod 2025/10/01 09:19:28 akmods: Building RPM using the command '/usr/sbin/akmodsbuild --kernels 6.12.0-55.34.1.el10_0.x86_64_v2 /usr/src/akmods/xtables-addons-kmod.latest' 2025/10/01 09:19:29 akmods: Building rpms failed; see /var/cache/akmods/xtables-addons/3.28-2-for-6.12.0-55.34.1.el10_0.x86_64_v2.failed.log for details 2025/10/01 09:19:29 akmods: Hint: Some kmods were ignored or failed to build or install. 2025/10/01 09:19:29 akmods: You can try to rebuild and install them by by calling 2025/10/01 09:19:29 akmods: '/usr/sbin/akmods --force' as root. 2025/10/01 09:19:52 akmods: Checking kmods exist for 6.12.0-55.34.1.el10_0.x86_64_v2 2025/10/01 09:19:52 akmods: Building and installing xtables-addons-kmod 2025/10/01 09:19:52 akmods: Building RPM using the command '/usr/sbin/akmodsbuild --kernels 6.12.0-55.34.1.el10_0.x86_64_v2 /usr/src/akmods/xtables-addons-kmod.latest' 2025/10/01 09:19:53 akmods: Building rpms failed; see /var/cache/akmods/xtables-addons/3.28-2-for-6.12.0-55.34.1.el10_0.x86_64_v2.failed.log for details 2025/10/01 09:19:53 akmods: Hint: Some kmods were ignored or failed to build or install. 2025/10/01 09:19:53 akmods: You can try to rebuild and install them by by calling 2025/10/01 09:19:53 akmods: '/usr/sbin/akmods --force' as root.
(In reply to bitchecker from comment #31) > 2025/10/01 09:19:53 akmods: Building rpms failed; see > /var/cache/akmods/xtables-addons/3.28-2-for-6.12.0-55.34.1.el10_0.x86_64_v2. > failed.log for details Where is the log?, attach it instead of pointless output which shows nothing useful.
Created attachment 2108227 [details] /var/cache/akmods/xtables-addons/3.28-2-for-6.12.0-55.34.1.el10_0.x86_64_v2.failed.log
Ok, the error is actually different (same issue), Can you report which kernel-devel(s) you have ? rpm -q kernel-devel for the lastest kernel, can you shows what is does provides ? rpm -q kernel-devel-6.12.0-55.34.1.el10_0 --provides
(In reply to Nicolas Chauvet (kwizart) from comment #34) > rpm -q kernel-devel kernel-devel-6.12.0-55.33.1.el10_0.x86_64_v2 kernel-devel-6.12.0-55.34.1.el10_0.x86_64_v2 > for the lastest kernel, can you shows what is does provides ? > rpm -q kernel-devel-6.12.0-55.34.1.el10_0 --provides installonlypkg(kernel) kernel-devel = 6.12.0-55.34.1.el10_0 kernel-devel(x86-64) = 6.12.0-55.34.1.el10_0 kernel-devel-uname-r = 6.12.0-55.34.1.el10_0.x86_64_v2 kernel-devel-x86_64_v2 = 6.12.0-55.34.1.el10_0
Error is the following: error: Failed build dependencies: kernel-devel = 6.12.0-55.34.1.el10_0_v2 is needed by xtables-addons-kmod-3.28-2.el10.x86_64 But what is weird is you have previously tested manually and it managed to find the appropriate version for your kernel-devel (as 6.12.0-55.34.1.el10_0 instead of the mangled 6.12.0-55.34.1.el10_0_v2 or the more expected 6.12.0-55.34.1.el10_0.x86_64_v2). We could still improves things by using the kernel-devel-uname-r modern variant but I don't get why it previously worked. The problem is that the fix would be in kmodtool which was expected not to be modified. So I guess I will have to install alma x86_64_v2... It could be a bug in the way alma set the _target_cpu RPM macro (can we see it with rpm -E %{_target_cpu} ) ?
> It could be a bug in the way alma set the _target_cpu RPM macro (can we see > it with rpm -E %{_target_cpu} ) ? $ rpm -E %{_target_cpu} x86_64
rpm -qi kmod-xtables-addons-6.12.0-55.el10_0-3.28-2.el10.x86_64_v2 Name : kmod-xtables-addons-6.12.0-55.el10_0 Version : 3.28 Release : 2.el10 Architecture: x86_64_v2 Install Date: Wed Oct 1 19:16:38 2025 Group : Unspecified Size : 89276 License : GPL-2.0-only Signature : (none) Source RPM : xtables-addons-kmod-3.28-2.el10.src.rpm Build Date : Wed Oct 1 19:15:51 2025 Build Host : almalinux10 URL : https://inai.de/projects/xtables-addons/ Summary : xtables-addons kernel module(s) for 6.12.0-55.el10_0 Description : This package provides the xtables-addons kernel modules built for the Linux kernel 6.12.0-55.el10_0 for the x86_64_v2 family of processors. uname -r 6.12.0-55.9.1.el10_0.x86_64_v2 rpm -q akmods akmods-0.6.1-2.el10_0.noarch Can you report the version of akmods rpm -qi akmods ? So for me everything operates correctly. You might have an outdated version from the epel10 rebuild for x86_64_v2 ?
Hi, this is what are you asking: $ rpm -qi akmods Name : akmods Version : 0.6.0 Release : 8.el10_0.alma_altarch Architecture: noarch Install Date: mer 1 ott 2025, 09:19:28 Group : Unspecified Size : 66008 License : MIT Signature : RSA/SHA256, sab 5 apr 2025, 14:42:25, Key ID b620c02335d447a6 Source RPM : akmods-0.6.0-8.el10_0.alma_altarch.src.rpm Build Date : gio 6 mar 2025, 16:29:21 Build Host : x64-builder04.almalinux.org Packager : AlmaLinux Packaging Team <packager> Vendor : AlmaLinux URL : http://rpmfusion.org/Packaging/KernelModules/Akmods Summary : Automatic kmods build and install tool Description : Akmods startup script will rebuild akmod packages during system boot, while its background daemon will build them for kernels right after they were installed. What is strange is this: $ rpm -qi kmod-xtables-addons-6.12.0-55.el10_0-3.28-2.el10.x86_64_v2 package kmod-xtables-addons-6.12.0-55.el10_0-3.28-2.el10.x86_64_v2 is not installed Checking on "kmod" packages I found this: $ rpm -qa | grep -i kmod kmod-31-11.el10.x86_64_v2 kmod-libs-31-11.el10.x86_64_v2 kmodtool-1.1-11.el10_0.alma_altarch.noarch akmods-0.6.0-8.el10_0.alma_altarch.noarch akmod-xtables-addons-3.28-2.el10.x86_64 I simply installed the xtables-addons package as I always did in previous versions.
right, so you don't have the updated akmods with the expected fixes, that's because you are using the almalinux altarch epel repository, not the original epel repository. You can get the fixed package at https://fr2.rpmfind.net/linux/epel/10.0/Everything/x86_64/Packages/a/akmods-0.6.1-2.el10_0.noarch.rpm
(In reply to Nicolas Chauvet (kwizart) from comment #40) > right, so you don't have the updated akmods with the expected fixes, that's > because you are using the almalinux altarch epel repository, not the > original epel repository. I, as usual, install epel-release package (the name is the same)
> I, as usual, install epel-release package (the name is the same) name is the same but the content is not. For some reason the akmods version is not the same, likely because there is a delay with the updates in this alma specific repos. This is an issue with alma side. (I will escalate to them). Anyway the fix is expected to be in akmods-0.6.1-2
(In reply to Nicolas Chauvet (kwizart) from comment #42) > > I, as usual, install epel-release package (the name is the same) > > name is the same but the content is not. mmh, this is not completely clear to me...at least the source (and the package list) should be the same...of course with some delay. > For some reason the akmods version is not the same, likely because there is > a delay with the updates in this alma specific repos. This is an issue with > alma side. (I will escalate to them). I tried to raise the ticket to their ticket system but, it seems that I can't create an account. > Anyway the fix is expected to be in akmods-0.6.1-2 I can confirm! Thanks.
The bug is still open at https://bugs.almalinux.org/view.php?id=565 But at far as I'm concerned, the original issue is closed.