Created attachment 1499061 [details] akmods --force build log Description of problem: akmods produces packages for wrong architecture (armv7l instead of armv7hl) The problem seems to be the result of akmods using invoking akmodsbuild with -target option with the value taken from the $(uname -m) command (see below grep output): # grep target /usr/sbin/akmods akmods_echo 1 4 "Building RPM using the command '$(which akmodsbuild) --target $(uname -m) --kernels ${this_kernelver} ${this_kmodsrpm}'" /sbin/runuser -s /bin/bash -c "$(which akmodsbuild) --quiet --quiet --target $(uname -m) --kernels ${this_kernelver} --outputdir ${tmpdir}results --logfile ${tmpdir}/akmodsbuild.log ${this_kmodsrpm}" akmods >> "${kmodlogfile}" 2>&1 which on raspberry pi returns: # uname -m armv7l This results in producing packages for armv7l architecture instead of armv7hl. Version-Release number of selected component (if applicable): # cat /etc/fedora-release Fedora release 29 (Twenty Nine) # uname -a Linux rpi3 4.18.16-300.fc29.armv7hl #1 SMP Sun Oct 21 00:56:28 UTC 2018 armv7l armv7l armv7l GNU/Linux # rpm -qv akmods akmods-0.5.6-16.fc29.noarch How reproducible: 100% Steps to Reproduce: 1. rpm -U http://koji.rpmfusion.org/kojifiles/packages/wireguard-kmod/0.0.20181018/1.fc29/armv7hl/akmod-wireguard-0.0.20181018-1.fc29.armv7hl.rpm http://koji.rpmfusion.org/kojifiles/packages/wireguard/0.0.20181018/1.fc29/armv7hl/wireguard-0.0.20181018-1.fc29.armv7hl.rpm 2.akmods --force Actual results: # akmods --force Checking kmods exist for 4.18.16-300.fc29.armv7hl [ OK ] Building and installing wireguard-kmod [FAILED] Could not install newly built RPMs. You can find them and the logfile 0.0.20181018-1-for-4.18.16-300.fc29.armv7hl.failed.log in /var/cache/akmods/wireguard/ # rpm -U kmod-wireguard-4.18.16-300.fc29.armv7hl-0.0.20181018-1.fc29.armv7l.rpm package kmod-wireguard-4.18.16-300.fc29.armv7hl-0.0.20181018-1.fc29.armv7l is intended for a different architecture Expected results: akmods should produce installable packages Additional info: Running akmodsbuild directly as following works perfectly: (a) with --target arm7hl: # sudo -u akmods /sbin/akmodsbuild --target armv7hl --kernels 4.18.16-300.fc29.armv7hl /usr/src/akmods/wireguard-kmod.latest * Rebuilding /usr/src/akmods/wireguard-kmod.latest for kernel(s) 4.18.16-300.fc29.armv7hl: prep build install clean; Successfull; Saved kmod-wireguard-4.18.16-300.fc29.armv7hl-0.0.20181018-1.fc29.armv7hl.rpm in /tmp/ (b) without --target option: # sudo -u akmods /sbin/akmodsbuild --kernels 4.18.16-300.fc29.armv7hl /usr/src/akmods/wireguard-kmod.latest * Rebuilding /usr/src/akmods/wireguard-kmod.latest for kernel(s) 4.18.16-300.fc29.armv7hl: prep build install clean; Successfull; Saved kmod-wireguard-4.18.16-300.fc29.armv7hl-0.0.20181018-1.fc29.armv7hl.rpm in /tmp/ The later works because akmodsbuild contains the following code: target="$(uname -m)" if [[ "${target}" == "armv7l" ]]; then target="armv7hl" fi I'm not sure what could be the proper fix either to rely on `uname -m` or maybe _target_cpu could be used instead: # rpm --eval '%{_target_cpu}' armv7hl
Created attachment 1499145 [details] akmodsbuild modified Hello, Thanks for reporting this issue. I wonder if you could try the modified akmodsbuild script provided as an attachment. First backup the current akmodsbuild script: mv /usr/sbin/akmodsbuild /usr/sbin/akmodsbuild.bak Then copy the modified akmodsbuild file in /usr/sbin: cp /path_to_your_downloads/akmodsbuild /usr/sbin/ Ensure it is executable: chmod 0755 /usr/sbin/akmodsbuild Then proceed as usual: akmods --force Any feedback is welcome. Feel free to make any comment about this issue. Cordially, -- NVieville
Created attachment 1500682 [details] akmodsbuild.patch NVieville, Thank you for the modified version, I converted it into a patch (to see what has changed) and I can confirm it's working now for me. >Any feedback is welcome. Feel free to make any comment about this issue. The only comment I have is that when someone will try to run akmodsbuild with the --target armv7l then it might be a little bit misleading that despite given option, resultant rpm will be for a different architecture (armv7hl). Also when you run akmods as following: # bash -x /usr/sbin/akmods --force then in the bash output you will see that akmodsbuild is invoked with --target armv7l option. In other words, IMHO it would be better if akmods will pass a proper target to akmodsbuild and akmodsbuild will not try to mangle given architecture.
Created attachment 1500751 [details] akmodsbuild.v2.patch using rpm -E %{_target_cpu} Based on comment "I'm not sure what could be the proper fix either to rely on `uname -m` or maybe _target_cpu could be used instead: # rpm --eval '%{_target_cpu}' armv7hl " seems to me the correct approach
Sergio, Please bear in mind that akmods also needs to be patched as this is the component which passes --target option to the akmodsbuild.
as reported (a) with --target arm7hl works fine
Hello, As Sergio suggested it, and according to the discussion below in comment #5: https://bugzilla.redhat.com/show_bug.cgi?id=719609#c5 there seems that the only way to check the architecture of the OS itself on armv7 is to use "rpm -E '%{_target_cpu}'". "uname -m" seems to be wrong from a long time. @Damian Wrobel I wonder if could please give a try to the patch you can fetch from this URL: https://src.fedoraproject.org/fork/nvieville/rpms/akmods/c/1c9026729bd4e9aa8f1cb41f57490285654c48d8?branch=rhbz-1644430 Just click on the button "patch" to grab it. Then apply it to the /usr/sbin/akmods and /usr/sbin/akmodsbuild files (maybe you should backup them before). Then proceed as usual (it should be necessary to remove the kmod-wireguard-4.18.16-300.fc29.armv7hl-0.0.20181018-1.fc29.armv7hl package before proceeding): akmods --force Any feedback is welcome. Feel free to make any comment about this issue. Cordially, -- NVieville
(In reply to nicolas.vieville from comment #6) > Hello, > > As Sergio suggested it, and according to the discussion below in comment #5: > > https://bugzilla.redhat.com/show_bug.cgi?id=719609#c5 > > there seems that the only way to check the architecture of the OS itself on > armv7 is to use "rpm -E '%{_target_cpu}'". "uname -m" seems to be wrong from > a long time. This is not quite true, what we really want is the kernel architecture, not the architecture of the userspace. In most cases this is the same, but it could be different like with x32 (the new 32bit ABI for x86) where the kernel would be 64bit but the userspace 32bit. (Solaris used such design since years on sparc). With that said, support for x32 is not planned for Fedora, so it's probably the best way forward to use target_cpu. I will try to reproduce.
About using target_cpu one issue is that in some case, the default could be to use armv7hnl by instead of armv7hl Tested on pi2: # rpm -E %{_target_cpu} armv7hnl So it just move the problem elsewhere. Also I don't understand why moving this piece of code helps, any reasoning ?
(In reply to nicolas.vieville from comment #6) > I wonder if could please give a try to the patch you can fetch from this URL: Tested on RPi3+: # dnf reinstall -y akmods # akmods --force Checking kmods exist for 4.18.16-300.fc29.armv7hl [ OK ] Building and installing wireguard-kmod [FAILED] Could not install newly built RPMs. You can find them and the logfile 0.0.20181018-1-for-4.18.16-300.fc29.armv7hl.failed.log in /var/cache/akmods/wireguard/ [FAILED] # curl https://src.fedoraproject.org/fork/nvieville/rpms/akmods/c/1c9026729bd4e9aa8f1cb41f57490285654c48d8.patch | patch -p1 -d /usr/sbin/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1751 100 1751 0 0 1843 0 --:--:-- --:--:-- --:--:-- 1843 patching file akmods patching file akmodsbuild # akmods --force Checking kmods exist for 4.18.16-300.fc29.armv7hl [ OK ] Building and installing wireguard-kmod [ OK ] # cd /tmp # sudo -u akmods /sbin/akmodsbuild --target armv7hl --kernels 4.18.16-300.fc29.armv7hl /usr/src/akmods/wireguard-kmod.latest * Rebuilding /usr/src/akmods/wireguard-kmod.latest for kernel(s) 4.18.16-300.fc29.armv7hl: prep build install clean; Successfull; Saved kmod-wireguard-4.18.16-300.fc29.armv7hl-0.0.20181018-1.fc29.armv7hl.rpm in /tmp/ # sudo -u akmods /sbin/akmodsbuild --kernels 4.18.16-300.fc29.armv7hl /usr/src/akmods/wireguard-kmod.latest * Rebuilding /usr/src/akmods/wireguard-kmod.latest for kernel(s) 4.18.16-300.fc29.armv7hl: prep build install clean; Successfull; Saved kmod-wireguard-4.18.16-300.fc29.armv7hl-0.0.20181018-1.fc29.armv7hl.rpm in /tmp/
akmods-0.5.6-17.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-cd5f04fe44
akmods-0.5.6-17.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-16e0cb4710
akmods-0.5.6-17.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d925301651
akmods-0.5.6-17.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbd1fe8b0b
akmods-0.5.6-17.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bbb7ae9b1e
Hi Nicolas, AFAIK, I think you miss the main patch for arm. Thanks diff --git a/akmodsbuild b/akmodsbuild index 2170f7c..78d25ac 100644 --- a/akmodsbuild +++ b/akmodsbuild @@ -27,10 +27,7 @@ myver="0.5.6" # defaults that might get overwritten by user: kernels="$(uname -r)" -target="$(uname -m)" -if [[ "${target}" == "armv7l" ]]; then - target="armv7hl" -fi +target="$(rpm -E '%{_target_cpu}')"
(In reply to Sergio Monteiro Basto from comment #15) > Hi Nicolas, AFAIK, I think you miss the main patch for arm. As reported in c#8 this patch is wrong. arm is that weird that it may report armv7hnl when neon is supported in /proc/cpuinfo instead of the normal armv7hl. This may break even more when armv8hl and others variant will be introduced (with the next rpm.org).
akmods-0.5.6-17.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-16e0cb4710
akmods-0.5.6-17.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbd1fe8b0b
akmods-0.5.6-17.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d925301651
akmods-0.5.6-17.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-cd5f04fe44
akmods-0.5.6-17.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bbb7ae9b1e
akmods-0.5.6-17.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
akmods-0.5.6-17.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
akmods-0.5.6-17.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
FEDORA-EPEL-2019-3eceb6f9bf has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-3eceb6f9bf
akmods-0.5.6-22.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-3eceb6f9bf
FEDORA-EPEL-2019-6a710036e9 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6a710036e9
akmods-0.5.6-23.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6a710036e9
akmods-0.5.6-23.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.