Bug 1644430
Summary: | akmods --force produces packages for wrong architecture (armv7l instead of armv7hl) | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Damian Wrobel <dwrobel> | ||||||||||
Component: | akmods | Assignee: | Nicolas Chauvet (kwizart) <kwizart> | ||||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||
Priority: | unspecified | ||||||||||||
Version: | 29 | CC: | hdegoede, hobbes1069, kwizart, leigh123linux, negativo17, nicolas.vieville, sergio | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | armv7hl | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | akmods-0.5.6-17.fc29 akmods-0.5.6-17.fc27 akmods-0.5.6-17.fc28 akmods-0.5.6-23.el7 | Doc Type: | If docs needed, set a value | ||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2018-11-13 02:21:53 UTC | Type: | Bug | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
Damian Wrobel
2018-10-30 19:43:42 UTC
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. |