Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1033786

Summary: mock post install fails on armhfp
Product: [Fedora] Fedora Reporter: Nicolas Chauvet (kwizart) <kwizart>
Component: mockAssignee: Miroslav Suchý <msuchy>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: bochecha, dennis, kwizart, mebrown, msuchy, pbrobinson, rdieter, tlestach, williams
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: mock-1.2.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-12 21:18:19 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:
Bug Depends On:    
Bug Blocks: 245418    

Description Nicolas Chauvet (kwizart) 2013-11-22 22:23:12 UTC
Description of problem:
uname -i is used on postin snippet to set the runtime default config file.
But the command output armv7l on armhfp and so the default symlink is not set.



Version-Release number of selected component (if applicable):
mock-1.1.35-1.fc20.noarch

How reproducible:
always

Steps to Reproduce:
1. yum re-install mock shows on armhfp machine
2.
3.

Actual results:
warning: %post(mock-1.1.35-1.fc20.noarch) scriptlet failed, exit status 254
Non-fatal POSTIN scriptlet failure in rpm package mock-1.1.35-1.fc20.noarch

Expected results:
Clean update

Additional info:
$ uname -a :
Linux localhost 3.11.6-301.fc20.armv7hl #1 SMP Mon Oct 21 23:13:51 UTC 2013 armv7l armv7l armv7l GNU/Linux
I don't know how to detect between arm/armhfp and armv6hl (for the pidora).

Comment 1 Clark Williams 2014-01-04 16:36:48 UTC
Do we need a symlink from the armhfp config to an armv7l config?

Comment 2 Nicolas Chauvet (kwizart) 2014-01-06 09:34:13 UTC
Denis might know better the details on this.
Hopefully there is a solution that would still work when using third part architecture (such as armv6hl if the related cfg files are provided).

Comment 3 Peter Robinson 2014-03-10 13:22:43 UTC
(In reply to Clark Williams from comment #1)
> Do we need a symlink from the armhfp config to an armv7l config?

How do you deal with all the other ARM architectures? Having a quick look at the %post script I don't see where it's archful but presumably from the comment above it's trying to link the default config to the native arch.

The issue we have is that there's armv4t, armv5tel (and other v5 variants), armv6l armv6hl (in other v6 variants), armv7l etc etc and even aarach64 HW will happily run an ARMv7 userspace. The supported armv7hl is generally what we'd see but it's not to say it's the only option.

The armhfp isn't actually an architecture designator so shouldn't really ever be used in this context.

Comment 4 Nicolas Chauvet (kwizart) 2014-06-02 21:16:49 UTC
To the end, how to fix this bug ?
Do we need some mapping to circumvent this issue ? (armv7l -> armhfp) how about aarch64 ?

gcc -dumpmachine is probably an accurate way to discover the host userspace, but this will trigger a dependency on gcc which isn't needed yet. Anything better from the current set of mock dependencies ?

Comment 5 Dennis Gilmore 2014-06-02 22:05:05 UTC
replace the call to uname -i with 
python -c "import rpmUtils.arch;  baseArch = rpmUtils.arch.getBaseArch(\"$(uname -i)\"); print baseArch"

the issue you have is that uname -i may not match the yum base arch as you want the yum basearch the best way to get it is to ask yum.

Comment 6 Nicolas Chauvet (kwizart) 2014-06-02 22:39:18 UTC
(In reply to Dennis Gilmore from comment #5)
> replace the call to uname -i with 
> python -c "import rpmUtils.arch;  baseArch =
> rpmUtils.arch.getBaseArch(\"$(uname -i)\"); print baseArch"
it's output arm on armv7hl, so I don't know how it would solve the problem, unless it means moving back the mock config files from *armhfp.cfg to *arm.cfg namespace which would clash with previous arm softfp. (that been said, thoses arches are currently unsupported in recent fedora). 

One last question, how to predict the kernel RPM package target_cpu on arm from userspace ? As that's armv7hl but uname reports armv7l.

Comment 7 Dennis Gilmore 2014-06-03 02:00:33 UTC
[dennis@wandboard01 ~]$ uname -a
Linux wandboard01.ausil.us 3.15.0-0.rc5.git2.9.fc21.armv7hl #1 SMP Thu May 15 19:48:16 UTC 2014 armv7l armv7l armv7l GNU/Linux
[dennis@wandboard01 ~]$ python -c "import rpmUtils.arch;  baseArch = rpmUtils.arch.getBaseArch(); print baseArch"
armhfp

Comment 8 Dennis Gilmore 2014-06-03 02:01:33 UTC
drop the uname -i from the call and it gives us the right info

Comment 9 Mathieu Bridon 2014-08-25 14:59:00 UTC
This also fails on the Spacewalk koji:
http://koji.spacewalkproject.org/koji/getfile?taskID=168111&name=root.log

For sure, the arm-specific issue described here should be fixed, but even once that's done, I don't think the %post scriptlet should exit with a non-zero return code.

How about this instead:

-cfg=fedora-$ver-$(uname -i).cfg
-[ -e /etc/mock/$cfg ] || exit -2
-ln -s -f $cfg /etc/mock/default.cfg
+cfg=fedora-$ver-$(python -c "import rpmUtils.arch;  baseArch = rpmUtils.arch.getBaseArch(\"$(uname -i)\"); print baseArch").cfg
+[ -e /etc/mock/$cfg ] && ln -s -f $cfg /etc/mock/default.cfg

Comment 10 Rex Dieter 2014-08-25 15:45:37 UTC
Another possibility is to create the symlink and include in packaging at build time, instead of %post.  Then inconsistencies would be caught at build-time instead of during the install.

This means making the package that owns the symlink be arch'd though (mock is currently noarch).

Comment 11 Tomas Lestach 2014-08-26 14:28:21 UTC
Could we somehow prioritize the BZ?
This issue causes Spacewalk fc19 and fc20 builds to fail:
https://koji.spacewalkproject.org/koji/taskinfo?taskID=168270
https://koji.spacewalkproject.org/koji/taskinfo?taskID=168268
https://koji.spacewalkproject.org/koji/taskinfo?taskID=168266

Comment 12 Miroslav Suchý 2014-09-04 09:08:03 UTC
Fixed in commit c33350d in msuchy-work branch.

Comment 13 Miroslav Suchý 2014-10-12 21:18:19 UTC
Fixed in mock-1.2.0, which just landed in rawhide.