Updating to glibc-2.31-r6 on x32 installs breaks quite a few portage features, at least userfetch and userpriv and maybe pid-sandbox. For example: # emerge -1O libffi >>> Verifying ebuild manifests * IMPORTANT: 7 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. >>> Emerging (1 of 1) dev-libs/libffi-3.3-r2::gentoo Unable to configure loopback interface: Operation not permitted [Errno 14] Bad address: /bin/bash -c >> /var/cache/distfiles/.__portage_test_write__ 2>/dev/null ; rval=$? ; rm -f /var/cache/distfiles/.__portage_test_write__ ; exit $rval Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/portage/process.py", line 391, in spawn unshare_flags, cgroup) File "/usr/lib/python3.7/site-packages/portage/process.py", line 740, in _exec os.setgroups(groups) File "/usr/lib/python3.7/site-packages/portage/__init__.py", line 246, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 14] Bad address Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/portage/util/_async/ForkProcess.py", line 55, in _spawn rval = self._run() File "/usr/lib/python3.7/site-packages/_emerge/EbuildFetcher.py", line 246, in _run _drop_privs_userfetch(self._settings) File "/usr/lib/python3.7/site-packages/portage/package/ebuild/fetch.py", line 102, in _drop_privs_userfetch os.setgroups(spawn_kwargs['groups']) File "/usr/lib/python3.7/site-packages/portage/__init__.py", line 246, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 14] Bad address * Fetch failed for 'dev-libs/libffi-3.3-r2', Log file: * '/var/tmp/portage/dev-libs/libffi-3.3-r2/temp/build.log' >>> Failed to emerge dev-libs/libffi-3.3-r2, Log file: >>> '/var/tmp/portage/dev-libs/libffi-3.3-r2/temp/build.log' * Messages for package dev-libs/libffi-3.3-r2: * Fetch failed for 'dev-libs/libffi-3.3-r2', Log file: * '/var/tmp/portage/dev-libs/libffi-3.3-r2/temp/build.log'
Then once userfetch is bypassed: # FEATURES=-userfetch emerge -1O libffi >>> Verifying ebuild manifests * IMPORTANT: 7 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. >>> Emerging (1 of 1) dev-libs/libffi-3.3-r2::gentoo Unable to configure loopback interface: Operation not permitted >>> Downloading 'http://distfiles.gentoo.org/distfiles/cf/libffi-3.3.tar.gz' --2020-08-12 12:48:29-- http://distfiles.gentoo.org/distfiles/cf/libffi-3.3.tar.gz Resolving distfiles.gentoo.org... 2600:3404:200:237::2, 2600:3402:200:227::2, 2605:bc80:3010::134, ... Connecting to distfiles.gentoo.org|2600:3404:200:237::2|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1305466 (1.2M) [application/x-gzip] Saving to: ‘/var/cache/distfiles/libffi-3.3.tar.gz.__download__’ 0K .......... .......... .......... .......... .......... 3% 352K 3s 50K .......... .......... .......... .......... .......... 7% 868K 2s 100K .......... .......... .......... .......... .......... 11% 2.13M 2s 150K .......... .......... .......... .......... .......... 15% 807K 2s 200K .......... .......... .......... .......... .......... 19% 378K 2s 250K .......... .......... .......... .......... .......... 23% 11.5M 1s 300K .......... .......... .......... .......... .......... 27% 2.08M 1s 350K .......... .......... .......... .......... .......... 31% 3.05M 1s 400K .......... .......... .......... .......... .......... 35% 410K 1s 450K .......... .......... .......... .......... .......... 39% 116M 1s 500K .......... .......... .......... .......... .......... 43% 1.66M 1s 550K .......... .......... .......... .......... .......... 47% 796K 1s 600K .......... .......... .......... .......... .......... 50% 508K 1s 650K .......... .......... .......... .......... .......... 54% 61.2M 1s 700K .......... .......... .......... .......... .......... 58% 127M 1s 750K .......... .......... .......... .......... .......... 62% 802K 0s 800K .......... .......... .......... .......... .......... 66% 917K 0s 850K .......... .......... .......... .......... .......... 70% 974K 0s 900K .......... .......... .......... .......... .......... 74% 899K 0s 950K .......... .......... .......... .......... .......... 78% 1.68M 0s 1000K .......... .......... .......... .......... .......... 82% 965K 0s 1050K .......... .......... .......... .......... .......... 86% 962K 0s 1100K .......... .......... .......... .......... .......... 90% 905K 0s 1150K .......... .......... .......... .......... .......... 94% 976K 0s 1200K .......... .......... .......... .......... .......... 98% 784K 0s 1250K .......... .......... .... 100% 3.45M=1.3s 2020-08-12 12:48:30 (974 KB/s) - ‘/var/cache/distfiles/libffi-3.3.tar.gz.__download__’ saved [1305466/1305466] * libffi-3.3.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] Unable to configure loopback interface: Operation not permitted Traceback (most recent call last): File "/usr/lib/portage/python3.7/pid-ns-init", line 127, in <module> sys.exit(main(sys.argv)) File "/usr/lib/portage/python3.7/pid-ns-init", line 91, in main proc = subprocess.Popen(args, executable=binary, **popen_kwargs) File "/usr/lib/python3.7/subprocess.py", line 800, in __init__ restore_signals, start_new_session) File "/usr/lib/python3.7/subprocess.py", line 1552, in _execute_child raise child_exception_type(err_msg) subprocess.SubprocessError: Exception occurred in preexec_fn. * The ebuild phase 'unpack' 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 dev-libs/libffi-3.3-r2, Log file: >>> '/var/tmp/portage/dev-libs/libffi-3.3-r2/temp/build.log' * Messages for package dev-libs/libffi-3.3-r2: * The ebuild phase 'unpack' 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.
Then once pid-sandbox is bypassed: # FEATURES="-userfetch -pid-sandbox" emerge -1O libffi >>> Verifying ebuild manifests * IMPORTANT: 7 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. >>> Emerging (1 of 1) dev-libs/libffi-3.3-r2::gentoo Unable to configure loopback interface: Operation not permitted * libffi-3.3.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] Unable to configure loopback interface: Operation not permitted [Errno 14] Bad address: /usr/bin/sandbox /usr/lib/portage/python3.7/ebuild.sh unpack Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/portage/process.py", line 391, in spawn unshare_flags, cgroup) File "/usr/lib/python3.7/site-packages/portage/process.py", line 740, in _exec os.setgroups(groups) File "/usr/lib/python3.7/site-packages/portage/__init__.py", line 246, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 14] Bad address * The ebuild phase 'unpack' 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 dev-libs/libffi-3.3-r2, Log file: >>> '/var/tmp/portage/dev-libs/libffi-3.3-r2/temp/build.log' * Messages for package dev-libs/libffi-3.3-r2: * The ebuild phase 'unpack' 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.
Finally with userpriv also disabled, it succeeds. A patch has been submitted upstream here: https://sourceware.org/pipermail/libc-alpha/attachments/20200727/f3004da6/attachment.bin This is the patch debian is applying, and it appears to work here.
https://sourceware.org/PR26248
I've received this problem in i686, arm, mips, etc any 32 bit systems. You can just try to emerge any package and you will receive the following folder (/usr/i686-pc-linux-gnu/tmp/portage/dev-lang/python-3.7.8-r2) structure: portage portage 4096 Aug 25 13:46 homedir root root 4096 Aug 25 13:47 image portage portage 4096 Aug 25 13:47 temp portage portage 4096 Aug 25 13:46 work Portage is running as portage user and not able to copy files to image folder. Please mask =sys-libs/glibc-2.31-r6 for 32 bit systems.
Upstream bug says it only afects x32-abi and probably other ABIs where sizeof(long) != sizeof(void*), like mips n32 ABI. arm and i686 should not be affected.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3acb1697fbdb842072d5573ff68112486f59e5ad commit 3acb1697fbdb842072d5573ff68112486f59e5ad Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2020-09-05 02:43:04 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2020-09-05 02:46:00 +0000 sys-libs/glibc: 2.31 revbump, patchlevel 9 Untested, no keywords for now Bug: https://bugs.gentoo.org/736904 Package-Manager: Portage-3.0.4, Repoman-2.3.23 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-libs/glibc/Manifest | 1 + sys-libs/glibc/glibc-2.31-r7.ebuild | 1495 +++++++++++++++++++++++++++++++++++ 2 files changed, 1496 insertions(+)
I am reproducing this issue while cross emerging python (with glibc 2.31-r6), for example "i686-unknown-linux-gnu-emerge dev-lang/python:3.7": running install_lib creating /usr/i686-unknown-linux-gnu/tmp/portage/dev-lang/python-3.7.8-r2/image/usr/lib/python3.7/lib-dynload copying build/lib.linux-i686-3.7/_pickle.cpython-37m-i386-linux-gnu.so -> /usr/i686-unknown-linux-gnu/tmp/portage/dev-lang/python-3.7.8-r2/image/usr/lib/python3.7/lib-dynload error: [Errno 1] Operation not permitted Creating directory /usr/lib/python3.7/logging make: *** [Makefile:1549: sharedinstall] Error 1 Glibc 2.30-r9 and musl 1.1.24, 1.2.1 works fine. I will try to check updated glibc 2.31-r7 and 2.32.
Unfortunately both glibc 2.31-r7 and glibc 2.32-r1 fails in my case. Cpython is not able to copy /usr/i686-unknown-linux-gnu/tmp/portage/dev-lang/python-3.7.8-r2/work/Python-3.7.8/build/lib.linux-i686-3.7/_pickle.cpython-37m-i386-linux-gnu.so into /usr/i686-unknown-linux-gnu/tmp/portage/dev-lang/python-3.7.8-r2/image/usr/lib/python3.7/lib-dynload/ during installation. I will try to investigate this issue.
python -c "from distutils import file_util; file_util.copy_file('src', 'dst')" Everything is fine. target-python -c "from distutils import file_util; file_util.copy_file('src', 'dst')" Fails with: Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/i686-unknown-linux-gnu/usr/lib/python3.7/distutils/file_util.py", line 158, in copy_file os.utime(dst, (st[ST_ATIME], st[ST_MTIME])) PermissionError: [Errno 1] Operation not permitted Where target-python is the following: /usr/i686-unknown-linux-gnu/lib/ld-2.32.so --library-path "/usr/i686-unknown-linux-gnu/lib:/usr/i686-unknown-linux-gnu/usr/lib:/usr/i686-unknown-linux-gnu/usr/lib/gcc/i686-unknown-linux-gnu/9.3.0" /usr/i686-unknown-linux-gnu/usr/bin/python3.7 "$@" The difference between straces is the following: 1 Regular python - utimensat(AT_FDCWD, "file.so", [{tv_sec=1599427392, tv_nsec=0} /* 2020-09-06T21:23:12+0000 */, {tv_sec=1599427392, tv_nsec=0} /* 2020-09-06T21:23:12+0000 */], 0) = 0 2 Target python loaded using i686 ld.so - utimensat_time64(AT_FDCWD, "/usr/i686-unknown-linux-gnu/tmp/portage/dev-lang/python-3.7.8-r2/image/usr/lib/python3.7/lib-dynload/_pickle.cpython-37m-i386-linux-gnu.so", [{tv_sec=1599427392, tv_nsec=0} /* 2020-09-06T21:23:12+0000 */, {tv_sec=1599427392, tv_nsec=0} /* 2020-09-06T21:23:12+0000 */], 0) = -1 EPERM (Operation not permitted) So the issue is the new glibc utimensat code appeared in 2.31 version. It assumes somehow that it should use utimensat_time64 and uses it in wrong way. You can just compare this code: 2.30 version https://github.com/bminor/glibc/blob/glibc-2.30/sysdeps/unix/sysv/linux/utimensat.c 2.31 version https://github.com/bminor/glibc/blob/glibc-2.31/sysdeps/unix/sysv/linux/utimensat.c
I am sorry, my case is missing "utimensat_time64" syscall in buildah/docker container manager seccomp whitelist. Please be aware that usage of new glibc v2.31+ inside container requires updating (app-emulation/containerd, app-emulation/docker) everything that depends on libseccomp and maintains its own seccomp whitelist.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=af0c4db7d53eafd2a797c082f85662c945ad01de commit af0c4db7d53eafd2a797c082f85662c945ad01de Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2020-09-25 19:42:22 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2020-09-25 19:42:40 +0000 sys-libs/glibc: Re-keyword 2.31 patchlevel 9 This contains the following fixes: * Rewrite iconv option parsing [BZ #19519] * powerpc: Fix incorrect cache line size load in memset (bug 26332) * nptl: Zero-extend arguments to SETXID syscalls [BZ #26248] * Disable warnings due to deprecated libselinux symbols used by nss and nscd Bug: https://bugs.gentoo.org/736904 Bug: https://bugs.gentoo.org/611344 Package-Manager: Portage-3.0.4, Repoman-3.0.1 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-libs/glibc/glibc-2.31-r7.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
2.32 is stable on amd64.
