Bug 1644430

Summary: akmods --force produces packages for wrong architecture (armv7l instead of armv7hl)
Product: [Fedora] Fedora Reporter: Damian Wrobel <dwrobel>
Component: akmodsAssignee: Nicolas Chauvet (kwizart) <kwizart>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: 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:
Attachments:
Description Flags
akmods --force build log
none
akmodsbuild modified
none
akmodsbuild.patch
none
akmodsbuild.v2.patch using rpm -E %{_target_cpu} none

Description Damian Wrobel 2018-10-30 19:43:42 UTC
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

Comment 1 nicolas.vieville 2018-10-30 22:34:53 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

Comment 2 Damian Wrobel 2018-11-02 19:45:07 UTC
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.

Comment 3 Sergio Monteiro Basto 2018-11-03 02:04:09 UTC
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

Comment 4 Damian Wrobel 2018-11-03 11:03:07 UTC
Sergio,

Please bear in mind that akmods also needs to be patched as this is the component which passes --target option to the akmodsbuild.

Comment 5 Sergio Monteiro Basto 2018-11-03 13:10:20 UTC
as reported (a) with --target arm7hl works fine

Comment 6 nicolas.vieville 2018-11-03 17:37:52 UTC
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

Comment 7 Nicolas Chauvet (kwizart) 2018-11-05 10:27:43 UTC
(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.

Comment 8 Nicolas Chauvet (kwizart) 2018-11-05 10:49:14 UTC
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 ?

Comment 9 Damian Wrobel 2018-11-05 13:16:33 UTC
(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/

Comment 10 Fedora Update System 2018-11-05 14:17:47 UTC
akmods-0.5.6-17.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-cd5f04fe44

Comment 11 Fedora Update System 2018-11-05 14:17:57 UTC
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

Comment 12 Fedora Update System 2018-11-05 14:18:05 UTC
akmods-0.5.6-17.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d925301651

Comment 13 Fedora Update System 2018-11-05 14:18:13 UTC
akmods-0.5.6-17.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbd1fe8b0b

Comment 14 Fedora Update System 2018-11-05 14:18:22 UTC
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

Comment 15 Sergio Monteiro Basto 2018-11-05 15:40:49 UTC
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}')"

Comment 16 Nicolas Chauvet (kwizart) 2018-11-05 16:11:01 UTC
(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).

Comment 17 Fedora Update System 2018-11-06 01:13:39 UTC
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

Comment 18 Fedora Update System 2018-11-06 22:01:07 UTC
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

Comment 19 Fedora Update System 2018-11-06 22:45:26 UTC
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

Comment 20 Fedora Update System 2018-11-06 23:27:57 UTC
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

Comment 21 Fedora Update System 2018-11-06 23:59:52 UTC
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

Comment 22 Fedora Update System 2018-11-13 02:21:53 UTC
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.

Comment 23 Fedora Update System 2018-11-17 02:08:00 UTC
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.

Comment 24 Fedora Update System 2018-11-17 05:22:23 UTC
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.

Comment 25 Fedora Update System 2019-10-12 21:38:05 UTC
FEDORA-EPEL-2019-3eceb6f9bf has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-3eceb6f9bf

Comment 26 Fedora Update System 2019-10-13 03:15:10 UTC
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

Comment 27 Fedora Update System 2019-10-16 09:08:52 UTC
FEDORA-EPEL-2019-6a710036e9 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6a710036e9

Comment 28 Fedora Update System 2019-10-16 16:09:07 UTC
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

Comment 29 Fedora Update System 2019-10-31 00:19:55 UTC
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.