emerge does not work in musl container

[asarubbo]

On the host:

~ # docker run -it -d --name musl gentoo/stage3:musl
~ # docker exec -it musl /bin/bash

Then in the container:

~ # emerge --sync -q
~ # emerge -v push

 * IMPORTANT: 12 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 1.37 s.

[ebuild  N     ] app-shells/push-3.4::gentoo  0 KiB

Total: 1 package (1 new), Size of downloads: 0 KiB

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) app-shells/push-3.4::gentoo
 * push-3.4.tar.gz BLAKE2B SHA512 size ;-) ...                                                                                                                                  [ ok ]
File not found: /usr/lib/portage/python3.10/ebuild-ipc
 * The ebuild phase 'setup' has exited unexpectedly. This type of behavior
 * is known to be triggered by things such as failed variable assignments
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before
 * exiting, bash should have displayed an error message above. If bash did
 * not produce an error message above, it's possible that the ebuild has
 * called `exit` when it should have called `die` instead. This behavior
 * may also be triggered by a corrupt bash binary or a hardware problem
 * such as memory or cpu malfunction. If the problem is not reproducible or
 * it appears to occur randomly, then it is likely to be triggered by a
 * hardware problem. If you suspect a hardware problem then you should try
 * some basic hardware diagnostics such as memtest. Please do not report
 * this as a bug unless it is consistently reproducible and you are sure
 * that your bash binary and hardware are functioning properly.
File not found: /usr/lib/portage/python3.10/ebuild-ipc
 * The ebuild phase 'die_hooks' has exited unexpectedly. This type of
 * behavior is known to be triggered by things such as failed variable
 * assignments (bug #190128) or bad substitution errors (bug #200313).
 * Normally, before exiting, bash should have displayed an error message
 * above. If bash did not produce an error message above, it's possible
 * that the ebuild has called `exit` when it should have called `die`
 * instead. This behavior may also be triggered by a corrupt bash binary or
 * a hardware problem such as memory or cpu malfunction. If the problem is
 * not reproducible or it appears to occur randomly, then it is likely to
 * be triggered by a hardware problem. If you suspect a hardware problem
 * then you should try some basic hardware diagnostics such as memtest.
 * Please do not report this as a bug unless it is consistently
 * reproducible and you are sure that your bash binary and hardware are
 * functioning properly.

>>> Failed to emerge app-shells/push-3.4, Log file:

>>>  '/var/tmp/portage/app-shells/push-3.4/temp/build.log'

 * Messages for package app-shells/push-3.4:

 * The ebuild phase 'setup' has exited unexpectedly. This type of behavior
 * is known to be triggered by things such as failed variable assignments
 * (bug #190128) or bad substitution errors (bug #200313). Normally, before
 * exiting, bash should have displayed an error message above. If bash did
 * not produce an error message above, it's possible that the ebuild has
 * called `exit` when it should have called `die` instead. This behavior
 * may also be triggered by a corrupt bash binary or a hardware problem
 * such as memory or cpu malfunction. If the problem is not reproducible or
 * it appears to occur randomly, then it is likely to be triggered by a
 * hardware problem. If you suspect a hardware problem then you should try
 * some basic hardware diagnostics such as memtest. Please do not report
 * this as a bug unless it is consistently reproducible and you are sure
 * that your bash binary and hardware are functioning properly.

~ # ls -la /usr/lib/portage/python3.10/ebuild-ipc
-rwxr-xr-x 1 root root 616 Jan 15 22:11 /usr/lib/portage/python3.10/ebuild-ipc

[ajakk]

Works for me...: musl.log

[ajakk]

It even works for me if I sync the wrong way: musl2.log

It's clear that your text isn't a verbatim copy and paste, are we sure you haven't omitted anything from your command lines?

[ajakk]

Please share the output of: docker run -it gentoo/stage3:musl bash -c "emerge-webrsync && emerge -v push"

[asarubbo]

Let's prefer a screenshot over a copy-paste so at least you cannot say that I have omitted something

I also took the liberty to replace emerge-webrsync with emerge --sync -q and this is the result: (NOTE that I added -q on purpose otherwise the output was too much long for a screenshot)

I can make a video with media-video/recordmydesktop if you still don't trust the output.

[ajakk]

What's the host? What docker version?

[asarubbo]

This is a freshly-installed and up-to-date CentOS 7

~ # rpm -qa | grep docker
docker-client-1.13.1-209.git7d71120.el7.centos.x86_64
docker-common-1.13.1-209.git7d71120.el7.centos.x86_64
docker-1.13.1-209.git7d71120.el7.centos.x86_64

Note that the system where I originally reproduced the issue and the system where I did further tests are different, so it is very probably that you can reproduce on a fresh-installed up-to-date CentOS 7.

[KSmanis]

You might have better luck running the container with the --privileged flag, but TBH v1.13.1 is ancient. For the record, I also didn't encounter any issues in a stable Gentoo system (Docker Engine v20.10.22).

[asarubbo]

privileged container works for me, I don't undertstand why but at least I can use it.

[KSmanis]

The tl;dr explanation is that Docker's default security profile blocks certain syscalls made by portage. The security profile for v1.13.1 can be found here in case you want to pinpoint the blocked syscall that is giving you issues.

[asarubbo]

Thanks for the hint so I think that one of those are true:

1) CentOS 7 Changed its security profile 2) Recent versions of portage make syscall that didn't do in the past

[ajakk]

Yeah, that makes sense. It's an old docker version problem, so I'm not sure we can do anything about it from the image's perspective:

1. Will have to be solved by configuration changes by the CentOS admin
2. Will have to be fixed in Portage (and I'm not sure we should care about supporting CentOS 7 containers), or will have to be worked around by the admin by running privileged containers

[KSmanis]

Perhaps a README note would be useful, since this is an issue affecting any Docker version to a certain extent.

[ajakk]

CentOS 7 is now EOL and I can't find anything else still-alive which is packaging a version of Docker near this old (https://repology.org/project/docker/versions), so I think we can call this obsolete as nobody should be using a Docker that old in modern times.