After upgrading from glibc-2.19-r1 to glibc-2.20-r2 (which is stable) I can no longer "su" or ie. start arpwatch. Anything that issues setgid privilege stuff is going to die. No login possible. Reproducible: Always Steps to Reproduce: 1. Install glibc-2.20-r2 2. issue "su -" from a logged in user _or_ 3. login on a tty Actual Results: No privilege stuff longer works, no one can login. Expected Results: Let me login again? :) root@marc:/etc/pam.d # objdump -T /lib/libc-2.20.so | grep setgid 000b7e40 w DF .text 00000070 GLIBC_2.0 setgid
I have these in my logs as well: Apr 22 19:10:47 marc su[19160]: Successful su for marc by root Apr 22 19:10:47 marc su[19160]: + /dev/pts/0 root:marc Apr 22 19:10:47 marc su[19160]: bad group ID `407' for user `marc': Function not implemented Apr 22 18:15:24 marc login[16158]: pam_unix(login:session): session opened for user marc by LOGIN(uid=0) Apr 22 18:15:24 marc login[16158]: pam_mail(login:session): pam_modutil_drop_priv: setgroups failed: Function not implemented Apr 22 18:15:24 marc login[16158]: bad group ID `407' for user `marc': Function not implemented
OK, what did I do after my box was somehow halted (screen on, nothing moved any more): - boot into Knoppix - pushed my weekly system backup HDD in my wife laptop - ssh'ed over the old 2.19 files from /lib onto my SSD /lib folder - copied all *2.19.so files into their *2.20.so counterparts - rebooted - logged in I will habe to copy all other 'obj' as shown in /var/db/pkg/sys-libs/glibc-2.20-r2/CONTENTS into their respective counterparts to have the headers and stuff match the binaries. This, however, is just a dirty dirty workaround that I use to bypass the cannot-login-thing. Currently my machine works like normal but I won't install anything new until this issue is resolved. Maybe I could that I just turned off the gold linker and switched over to ld.bfd again before I compiled glibc as ./configure stated 'ld was too old'.
This appears to have borked my system. I can't emerge anything: >>> Emerging (1 of 1) dev-lang/python-2.7.9-r1::gentoo * Python-2.7.9.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * python-gentoo-patches-2.7.9-0.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] [Errno 38] Function not implemented: /usr/bin/sandbox /usr/lib/portage/python2.7/ebuild.sh unpack Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/portage/process.py", line 317, in spawn unshare_net, unshare_ipc, cgroup) File "/usr/lib/python2.7/site-packages/portage/process.py", line 503, in _exec os.setgid(int(gid)) File "/usr/lib/python2.7/site-packages/portage/__init__.py", line 259, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 38] Function not implemented * 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-lang/python-2.7.9-r1, Log file:
Well, for all the trashing, this is legit - I've just got a similar result on my x86 machine. Back before I've rebooted, I started getting 'setresuid(0, -1, -1) function not implemented' upon 'sudo'. It seems the whole set of those functions got broken. I can still login if I boot into single user mode. @reporter: could you post your system specs (at least in so far you can retrieve them) ?
please attach the full build log as well as emerge info
According to http://upstream-tracker.org/versions/glibc.html there's minimal (effectively even more minimal) API change so the copy 2.19 binaries into the 2.20 files could work for you, too, until this is resolved. I think I used gcc 4.8.3 at the time I compiled the package.
Created attachment 402022 [details] emerge --info
(In reply to Rafał Mużyło from comment #4) > Well, for all the trashing, this is legit - I've just got a similar result > on my x86 machine. > > Back before I've rebooted, I started getting 'setresuid(0, -1, -1) function > not implemented' upon 'sudo'. > It seems the whole set of those functions got broken. > > I can still login if I boot into single user mode. > > > @reporter: could you post your system specs (at least in so far you can > retrieve them) ? Hi Rafał, what specs besides emerge --info do you mean? I can provide anything if you just give me more detail. Thanks, Marc
Created attachment 402024 [details] emerge --info from one of my x86 affected machines. This is after I downgraded glibc back to 2.19 and emerge -e system, so a few packages got updated (including gcc and binutils which were at 4.8.3 and 2.24-r3. My x86_64 machines don't seem to be affected. I've updated binutils now due to bug 547394.
(In reply to Peter Fox from comment #9) > Created attachment 402024 [details] > emerge --info from one of my x86 affected machines. > > This is after I downgraded glibc back to 2.19 and emerge -e system, so a few > packages got updated (including gcc and binutils which were at 4.8.3 and > 2.24-r3. My x86_64 machines don't seem to be affected. > > I've updated binutils now due to bug 547394. Hi Peter, how did you manage to downgrade glibc? I think the ebuild does not allow that. Did you downgrade 'manually' somehow? Thanks, Marc
(In reply to Marc Burkhardt from comment #10) > (In reply to Peter Fox from comment #9) > > Created attachment 402024 [details] > > emerge --info from one of my x86 affected machines. > > > > This is after I downgraded glibc back to 2.19 and emerge -e system, so a few > > packages got updated (including gcc and binutils which were at 4.8.3 and > > 2.24-r3. My x86_64 machines don't seem to be affected. > > > > I've updated binutils now due to bug 547394. > > Hi Peter, > > how did you manage to downgrade glibc? I think the ebuild does not allow > that. Did you downgrade 'manually' somehow? > > Thanks, > Marc ebuild doesn't - that would be not that hard to bypass, if not for that glibc is so broken that emerge is prevented even with the bypas in place. I ended up needing to untar tinderbox tarball. Anyway, this is a well documented problem. On the upstream wiki page for 2.20, section 3.1.23 it's noted that gcc 4.8.3 miscompiles glibc 2.20. The linked bug supposedly affects 4.91 too. emerging and switching to 4.8.4 allowed glibc 2.20 to be built correctly.
Hi Rafał, I cannot directly understand the set{g,u}id stuff being related to a compiler bug in the notes mentioned in 3.1.23 as it says it's for x86_64. I have a 32bit installation without even the ability to compile 64bit code. I, however, have the gcc 4.8.4 compiler in place and could try building again with it later today.
(In reply to Marc Burkhardt from comment #12) > Hi Rafał, > > I cannot directly understand the set{g,u}id stuff being related to a > compiler bug in the notes mentioned in 3.1.23 as it says it's for x86_64. I > have a 32bit installation without even the ability to compile 64bit code. > > I, however, have the gcc 4.8.4 compiler in place and could try building > again with it later today. Ah, you meant 3.1.22 (twenty two) ?
If we're really sure that gcc 4.8.3 is to blame I would suggest to immediately prevent glibc to be built with the compiler. I cannot test if it's really the compiler as both 4.8.3 and 4.8.4 slotted in 4.8 and I don't have the time to downgrade, test and upgrade again right now.
In answer to comment 10, I used https://forums.gentoo.org/viewtopic-t-845000.html as a reference (steps 3-5), but then had to hack /usr/lib/python2.7/site-packages/portage/process.py to comment out the os.set*() calls on lines 503 and following. To save searching, the glibc wiki for 2.20 is at https://sourceware.org/glibc/wiki/Release/2.20, and it does appear 3.1.22 is the relevant comment, though that appears to be cross compiling to x86 from x86_64. I shall try upgrading glibc on one of my x86 machines now that gcc has been updated.
(In reply to Marc Burkhardt from comment #13) > (In reply to Marc Burkhardt from comment #12) > > I cannot directly understand the set{g,u}id stuff being related to a > > compiler bug in the notes mentioned in 3.1.23 as it says it's for x86_64. I > > have a 32bit installation without even the ability to compile 64bit code. > > Ah, you meant 3.1.22 (twenty two) ? ...:shrug: typos happen...
(In reply to Peter Fox from comment #15) > To save searching, the glibc wiki for 2.20 is at > https://sourceware.org/glibc/wiki/Release/2.20, and it does appear 3.1.22 is > the relevant comment, though that appears to be cross compiling to x86 from > x86_64. > In that light, I wonder if 32bit build on amd64 is affected too...
Building glibc-2.20 using gcc 4.8.4 seems to be ok: # python Python 2.7.9 (default, Apr 26 2015, 00:55:33) [GCC 4.8.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgid(0) >>>
Created attachment 402074 [details] emerge --info for glibc-2.20 built with gcc4.8.4 etc and ok.
GCCs which could be affected: 4.5.0 - 4.8.3, 4.9.0, 4.9.1 GCC 4.8.3 broke my system. No login. No simple glibc rebuild on live system possible. GCC 4.6.3 may be ok. Recompiling glibc-2.20-r2 using -fno-var-tracking flag should resolve the problem. More info: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904
bug 519172 tracked the original issue. we backported the fix to 4.9.1 only though. i can update glibc to reject 4.8.[0-3] and 4.9.0 until (if) we backport the fix there too.
should be all set now in the tree; thanks for the report! Commit message: Reject gcc-4.8.[0-3] and gcc-4.9.0 due to miscompilation bugs http://sources.gentoo.org/sys-libs/glibc/glibc-2.20-r2.ebuild?r1=1.7&r2=1.8 http://sources.gentoo.org/sys-libs/glibc/glibc-2.21.ebuild?r1=1.2&r2=1.3
>>> Emerging (3 of 53) sys-libs/glibc-2.20-r2::gentoo * glibc-2.20.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * glibc-2.20-patches-4.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] make -j2 -s glibc-test make -j2 -s glibc-test qemu: Unsupported syscall: 1000 >>> Unpacking source... * Checking gcc for __thread support ... [ ok ] * Checking kernel version (3.18.11 >= 2.6.32) ... [ ok ] * Checking linux-headers version (3.18.0 >= 2.6.32) ... [ ok ] >>> Unpacking glibc-2.20.tar.xz to /var/tmp/portage/sys-libs/glibc-2.20-r2/work >>> Unpacking glibc-2.20-patches-4.tar.bz2 to /var/tmp/portage/sys-libs/glibc-2.20-r2/work >>> Source unpacked in /var/tmp/portage/sys-libs/glibc-2.20-r2/work >>> Preparing source in /var/tmp/portage/sys-libs/glibc-2.20-r2/work/glibc-2.20 ... * Applying Gentoo Glibc Patchset 2.20-4 ... * 00_all_0001-disable-ldconfig-during-install.patch ... [ ok ] * 00_all_0002-workaround-crash-when-handling-signals-in-static-PIE.patch ... [ ok ] * 00_all_0003-make-fortify-logic-checks-less-angry.patch ... [ ok ] * 00_all_0004-Fix-localedef-segfault-when-run-under-exec-shield-Pa.patch ... [ ok ] * 00_all_0005-reload-etc-resolv.conf-when-it-has-changed.patch ... [ ok ] * 00_all_0006-nptl-support-thread-stacks-that-grow-up.patch ... [ ok ] * 00_all_0007-rtld-do-not-ignore-arch-specific-CFLAGS.patch ... [ ok ] * 00_all_0008-nptl-handle-EAGAIN-with-some-futex-operations.patch ... [ ok ] * 00_all_0009-gentoo-support-running-tests-under-sandbox.patch ... [ ok ] * 00_all_0010-gentoo-disable-building-in-timezone-subdir.patch ... [ ok ] * 00_all_0011-arm-fix-PIC-vs-SHARED-typos.patch ... [ ok ] * 00_all_0012-hppa-name-setjmp-union.patch ... [ ok ] * 00_all_0013-hppa-fix-build-problems-with-atomic-code.patch ... [ ok ] * 00_all_0014-hppa-fix-bug-in-floating-point-exception-support.patch ... [ ok ] * 00_all_0015-hppa-fix-pthread-spinlock.patch ... [ ok ] * 00_all_0016-hppa-fix-__O_SYNC-to-match-the-kernel.patch ... [ ok ] * 00_all_0017-disable-PIE-when-checking-for-PIC-default.patch ... [ ok ] * 00_all_0018-Update-Russian-translation.patch ... [ ok ] * 00_all_0019-Add-new-Linux-3.16-constants-to-netinet-udp.h.patch ... [ ok ] * 00_all_0020-Handle-zero-prefix-length-in-getifaddrs-BZ-17371.patch ... [ ok ] * 00_all_0021-Revert-to-defining-__extern_inline-only-for-gcc-4.3-.patch ... [ ok ] * 00_all_0022-Fix-memory-leak-in-libio-wfileops.c-do_ftell_wide-BZ.patch ... [ ok ] * 00_all_0023-Fix-memory-leak-in-error-path-of-do_ftell_wide-BZ-17.patch ... [ ok ] * 00_all_0024-Update-French-translation.patch ... [ ok ] * 00_all_0025-BZ-17460-Fix-buffer-overrun-in-nscd-help.patch ... [ ok ] * 00_all_0026-MIPS-Avoid-a-dangling-vfork-GLIBC_2.0-reference.patch ... [ ok ] * 00_all_0027-AArch64-End-frame-record-chain-correctly.patch ... [ ok ] * 00_all_0028-CVE-2014-7817-wordexp-fails-to-honour-WRDE_NOCMD.patch ... [ ok ] * 00_all_0029-arm-drop-EABI-check.patch ... [ ok ] * 00_all_0030-Make-__extern_always_inline-usable-on-clang-again.patch ... [ ok ] * 00_all_0031-CVE-2012-3406-Stack-overflow-in-vfprintf-BZ-16617.patch ... [ ok ] * 00_all_0032-Avoid-infinite-loop-in-nss_dns-getnetbyname-BZ-17630.patch ... [ ok ] * 00_all_0033-Move-findidx-nested-functions-to-top-level.patch ... [ ok ] * 00_all_0034-Fix-memory-handling-in-strxfrm_l-BZ-16009.patch ... [ ok ] * 00_all_0035-Use-AVX-unaligned-memcpy-only-if-AVX2-is-available.patch ... [ ok ] * 00_all_0036-CVE-2015-1472-wscanf-allocates-too-little-memory.patch ... [ ok ] * Done with patching * Using GNU config files from /usr/share/gnuconfig * Updating scripts/config.sub [ ok ] * Updating scripts/config.guess [ ok ] * You need to switch to a newer compiler; gcc-4.8.[0-3] and gcc-4.9.0 miscompile * glibc. See https://bugs.gentoo.org/547420 for details. * ERROR: sys-libs/glibc-2.20-r2::gentoo failed (prepare phase): * need to switch compilers #547420 * * Call stack: * ebuild.sh, line 93: Called src_prepare * environment, line 3170: Called eblit-run 'src_prepare' * environment, line 882: Called eblit-run-maybe 'eblit-src_prepare-post' * environment, line 886: Called eblit-src_prepare-post * environment, line 907: Called die * The specific snippet of code: * die "need to switch compilers #547420" * * If you need support, post the output of `emerge --info '=sys-libs/glibc-2.20-r2::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-libs/glibc-2.20-r2::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.20-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/glibc-2.20-r2/temp/environment'. * Working directory: '/var/tmp/portage/sys-libs/glibc-2.20-r2/work/glibc-2.20' * S: '/var/tmp/portage/sys-libs/glibc-2.20-r2/work/glibc-2.20' [I] sys-devel/gcc Available versions: (2.95.3) [M]~*2.95.3-r10^s (3.3.6) ~*3.3.6-r1^s (3.4.6) 3.4.6-r2^s (4.0.4) **4.0.4^s (4.1.2) 4.1.2^s (4.2.4) ~4.2.4-r1^s (4.3.6) 4.3.6-r1^s (4.4.7) 4.4.7^s (4.5.4) 4.5.4^s (4.6.4) 4.6.4^s (4.7) ~4.7.0^s ~4.7.1^s ~4.7.2-r1^s 4.7.3-r1^s ~4.7.4^s (4.8) ~4.8.0^s ~4.8.1-r1^s ~4.8.2^s 4.8.3^s ~4.8.4^s (4.9) ~*4.9.0^s ~*4.9.1^s ~4.9.2^s (5.1) **5.1.0^s [U] sys-libs/glibc Available versions: (2.2) 2.13-r4^s 2.14.1-r3^s 2.15-r3^s 2.16.0^s 2.17^s ~2.18-r1^s ~2.19^s 2.19-r1^s ~2.20^s ~2.20-r1^s 2.20-r2^s **2.21^s **9999^s {debug gd hardened multilib nscd profile selinux suid systemtap vanilla CROSSCOMPILE_OPTS="headers-only"} Installed versions: 2.19-r1(2.2)^s(05:03:27 25.10.2014)(-debug -gd -hardened -multilib -nscd -profile -selinux -suid -systemtap -vanilla CROSSCOMPILE_OPTS="-headers-only") Homepage: http://www.gnu.org/software/libc/libc.html Description: GNU libc6 (also called glibc2) C library Portage 2.2.18 (python 3.3.5-final-0, default/linux/arm/13.0/armv6j, gcc-4.8.3, glibc-2.19-r1, 3.18.11-gentoo armv7l) ================================================================= System uname: Linux-3.18.11-gentoo-armv7l-with-gentoo-2.2 KiB Mem: 3825352 total, 165256 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Fri, 01 May 2015 00:45:01 +0000 sh bash 4.2_p53 ld GNU ld (Gentoo 2.24 p1.4) 2.24 app-shells/bash: 4.2_p53::gentoo dev-lang/perl: 5.18.2-r2::gentoo dev-lang/python: 2.7.7::gentoo, 3.3.5-r1::gentoo dev-util/pkgconfig: 0.28-r1::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.12.4::gentoo sys-apps/sandbox: 2.6-r1::gentoo sys-devel/autoconf: 2.69::gentoo sys-devel/automake: 1.13.4::gentoo sys-devel/binutils: 2.24-r3::gentoo sys-devel/gcc: 4.8.3::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.2-r1::gentoo sys-devel/make: 4.0-r1::gentoo sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers) sys-libs/glibc: 2.19-r1::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 ACCEPT_KEYWORDS="arm" ACCEPT_LICENSE="* -@EULA" CBUILD="armv6j-hardfloat-linux-gnueabi" CFLAGS="-O2 -pipe -march=armv6j -mfpu=vfp -mfloat-abi=hard" CHOST="armv6j-hardfloat-linux-gnueabi" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=armv6j -mfpu=vfp -mfloat-abi=hard" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe -march=armv6j" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe -march=armv6j" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="ru_RU.UTF-8" LC_ALL="ru_RU.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" 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" PORTAGE_TMPDIR="/var/tmp" USE="acl alsa arm berkdb bindist bzip2 cli cracklib crypt cxx dri fortran gdbm iconv ipv6 modules ncurses nls nptl openmp pam pcre readline session ssl tcpd unicode zlib" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="exynos fbdev omap omapfb dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Working as intended then?
ugh, its nice that you prevent glibc from being emerged when the "broken" compiler is used - but perhaps when you stabilize it you should also stabilize a compiler that can work with it? right now this blocks updating my system here.
sorry forgot, AMD64 stable profile here
ok i see... the problem is that gcc should be updated first, then glibc. when i try to do it manually i get this: # emerge -pv --update sys-devel/gcc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-devel/gcc-4.8.4:4.8::gentoo [4.8.3:4.8::gentoo] USE="cxx fortran (multilib) nls nptl openmp sanitize (-altivec) (-awt) -doc (-fixed-point) -gcj -go -graphite (-hardened) (-libssp) -mudflap (-multislot) -nopie -nossp -objc -objc++ -objc-gc -regression-test -vanilla" 84.242 KiB Total: 1 package (1 upgrade), Size of downloads: 84.242 KiB !!! The following installed packages are masked: - app-emulation/emul-linux-x86-xlibs-20140508::gentoo (masked by: package.mask) /usr/portage/profiles/package.mask: # Michał Górny <mgorny@gentoo.org> (28 Mar 2015) # on behalf of gx86-multilib project <multilib@gentoo.org> # Mask emul-linux-x86 packages along with unported old versions # of reverse dependencies for removal in 60 days, bug #544876. # Please use multilib ebuilds with abi_x86_32 instead. - app-emulation/emul-linux-x86-db-20140508-r1::gentoo (masked by: package.mask) - app-emulation/emul-linux-x86-opengl-20140508::gentoo (masked by: package.mask) - app-emulation/emul-linux-x86-medialibs-20140508-r6::gentoo (masked by: package.mask) - app-emulation/emul-linux-x86-gtklibs-20140508-r3::gentoo (masked by: package.mask) - app-emulation/emul-linux-x86-soundlibs-20140508::gentoo (masked by: package.mask) - app-emulation/emul-linux-x86-baselibs-20140508-r12::gentoo (masked by: package.mask) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook.
args. i am stupid. sorry for the noise :=)
Any reason there isn't a DEPEND for this to ensure Portage orders the updates correctly?
gcc is SLOTed and there's no guarantee that having a good version installed means that version is selected
(In reply to SpanKY from comment #30) Cannot the check be done at pkg_pretend to prevent getting the failure after I though all was ready to update? :)
(In reply to Pacho Ramos from comment #31) there's probably no reason we can't move the pkg_setup checks to pkg_pretend. need to make sure there's glue in place for older EAPIs, but that should be easy.
Commit message: Relocate all pkg_setup checks to pkg_pretend http://sources.gentoo.org/sys-libs/glibc/files/eblits/pkg_pretend.eblit?r1=1.1&r2=1.2 http://sources.gentoo.org/sys-libs/glibc/files/eblits/pkg_setup.eblit?r1=1.14&r2=1.15
Thanks vapier
I just wonder if glibc-2.20 requires a gcc compiler >4.9.1 why the ebuild still only requires it to be >=4.4? And why is glibc-2.20 is bring in for update by emerge if the prerequisites are not met? Why I do not get a message before it tries to build about the dependencies?
(In reply to Daniel Savard from comment #35) that's not what the check does. it requires that, if you are using 4.9.x, the x be larger than 1. if you are using 4.4.x, then the check does not kick in.
I just updated gcc-4.9 to 4.9.3 and got the same phenomenon again. glibc was not updated...
<<< dir /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/include/g++-v4 <<< dir /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/include/cilk <<< dir /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/include-fixed <<< dir /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/include <<< dir /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/finclude <<< dir /usr/lib/debug/usr/libexec/gcc/i686-pc-linux-gnu/4.9.2/plugin <<< dir /usr/lib/debug/usr/libexec/gcc/i686-pc-linux-gnu/4.9.2 <<< dir /usr/lib/debug/usr/lib/gcc/i686-pc-linux-gnu/4.9.2 <<< dir /usr/lib/debug/usr/i686-pc-linux-gnu/gcc-bin/4.9.2 <<< dir /usr/i686-pc-linux-gnu/gcc-bin/4.9.2 [sys-devel/gcc-4.9.2] bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * The ebuild phase 'postrm' 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. /bin/bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * 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 postrm: 1 * The 'postrm' phase of the 'sys-devel/gcc-4.9.2' package has failed with * exit value 1. * * The problem occurred while executing the ebuild file named * 'gcc-4.9.2.ebuild' located in the '/var/db/pkg/sys-devel/gcc-4.9.2' * directory. If necessary, manually remove the environment.bz2 file and/or * the ebuild file located in that directory. * * Removal of the environment.bz2 file is preferred since it may allow the * removal phases to execute successfully. The ebuild will be sourced and * the eclasses from the current portage tree will be used when necessary. * Removal of the ebuild file will cause the pkg_prerm() and pkg_postrm() * removal phases to be skipped entirely. >>> Regenerating /etc/ld.so.cache... sh: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory >>> Original instance of package unmerged safely. [sys-devel/gcc-4.9.3] bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * The ebuild phase 'postinst' 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. /bin/bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * 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 postinst: 1 /usr/bin/scanelf: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory <<< !needed sym /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libgcj-tools.so.15 <<< !needed obj /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libgcj-tools.so.15.0.0 <<< !needed sym /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libgcj.so.15 <<< !needed obj /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libgcj.so.15.0.0 <<< !needed sym /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libgij.so.15 <<< !needed obj /usr/lib/gcc/i686-pc-linux-gnu/4.9.2/libgij.so.15.0.0 <<< !needed obj /usr/lib/libgit2.so.0.22.3 <<< !needed sym /usr/lib/libgit2.so.22 <<< !needed sym /usr/lib/libopenobex.so.1 <<< !needed obj /usr/lib/libopenobex.so.1.4.1 /bin/bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * The ebuild phase 'other' 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. [sys-devel/gcc-4.9.3] bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory /bin/bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * 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 execute postinst for sys-devel/gcc-4.9.3, Log file: >>> '/var/log/portage/sys-devel:gcc-4.9.3:20150820-192004.log' >>> Emerging (2 of 2) dev-java/gcj-jdk-4.9.3::gentoo [dev-java/gcj-jdk-4.9.3] bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory * The ebuild phase 'die_hooks' has been aborted since PORTAGE_BUILDDIR * does not exist: '/var/tmp/portage/dev-java/gcj-jdk-4.9.3' ... ... ...
root@marc:~ # ls ls: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory root@marc:~ # df df: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory root@marc:~ # lsof lsof: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory root@marc:~ # ls ls: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory root@marc:~ # mount mount: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory root@marc:~ # bash bash: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory root@marc:~ # gcc --version gcc (Gentoo 4.8.4 p1.6, pie-0.6.1) 4.8.4 Copyright (C) 2013 Free Software Foundation, Inc. Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.
root@marc:~ # ls ls: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory root@marc:~ # ldconfig root@marc:~ # ls insgesamt 14148 1703937 drwxr-x--- 31 root root 4096 18. Aug 21:00 ./ 2 drwxr-xr-x 23 root root 4096 20. Aug 21:21 ../ 1703938 drwx------ 2 root root 4096 1. Apr 2012 .TrueCrypt/
(In reply to Marc Burkhardt from comment #38) > libgcc_s.so.1: cannot open shared object file: No such file or directory none of those errors are related to this bug
Even if it's the same results as before? I cannot su and such anymore again... root@marc:~ # su - test setgid: Die angeforderte Funktion ist nicht implementiert root@marc:~ # ==> /var/log/auth.log <== Aug 21 06:53:54 local su[27027]: + /dev/pts/4 root:test Aug 21 06:53:54 local su[27027]: bad group ID `413' for user `test': Function not implemented
