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 1740816 - Mock armhfp config does not work on aarch64 host without 'armv7hl' in uname -a output
Summary: Mock armhfp config does not work on aarch64 host without 'armv7hl' in uname -...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 31
Hardware: arm
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2019-08-13 16:41 UTC by Adam Williamson
Modified: 2023-09-12 02:05 UTC (History)
34 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-24 16:57:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2019-08-13 16:41:57 UTC
Just try using a mock 'armhfp' config:

[root@aarch64-c26n1-oqa adamwill][PROD]# mock -r fedora-30-armhfp --rebuild os-autoinst-4.5-21.20190806gitc597122.fc31.src.rpm 
INFO: mock.py version 1.4.16 starting (python version = 3.7.4)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
INFO: Start(os-autoinst-4.5-21.20190806gitc597122.fc31.src.rpm)  Config(fedora-30-armhfp)
Start: clean chroot
Finish: clean chroot
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled dnf cache
Start: cleaning dnf metadata
Finish: cleaning dnf metadata
INFO: enabled HW Info plugin
Mock Version: 1.4.16
INFO: Mock Version: 1.4.16
Start: dnf install
fedora                                                                                280 kB/s |  51 kB     00:00    
Failed to synchronize cache for repo 'fedora'
Error: Failed to synchronize cache for repo 'fedora'

This seems to be because the mock 'target_arch' config opt is set to 'armv7hl' in the file:

config_opts['target_arch'] = 'armv7hl'

and I think that value gets used as the dnf 'basearch'. So because the repo config is this:

[fedora]
name=fedora
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
...

it winds up trying to query this URL:

https://mirrors.fedoraproject.org/metalink?repo=fedora-30&arch=armv7hl

but that isn't valid. mirrors.fp.o doesn't know about "armv7hl". It wants you to use "armhfp". This works fine:

https://mirrors.fedoraproject.org/metalink?repo=fedora-30&arch=armhfp

Comment 1 Adam Williamson 2019-08-13 18:13:54 UTC
Changing `config_opts['target_arch'] = 'armv7hl'` to `config_opts['target_arch'] = 'armhfp'` seems to work around this, though I don't know if there are any non-obvious consequences.

Comment 2 Miroslav Suchý 2019-08-19 14:58:09 UTC
This should not be the case. It was this way all the time. And DNF should transform this string using _BASEARCH_MAP to armhfp. Obviously, it does not.

DNF guys, can you please check it?

Comment 3 Adam Williamson 2019-08-19 15:10:43 UTC
For ease of reproduction, this is what we have on the host in question:

[adamwill@aarch64-c26n1-oqa ~][PROD]$ uname -r
5.0.17-300.fc30.aarch64
[adamwill@aarch64-c26n1-oqa ~][PROD]$ rpm -q mock
mock-1.4.16-2.fc30.noarch
[adamwill@aarch64-c26n1-oqa ~][PROD]$ rpm -q dnf
dnf-4.2.5-1.fc30.noarch

Comment 4 Miroslav Suchý 2019-08-20 14:17:43 UTC
I cannot reproduce it. On my AARCH64 machine I get:

# mock -r fedora-30-armhfp shell
INFO: mock.py version 1.4.16 starting (python version = 3.7.4)...
Start: init plugins
INFO: tmpfs initialized
INFO: selinux disabled
INFO: chroot_scan: initialized
INFO: compress_logs: initialized
Finish: init plugins
Start: run
Traceback (most recent call last):
  File "/usr/libexec/mock/mock", line 977, in <module>
    main()
  File "/usr/lib/python3.7/site-packages/mockbuild/trace_decorator.py", line 96, in trace
    result = func(*args, **kw)
  File "/usr/libexec/mock/mock", line 763, in main
    util.condPersonality(config_opts['target_arch'])
  File "/usr/lib/python3.7/site-packages/mockbuild/util.py", line 465, in condPersonality
    raise OSError(ctypes.get_errno(), os.strerror(ctypes.get_errno()))
OSError: [Errno 0] Success

I talked with Dan M. from dnf team and he does not have clue either.
I really wonder how you get the `armv7hl` as result of evaluation of $basearch because it is not in dnf.rpm._BASEARCH_MAP.values() and DNF should raise an exception in that point.

Hmm, this whole thing is possible due:
https://github.com/rpm-software-management/mock/pull/257
I tried this on some aarch64 machine - and even on machine using `mock -r fedora-30-aarch64 --forcearch=aarch64` and `linux32` does there nothing - no effect.

So my machines I can get a hand on are not capable of running 32 bits instruction.

Adam, are you sure that your machine can run 32 bits instructions natively? If not we can close this bug and you have to use `--forcearch=armhfp`

Comment 5 Adam Williamson 2019-08-20 15:11:24 UTC
Your reproducer is not sufficient, because --shell doesn't do anything with dnf. Note that you don't reach any "START: dnf <anything>" points in the output. That command works fine on my test machine:

[root@aarch64-c26n1-oqa adamwill][PROD]# mock -r fedora-30-armhfp --shell
INFO: mock.py version 1.4.16 starting (python version = 3.7.4)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled dnf cache
Start: cleaning dnf metadata
Finish: cleaning dnf metadata
INFO: enabled HW Info plugin
Finish: chroot init
Start: shell
<mock-chroot> sh-5.0# 

"Adam, are you sure that your machine can run 32 bits instructions natively?"

I'm not 100% sure, but I believe so. It's an X-Gene, and https://www.anandtech.com/show/5098/applied-micros-xgene-the-first-armv8-soc notes "As the X-Gene implements the ARMv8 ISA it is a full 64-bit architecture that is backwards compatible with 32-bit ARMv7." Also, the mock rebuild *does* work if I edit the config file to say armhfp instead of armv7hl, as I said in #c1. If the system wasn't 32-bit capable, presumably that would fail like your attempt?

Comment 6 Daniel Mach 2019-08-20 16:20:39 UTC
This is what I tried:

# setup virtualized environment:
$ dnf install qemu-user-static
$ dnf install --installroot=/opt/fedora-aarch64 --forcearch=aarch64 dnf mock bash systemd passwd vim-minimal glibc-minimal-langpack --repoid=rawhide --releasever=32 --nogpgcheck
$ systemd-nspawn -D /opt/fedora-aarch64/
$ mock -r fedora-30-armhfp --shell --old-chroot
It installs *aarch64* RPMs into the nested chroot.
The arch detection is definitely broken here.

# on baremetal - x86_64, installing i686
$ mock -r fedora-30-i386 --shell
-> installs i686 packages as expected

Other checks:
$ setarch linux32 dnf repoinfo --repoid=rawhide
-> shows url with 'aarch64' basearch - this is wrong!
(I'm not sure if linux32 is the right architecture, but probably the best setarch --list shows)

$ setarch i686 dnf repoinfo --repoid=rawhide
-> shows url with 'i386' basearch - as expected


It seems that mock correctly passes "armv7hl" to condPersonality() function.
On the other hand, DNF runs with aarch64 arch.
The arch detection in DNF/libdnf can be broken.


Minimal reproducer that should be showing 32bit arch:
python3 -c "PER_LINUX32 = 0x0008; import ctypes; _libc = ctypes.cdll.LoadLibrary(None); _libc.personality.argtypes = [ctypes.c_ulong]; _libc.personality.restype = ctypes.c_int;  _libc.personality(PER_LINUX32); import dnf.conf; c = dnf.conf.Conf(); print(c.arch)"

Comment 7 Daniel Mach 2019-08-20 17:24:29 UTC
Extended reproducer showing that the problem might be in uname (which is used by libdnf to detect arch):
python3 -c "PER_LINUX32 = 0x0008; import ctypes; _libc = ctypes.cdll.LoadLibrary(None); _libc.personality.argtypes = [ctypes.c_ulong]; _libc.personality.restype = ctypes.c_int;  _libc.personality(PER_LINUX32); import dnf.conf; c = dnf.conf.Conf(); print(c.arch); import platform; print(platform.uname())"

on x86_64:
i686
uname_result(system='Linux', node='...', release='5.3.0-0.rc4.git3.1.fc32.x86_64', version='#1 SMP Fri Aug 16 12:04:17 UTC 2019', machine='i686', processor='i686')


on aarch64:
aarch64
uname_result(system='Linux', node='...', release='5.3.0-0.rc4.git3.1.fc32.x86_64', version='#1 SMP Fri Aug 16 12:04:17 UTC 2019', machine='aarch64', processor='aarch64')

Comment 8 Daniel Mach 2019-08-21 07:07:40 UTC
Adam,
I believe we have hit situation described in bug#1691430#c12
Not every 64bit arm supports 32bit instructions.

The uname example from the previous comment returns aarch64 in qemu.
It returns armv8l on RPi3+.

I suppose uname returns correct data.
In that case, we cannot do anything with it.
If you believe it behaves incorrectly, please reopen this bug and move it to kernel.

Comment 9 Adam Williamson 2019-08-21 07:20:19 UTC
I keep saying it, but: *the build works fine if I edit the mock config*. That to me does not suggest the problem is my CPU missing support for doing the build, because if it didn't have that support, the build wouldn't work after I edit the config, would it?

Comment 10 Daniel Mach 2019-08-21 07:49:49 UTC
DNF should not make any assumptions about architectures.
The issue here is that you're not getting expected arch from uname.

The fact that it works for you if you explicitly set the architecture doesn't necessarily mean that the architectures are fully compatible
and maybe that's why the uname behaves the way it behaves.

Reassigning to kernel.

Comment 11 Adam Williamson 2019-08-21 16:13:25 UTC
so kernel folks, the question as I understand it at this point is 'why does this X-Gene CPU's `uname -a` not include armv7hl', is that intentional or a bug?

Comment 12 Justin M. Forbes 2020-03-03 16:29:27 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs.

Fedora 30 has now been rebased to 5.5.7-100.fc30.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31.

If you experience different issues, please open a new bug report for those.

Comment 13 Adam Williamson 2020-03-04 17:41:33 UTC
[adamwill@aarch64-c26n1-oqa ~][PROD]$ uname -a
Linux aarch64-c26n1-oqa.arm.fedoraproject.org 5.5.7-200.fc31.aarch64 #1 SMP Fri Feb 28 17:04:58 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

Comment 14 Ben Cotton 2020-11-03 16:52:49 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 15 Ben Cotton 2020-11-24 16:57:09 UTC
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 16 Red Hat Bugzilla 2023-09-12 02:05:56 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.