Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle multilib (file coloring) #1217

Closed
kladiv opened this issue Jan 19, 2018 · 7 comments
Closed

Handle multilib (file coloring) #1217

kladiv opened this issue Jan 19, 2018 · 7 comments
Labels

Comments

@kladiv
Copy link

kladiv commented Jan 19, 2018

PR: #1227


cat /etc/centos-release -> CentOS Linux release 7.4.1708 (Core)

I'm trying to install GLIBC 32bit :

# rpm-ostree install glibc.i686

I see:

Inactive requests:
  glibc-2.17-196.el7_4.2.i686 (already provided by glibc-2.17-196.el7_4.2.x86_64)
  glibc (already provided by glibc-2.17-196.el7_4.2.x86_64)
  glibc.i686 (already provided by glibc-2.17-196.el7_4.2.x86_64)

Can we have the possibility to install glibc 32bit on x86_64 system?
I'm going to install another RPM software package that requires those dependences.

Thank you

@cgwalters cgwalters added the bug label Jan 19, 2018
@jlebon
Copy link
Member

jlebon commented Jan 19, 2018

glibc.i686 (already provided by glibc-2.17-196.el7_4.2.x86_64)

Interesting. Somehow we're getting confused here when matching provides. Will look into it.

@jlebon
Copy link
Member

jlebon commented Jan 19, 2018

So, the immediate failure you're seeing here was fixed by the latest version of libdnf (bumped in #1114). However, the install will then fail with:

# rpm-ostree install glibc.i686
Checking out tree fcbfac0... done
Enabled rpm-md repositories: base updates extras
rpm-md repo 'base' (cached); generated: 2017-09-05 21:51:13
rpm-md repo 'updates' (cached); generated: 2018-01-18 10:10:54
rpm-md repo 'extras' (cached); generated: 2018-01-05 14:30:45

Importing metadata [=============] 100%
Resolving dependencies... done
Applying 2 overlays


error: Checkout glibc-2.17-196.el7_4.2.i686: Hardlinking b4/7fafc578622f7271ab7a7265db561e0e06b2b5b8a87774dbf39ba909cc3b81.file to ldconfig: File exists

The reason for this is that we don't consider file colors when layering files. Basically, /sbin/ldconfig are different files between the i686 and x86_64 versions, and librpm has this concept of coloring in order to allow installing these files without conflicting with each other (in this case, by letting the x86_64 version win).

Hmm, maybe we can add a callback to ostree_repo_checkout_at to allow skipping over files? Or it might be easier to just add a hack in the importer on x86_64 to special-case glibc and skip over those specific 32-bit-coloured files.

@jlebon
Copy link
Member

jlebon commented Jan 19, 2018

Can we have the possibility to install glibc 32bit on x86_64 system?
I'm going to install another RPM software package that requires those dependences.

Can you expand on this? Which package are you planning to install? Could it be run as a container?

@kladiv
Copy link
Author

kladiv commented Jan 19, 2018

Package is: lgtoclnt-8.2.3.0-1.x86_64.rpm (EMC Networker backup agent)

# rpm -Uvh --test lgtoclnt-8.2.3.0-1.x86_64.rpm
error: Failed dependencies:
        /bin/ksh is needed by lgtoclnt-8.2.3.0-1.x86_64
        libc.so.6 is needed by lgtoclnt-8.2.3.0-1.x86_64
        libc.so.6(GLIBC_2.0) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libc.so.6(GLIBC_2.1) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libc.so.6(GLIBC_2.1.1) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libc.so.6(GLIBC_2.1.2) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libc.so.6(GLIBC_2.1.3) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libc.so.6(GLIBC_2.2) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libc.so.6(GLIBC_2.2.3) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libc.so.6(GLIBC_2.3) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libc.so.6(GLIBC_2.3.2) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libc.so.6(GLIBC_2.3.4) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libdl.so.2 is needed by lgtoclnt-8.2.3.0-1.x86_64
        libdl.so.2(GLIBC_2.0) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libdl.so.2(GLIBC_2.1) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libm.so.6 is needed by lgtoclnt-8.2.3.0-1.x86_64
        libpthread.so.0 is needed by lgtoclnt-8.2.3.0-1.x86_64
        libpthread.so.0(GLIBC_2.0) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libpthread.so.0(GLIBC_2.1) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libpthread.so.0(GLIBC_2.2) is needed by lgtoclnt-8.2.3.0-1.x86_64
        libpthread.so.0(GLIBC_2.3.2) is needed by lgtoclnt-8.2.3.0-1.x86_64
        librt.so.1 is needed by lgtoclnt-8.2.3.0-1.x86_64
        librt.so.1(GLIBC_2.2) is needed by lgtoclnt-8.2.3.0-1.x86_64

We correctly installed into standard CentOS 7 / RHEL 7. It runs directly in the host to allow backups of any host file systems (e.g. /). Never tried to create a Dockerfile for that purpose.

I guess this bug is related to all i686 packages on x86_64 (multilib). I think it should be resolved due to other possible scenarios in Enterprise companies.

@cgwalters
Copy link
Member

This is fixable, but it's a really good example of the type of bug introduced by the fact that rpm-ostree effectively replaces a lot of librpm.

@cgwalters cgwalters changed the title Installation of glibc i686 on x86_64 Handle multilib (file coloring) Jan 26, 2018
@jlebon jlebon added the jira for syncing to jira label Feb 1, 2018
jlebon added a commit to jlebon/rpm-ostree that referenced this issue Feb 7, 2018
Not all files from an RPM are necessarily removed during pkg erasure.
For example, files which are shared between pkgs shouldn't be deleted.
Similarly, not all files in an RPM are necessarily copied during pkg
installs. This is the case for multilib handling, which is a mess in its
own right. But such is the cost of trying to replace major parts of a
long-standing foundational project like RPM.

This patch adds some smarts to the way we do overlays and overrides to
handle these cases by calculating beforehand which files we *should't*
checkout/delete.

Closes: coreos#1217
Closes: coreos#1145
@kladiv
Copy link
Author

kladiv commented Feb 9, 2018

@cgwalters I see issue has been resolved.
Can I execute rpm-ostree upgrade ?

@dustymabe
Copy link
Member

@cgwalters I see issue has been resolved.
Can I execute rpm-ostree upgrade ?

If you are on a Fedora or CentOS official release stream then you'll have to wait til a new release of rpm-ostree is out and makes it into the distro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants