Bug 1740816

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.

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?

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

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`

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?

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)"

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')

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.

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?

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.

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?

*********** 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.

[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

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.

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.