I get the following error, when I try to emerge rust: tar: eselect-rust-20200419: Cannot mkdir: Value too large for defined data type I had to set the PORTAGE_TMPDIR environment variable, because /var/tmp is too small for building rust. I found some reports on mkdir returning EOVERFLOW. But using strike, I found, that the error message is written to stdout without invoking the mkdir system call. :-O I though, this might be due to the sandbox used for building. When I set SANDBOX_DEBUG=1, I get the following message prior to seeing this error: * EARLY FAIL: mkdirat(eselect-rust-20200419) @ canonicalize: Value too large for defined data type Unfortunately it doesn't really help. :-( Here is the problem: # PORTAGE_TMPDIR=/video/portage.tmp emerge --ask rust These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-eselect/eselect-rust-20200419 [ebuild N ] dev-lang/rust-1.47.0-r2 USE="-clippy -debug (-doc) (-libressl) (-miri) (-nightly) (-parallel-compiler) -rls -rustfmt (-system-bootstrap) (-system-llvm) -test -wasm" CPU_FLAGS_X86="sse2" LLVM_TARGETS="BPF (X86) -AArch64 -AMDGPU -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Running pre-merge checks for dev-lang/rust-1.47.0-r2 * Checking for at least 10752 MiB disk space at "/video/portage.tmp/portage/dev-lang/rust-1.47.0-r2/temp" ... [ ok ] Unable to unshare: EINVAL (for FEATURES="ipc-sandbox network-sandbox pid-sandbox") >>> Emerging (1 of 2) app-eselect/eselect-rust-20200419::gentoo Unable to unshare: EINVAL (for FEATURES="ipc-sandbox network-sandbox pid-sandbox") * eselect-rust-20200419.tar.bz2 BLAKE2B SHA512 size ;-) ... [ ok ] Unable to unshare: EINVAL (for FEATURES="ipc-sandbox network-sandbox pid-sandbox") >>> Unpacking source... >>> Unpacking eselect-rust-20200419.tar.bz2 to /video/portage.tmp/portage/app-eselect/eselect-rust-20200419/work >>> Source unpacked in /video/portage.tmp/portage/app-eselect/eselect-rust-20200419/work Unable to unshare: EINVAL (for FEATURES="ipc-sandbox network-sandbox pid-sandbox") >>> Preparing source in /video/portage.tmp/portage/app-eselect/eselect-rust-20200419/work/eselect-rust-20200419 ... >>> Source prepared. Unable to unshare: EINVAL (for FEATURES="ipc-sandbox network-sandbox pid-sandbox") >>> Configuring source in /video/portage.tmp/portage/app-eselect/eselect-rust-20200419/work/eselect-rust-20200419 ... * /var/tmp/portage/sys-apps/sandbox-2.20/work/sandbox-2.20/libsandbox/libsandbox.c:check_syscall():983: failure (Value too large for defined data type): * ISE: access_rd(./configure) abs_path: (null) res_path: /video/portage.tmp/portage/app-eselect/eselect-rust-20200419/work/eselect-rust-20200419/configure errno=75: Value too large for defined data type /usr/lib/libsandbox.so(+0xc197)[0xb7709197] /usr/lib/libsandbox.so(+0xc233)[0xb7709233] /usr/lib/libsandbox.so(+0x4283)[0xb7701283] /usr/lib/libsandbox.so(+0x4395)[0xb7701395] /usr/lib/libsandbox.so(faccessat+0x5e)[0xb770539e] /bin/bash(+0x9d39a)[0x8015939a] /bin/bash(+0x5d881)[0x80119881] /bin/bash(+0x2098d)[0x800dc98d] /bin/bash(+0x2359c)[0x800df59c] /bin/bash(+0x2689c)[0x800e289c] /proc/31920/cmdline: /bin/bash /usr/lib/portage/python3.8/ebuild.sh configure /usr/lib/portage/python3.8/ebuild.sh: line 764: 31920 Aborted (core dumped) ( if [[ -n ${PORTAGE_PIPE_FD} ]]; then eval "exec ${PORTAGE_PIPE_FD}>&-"; unset PORTAGE_PIPE_FD; fi; __ebuild_main ${EBUILD_SH_ARGS}; exit 0 ) * The ebuild phase 'configure' 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-eselect/eselect-rust-20200419, Log file: >>> '/video/portage.tmp/portage/app-eselect/eselect-rust-20200419/temp/build.log' * Messages for package app-eselect/eselect-rust-20200419: * The ebuild phase 'configure' 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. Task was destroyed but it is pending! task: <Task pending name='Task-6' coro=<PipeLogger._io_loop() running at /usr/lib/python3.8/site-packages/portage/util/_async/PipeLogger.py:78> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0xb4650418>()]> cb=[PipeLogger._io_loop_done()]> Task was destroyed but it is pending! task: <Task pending name='Task-5' coro=<BuildLogger._main() running at /usr/lib/python3.8/site-packages/portage/util/_async/BuildLogger.py:86> wait_for=<Future pending cb=[AsynchronousTask.async_wait.<locals>.<lambda>() at /usr/lib/python3.8/site-packages/_emerge/AsynchronousTask.py:42, <TaskWakeupMethWrapper object at 0xb46501d8>()]> cb=[BuildLogger._main_exit()]> Task was destroyed but it is pending! task: <Task pending name='Task-4' coro=<PipeLogger._io_loop() running at /usr/lib/python3.8/site-packages/portage/util/_async/PipeLogger.py:78> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0xb4650118>()]> cb=[PipeLogger._io_loop_done()]> # I get following error for ages, but it never was a problem: Unable to unshare: EINVAL (for FEATURES="ipc-sandbox network-sandbox pid-sandbox") I just found, that there also is a core dump of bash. gdb shows the following back-trace: Core was generated by `/bin/bash /usr/lib/portage/python3.8/ebuild.sh configure'. Program terminated with signal SIGABRT, Aborted. #0 0xb772dc01 in __kernel_vsyscall () (gdb) bt #0 0xb772dc01 in __kernel_vsyscall () #1 0xb74d49b2 in raise () from /lib/libc.so.6 #2 0xb74bb313 in abort () from /lib/libc.so.6 #3 0xb770923d in __sb_ebort ( file=file@entry=0xb770c02c "/var/tmp/portage/sys-apps/sandbox-2.20/work/sandbox-2.20/libsandbox/libsandbox.c", func=func@entry=0xb770c4b0 <__func__.2> "check_syscall", line_num=line_num@entry=983, format=format@entry=0xb770c394 "ISE: %s(%s)\n\tabs_path: %s\n\tres_path: %s\n\terrno=%i: %s\n") at /usr/src/debug/sys-apps/sandbox-2.20/sandbox-2.20/libsbutil/sb_efuncs.c:138 #4 0xb7701283 in check_syscall (sbcontext=0xb77181a0 <sbcontext>, flags=1, file=0x807f64d0 "./configure", func=0xb770c3f7 "access_rd", sb_nr=-1) at /usr/src/debug/sys-apps/sandbox-2.20/sandbox-2.20/libsandbox/libsandbox.c:983 #5 before_syscall (dirfd=<optimized out>, sb_nr=-1, func=0xb770c3f7 "access_rd", file=0x807f64d0 "./configure", flags=1) at /usr/src/debug/sys-apps/sandbox-2.20/sandbox-2.20/libsandbox/libsandbox.c:1069 #6 0xb7701395 in before_syscall_access (dirfd=dirfd@entry=-100, sb_nr=<optimized out>, sb_nr@entry=25, func=func@entry=0xb770cc41 "faccessat", file=file@entry=0x807f64d0 "./configure", flags=flags@entry=1) at /usr/src/debug/sys-apps/sandbox-2.20/sandbox-2.20/libsandbox/libsandbox.c:1091 #7 0xb770539e in faccessat_DEFAULT (dirfd=-100, pathname=0x807f64d0 "./configure", mode=1, flags=512) at /usr/src/debug/sys-apps/sandbox-2.20/sandbox-2.20/libsandbox/wrapper-funcs/__wrapper_simple.c:52 #8 0x8015939a in ?? () #9 0x80119881 in ?? () #10 0x800dc98d in ?? () #11 0x800df59c in ?? () #12 0x800e289c in ?? () #13 0x800e08ff in ?? () #14 0x800df8e9 in ?? () #15 0x800e40e1 in ?? () #16 0x800e2776 in ?? () #17 0x800df8e9 in ?? () #18 0x800e40e1 in ?? () ... When I try a 2nd time, I get a core dump of tar: (gdb) bt #0 0xb7778c01 in __kernel_vsyscall () #1 0xb75929b2 in raise () from /lib/libc.so.6 #2 0xb7579313 in abort () from /lib/libc.so.6 #3 0xb775423d in __sb_ebort ( file=file@entry=0xb775702c "/var/tmp/portage/sys-apps/sandbox-2.20/work/sandbox-2.20/libsandbox/libsandbox.c", func=func@entry=0xb77574b0 <__func__.2> "check_syscall", line_num=line_num@entry=983, format=format@entry=0xb7757394 "ISE: %s(%s)\n\tabs_path: %s\n\tres_path: %s\n\terrno=%i: %s\n") at /usr/src/debug/sys-apps/sandbox-2.20/sandbox-2.20/libsbutil/sb_efuncs.c:138 #4 0xb774c283 in check_syscall (sbcontext=0xb77631a0 <sbcontext>, flags=526785, file=0x80c595d0 "eselect-rust-20200419/aclocal.m4", func=0xb775740b "open_wr", sb_nr=-4) at /usr/src/debug/sys-apps/sandbox-2.20/sandbox-2.20/libsandbox/libsandbox.c:983 #5 before_syscall (dirfd=<optimized out>, sb_nr=-4, func=0xb775740b "open_wr", file=0x80c595d0 "eselect-rust-20200419/aclocal.m4", flags=526785) at /usr/src/debug/sys-apps/sandbox-2.20/sandbox-2.20/libsandbox/libsandbox.c:1069 #6 0xb774c3f5 in before_syscall_open_int (dirfd=dirfd@entry=-100, sb_nr=<optimized out>, sb_nr@entry=38, func=func@entry=0xb7757ca5 "openat64", file=file@entry=0x80c595d0 "eselect-rust-20200419/aclocal.m4", flags=flags@entry=526785) at /usr/src/debug/sys-apps/sandbox-2.20/sandbox-2.20/libsandbox/libsandbox.c:1101 #7 0xb77535e1 in openat64_DEFAULT (dirfd=-100, pathname=0x80c595d0 "eselect-rust-20200419/aclocal.m4", flags=526785) at /usr/src/debug/sys-apps/sandbox-2.20/sandbox-2.20/libsandbox/wrapper-funcs/__wrapper_simple.c:52 #8 0x8005b437 in ?? () #9 0x8005c532 in ?? () #10 0x80068ea2 in ?? () #11 0x80049f43 in ?? () #12 0xb757af4c in __libc_start_main () from /lib/libc.so.6 #13 0x8004a471 in ?? () (gdb) Ok, not only the process to dup core changes with each run, also the error message is different. I have no idea, what to do. Thasnks to anybody looking at this problem. 73, Mario
# emerge --info Portage 3.0.17 (python 3.8.8-final-0, default/linux/x86/17.0, gcc-10.2.0, glibc-2.32-r7, 4.4.39-gentoo i686) ================================================================= System uname: Linux-4.4.39-gentoo-i686-Intel-R-_Celeron-R-_CPU_G1610T_@_2.30GHz-with-glibc2.1.3 KiB Mem: 16596672 total, 8933268 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Tue, 20 Apr 2021 02:00:01 +0000 Head commit of repository gentoo: 5b6cc80b2ba5a2ee76cd203379dedb0a1dbe6aae sh bash 5.0_p18 ld GNU ld (Gentoo 2.35.2 p1) 2.35.2 app-shells/bash: 5.0_p18::gentoo dev-lang/perl: 5.30.3::gentoo dev-lang/python: 2.7.18_p8::gentoo, 3.8.8_p1::gentoo, 3.9.2_p1::gentoo dev-util/cmake: 3.18.5::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.7::gentoo sys-apps/openrc: 0.42.1-r1::gentoo sys-apps/sandbox: 2.20::gentoo sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r5::gentoo sys-devel/automake: 1.15.1-r2::gentoo, 1.16.2-r1::gentoo sys-devel/binutils: 2.35.2::gentoo sys-devel/gcc: 10.2.0-r5::gentoo sys-devel/gcc-config: 2.4::gentoo sys-devel/libtool: 2.4.6-r6::gentoo sys-devel/make: 4.3::gentoo sys-kernel/linux-headers: 5.10::gentoo (virtual/os-headers) sys-libs/glibc: 2.32-r7::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 sync-rsync-verify-jobs: 1 sync-rsync-verify-max-age: 24 sync-rsync-extra-opts: --quiet sync-rsync-verify-metamanifest: yes x-portage location: /usr/local/portage masters: gentoo priority: 0 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php7.4/ext-active/ /etc/php/cgi-php7.4/ext-active/ /etc/php/cli-php7.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -march=i686 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -march=i686 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="de en" MAKEOPTS="-j2" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="-6" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="accessibility acl berkdb bzip2 cli crypt dri fortran gdbm gif iconv imap ipv6 libglvnd libtirpc mbox ncurses nls nptl openmp pam pcre php phpdbg readline sasl seccomp split-usr ssl tcpd tty-helpers unicode x86 xattr zlib" ABI_X86="32" ADA_TARGET="gnat_2018" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authn_file auth_basic authz_core authz_host authz_user deflate dir filter headers log_config mime rewrite php proxy proxy_http mod_headers alias socache_shmcb" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2 sse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" L10N="de en" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="BPF X86" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_8" PYTHON_TARGETS="python3_8" RUBY_TARGETS="ruby26" USERLAND="GNU" VIDEO_CARDS="vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, RUSTFLAGS #
Are you using XFS? I'm seeing a few similar reports on 32bit with XFS, not that I'm familiar with the issue. Like bug #583282
Yes, I am using XFS.
Here is the strike output of tar prior to emitting the error message: 911 read(0, <unfinished ...> 911 <... read resumed>"eselect-rust-20200419/\0\0\0\0\0\0\0\0\0\0"..., 10240) = 4096 911 read(0, <unfinished ...> 911 <... read resumed>"$srcdir/../..'.\n#\n# Of course, A"..., 6144) = 4096 911 read(0, <unfinished ...> 911 <... read resumed>"bsolete],\n [$0: two-"..., 2048) = 2048 911 fstat64(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 911 getcwd("/video/portage.tmp/portage/app-eselect/eselect-rust-20200419/work", 8192) = 66 911 lstat64("/video/portage.tmp/portage/app-eselect/eselect-rust-20200419/work", {st_mode=S_IFDIR|0700, st_size=6, ...}) = 0 911 getcwd("/video/portage.tmp/portage/app-eselect/eselect-rust-20200419/work", 8190) = 66 911 lstat64("/video/portage.tmp/portage/app-eselect/eselect-rust-20200419/work", {st_mode=S_IFDIR|0700, st_size=6, ...}) = 0 911 write(2, "tar: ", 5) = 5 911 write(2, "eselect-rust-20200419: Cannot mk"..., 35) = 35 911 write(2, ": Value too large for defined da"..., 39) = 39 911 write(2, "\n", 1) = 1 It seems, tar is reading the uncompressed archive on stdin and has read a record for a new file or directory, provably a directory. It tries to mkdir, but the sandbox intercepts and returns an error. I am not sure, wether the getcwd() and lstat64() calls are from tar or from the sandbox. When I look into the core dumps I see, that the process abroted in check_syscall() within sandbox-2.20/libsandbox/libsandbox.c: /* If we get here, something bad happened */ sb_ebort("ISE: %s(%s)\n" "\tabs_path: %s\n" "\tres_path: %s\n" "\terrno=%i: %s\n", func, file, absolute_path, resolved_path, errno, strerror(errno)); Here ist the error message in the build output: * /var/tmp/portage/sys-apps/sandbox-2.20/work/sandbox-2.20/libsandbox/libsandbox.c:check_syscall():983: failure (Value too large for defined data type): * ISE: open_wr(eselect-rust-20200419/aclocal.m4) abs_path: (null) res_path: (null) errno=75: Value too large for defined data type And according to this message, this seems to be the road to hell: absolute_path = resolve_path(file, 0); /* Do not bother dereferencing symlinks when we are using a function that * itself does not dereference. This speeds things up and avoids updating * the atime implicitly. #415475 */ if (symlink_func(sb_nr, flags, absolute_path)) resolved_path = absolute_path; else resolved_path = resolve_path(file, 1); if (!absolute_path || !resolved_path) goto error; resolve_path() seems to have returned NULL in both calls. But maybe, these are two errors: first, mkdir(eselect-rust-20200419) is denied (for some unknown reason), and then, when trying to write eselect-rust-20200419/aclocal.m4, the sandbox is unable to resolve the path (due the the missing directory), but is unable to handle this situation.
resolve_path() calls canonicalize(),which calls erealpath(). erealpath() calls egetcwd() and lstat(), if the name does not start with a slash. This probably is the origin of the two getcwd() and lstat64() calls seen with strace. Ok, egetcwd() calls sb_unwrapped_getcwd() and lstat(), too. But I still am not able to find any code setting errno=75 (EOVERFLOW).
The man page of lstat64() states on EOVERFLOW: EOVERFLOW pathname or fd refers to a file whose size, inode number, or number of blocks cannot be represented in, respectively, the types off_t, ino_t, or blkcnt_t. This error can occur when, for example, an application compiled on a 32-bit platform without -D_FILE_OFFSET_BITS=64 calls stat() on a file whose size exceeds (1<<31)-1 bytes. According to this statement, it should help to add -D_FILE_OFFSET_BITS=64 when compiling the sandbox.
(In reply to Mario Klebsch from comment #3) > Yes, I am using XFS. I guess it's a duplicate of the sandbox bug then, best continue there. *** This bug has been marked as a duplicate of bug 583282 ***
