Bug 1226818 - setarch i386 /usr/bin/dnf --install /tmp/foo sets host arch when /etc/rpm/platform is present
Summary: setarch i386 /usr/bin/dnf --install /tmp/foo sets host arch when /etc/rpm/pla...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 26
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1163028
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-01 08:37 UTC by Miroslav Suchý
Modified: 2017-07-10 13:24 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1178580
Environment:
Last Closed: 2017-06-27 17:48:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Miroslav Suchý 2015-06-01 08:37:01 UTC
This problem very likely occurs in DNF too. I am cloning it solely to document the use cases for bug 1163028.
The resolution of this bug depends on how we decide to document behaviour of --installroot.


+++ This bug was initially created as a clone of Bug #1178580 +++

Description of problem:
Running on an x86_64 Fedora 20 host, I cannot use mock to rebuild RPMs
for the target 'fedora-20-i386' or 'fedora-21-i386'. In both cases
attempts to build the RPM will fail at ./configure time because the C
compiler cannot be run. The reason it can't be run is that despite this
theoretically being a 32-bit buildroot, vast swatches of x86_64 RPMs have
been installed and vast swatches of i686 RPMs (such as libc) have *not*
been installed.

This is a fairly severe issue because it prevents rebuilding i686
packages on an x86_64 host if you have local versions of a dual
architecture package installed and now need to update it for some
reason. Without the ability to rebuild a 32-bit version, you're
screwed (as I am now).

Version-Release number of selected component (if applicable):
mock-1.2.3-1.fc20.noarch
yum-3.4.3-152.fc20.noarch

This also happens on several prior releases of mock, so it may be a
behavior change in yum.

How reproducible:

Completely.

Steps to Reproduce:

1. Get a source RPM. Freetype will do.
2. mock -r fedora-20-i386 --scrub all
3. setarch i386 mock --verbose -r fedora-20-i386 freetype-2.5.0-7.fc20.src.rpmo

setarch isn't supposed to be necessary but I've provided it as an
extra-large hammer.

Actual results:

Build run eventually fails with:

DEBUG: configure: WARNING: unrecognized options: --disable-dependency-tracking
DEBUG: checking build system type... x86_64-redhat-linux-gnu
DEBUG: checking host system type... x86_64-redhat-linux-gnu
DEBUG: checking for x86_64-redhat-linux-gnu-gcc... no
DEBUG: checking for gcc... gcc
DEBUG: checking whether the C compiler works... no
DEBUG: configure: error: in `/builddir/build/BUILD/freetype-2.5.0/builds/unix':
DEBUG: configure: error: C compiler cannot create executables
DEBUG: See `config.log' for more details
DEBUG: make: *** [setup] Error 77

Inspection of the install logs will reveal that, for example, there
are no 32-bit libraries that freetype depends on installed; the versions
(and -devel versions) are x86_64 versions.

Expected results:

Build completes, produces 32-bit binaries.

Additional info:

I will attach the full output of a mock run and the config.log output.


--- Additional comment from Chris Siebenmann on 2015-01-08 08:29:16 EST ---

My current yum version is indeed yum-3.4.3-152.fc20.noarch. 'rpm -V yum'
says it's unmodified except /etc/yum.conf, which I modified to keep more
kernels ('installonly_limit=...').

It does appear to be yum. 'setarch i386 yum ...' tries to install 64-bit
packages. The very first package it tries to install is:

    Resolving Dependencies
    --> Running transaction check
    ---> Package bash.x86_64 0:4.2.53-1.fc20 will be installed

So from the moment it starts picking packages it's going bad.
After the first try (with the command line as-is) did this, I
retried with '--disablerepo=* --enablerepo fedora --enablerepo
updates' and it did the same thing.

I can't see anything in the yum output up to that point that's
useful. setarch itself works; 'setarch i386 uname -m' shows the
expected i686 and 'setarch i386 python' followed by importing the
os module and looking at 'os.uname()[4]' also show i686.

Oh! I found it!

rpmUtils.arch.getCanonArch() looks at /etc/rpm/platform first unless
called with 'skipRpmPlatform=True', which arch.py doesn't seem to do.
I have an /etc/rpm/platform with 'x86_64-redhat-linux' (and I don't know
where it comes from, it's been there since 2006). With this removed,
everything seems to work fine (eg the yum command above works).

Is yum checking /etc/rpm/platform a recent change? (Either by adding that
code or by no longer calling getCanonArch() with skipRpmPlatform=True.)

This definitely didn't used to happen in Fedora 20 (and in earlier
Fedora versions this machine has run); I've built and rebuilt 32-bit
RPMs on my machine before, although probably not in the last few months.

--- Additional comment from Miroslav Suchý on 2015-01-08 09:14:24 EST ---

> Oh! I found it!

Perfect!

Does 
  rpm -qf /etc/rpm/platform
say something?

So it is yum bug. Reassigning. It is weird that this behaviour happen now to you.
The code is in yum since:
  Tue Feb 17 05:22:35 2004

IMO correct solution should be to not read /etc/rpm/platform, but to read ${installroot}/etc/rpm/platform (if exists).
However since yum is in maintance mode now, feel free to close it as DEFERRED.

I done 'git grep' in dnf.git and it appear the code is not there. So DNF should be safe.

--- Additional comment from Chris Siebenmann on 2015-01-08 10:43:44 EST ---

'rpm -qf /etc/rpm/platform' says that it's not owned by a package. This
machine was initially installed in 2006 and has been upgraded from
Fedora version to Fedora version ever since; /etc/rpm/platform appears
to have been written during that initial installation (it's got about
the right timestamp for it) and then never touched afterwards.

(/etc/rpm/platform appears to be a 2002-era feature that was designed
to get rpm out of the business of parsing uname(2) to determine the
architecture. More modern Fedora installs, such as a machine initially
installed in 2011 and upgraded from version to version since then, do
not have an /etc/rpm/platform. I suspect that at one point the installer
created it because rpm wanted it and then that feature was backed out of
rpm and thus the installer.)

As a result, I suspect that this is not an important bug (especially
with yum in maintenance mode).

As for timing of when this broke for me and versions of packages, it
looks like I probably last rebuilt a i686 package with mock in March 2014,
and at the time I probably had yum-3.4.3-137.fc20 and mock-1.1.36-1.fc20
(based on /var/log/yum.log*'s logging of what was updated when). I can't
see anything obvious in 'rpm -q --changelog' for mock or yum since then.

Comment 1 Fedora Admin XMLRPC Client 2016-07-08 09:30:53 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Fedora End Of Life 2016-07-19 20:53:07 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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 3 Miroslav Suchý 2016-07-27 14:17:06 UTC
Still valid.

Comment 4 Fedora End Of Life 2017-02-28 09:44:44 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 5 Jaroslav Mracek 2017-06-27 17:48:53 UTC
It looks lite that it is impossible to reproduce the issue with dnf-2.5.1-1 (dnf-nightly version) on Fedora 25. If anyone will find the issue reproducer with dnf-2.5.1+, please don't hesitate to reopen the bug report.

Comment 6 Miroslav Suchý 2017-07-10 13:24:46 UTC
The code was removed in commit f7dd24e10fdc6d1edc7b0924af0201dfb114223b
And replaced by 
  arch = hawkey.detect_arch()
I tried to create /etc/rpm/platform with some different content and hawkey seems to ignore it, which is good.
So I am fine with closing.


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