After emerge glibc-2.10 the system refuses to do a lot of things... many programs fail (emerge, python, gzip, ssh ...) with the error: "xxxx: relocation error: yyyy: symbol __guard, version GLIBC_2.3.2 not defined in file libc.so.6 with link time reference" ssh, python, emerge fail with /lib/libz.so.1 gzip, zcat fail with gzip no emerge --info because emerge fails to load.... Reproducible: Didn't try Steps to Reproduce: 1.emerge --sync 2.emerge -1vauDN world 3......... Actual Results: errors from various tools, see description Expected Results: working system, my x86 systems happily upgraded, the amd64 failed.
emerge --info yields: !!! Failed to complete python imports. These are internal modules for !!! python and failure here indicates that you have a problem with python !!! itself and thus portage is not able to continue processing. !!! You might consider starting python with verbose flags to see what has !!! gone wrong. Here is the information we got for this exception: /lib/libz.so.1: symbol __guard, version GLIBC_2.3.2 not defined in file libc.so.6 with link time reference !!! Failed to complete python imports. These are internal modules for !!! python and failure here indicates that you have a problem with python !!! itself and thus portage is not able to continue processing. !!! You might consider starting python with verbose flags to see what has !!! gone wrong. Here is the information we got for this exception: /lib/libz.so.1: symbol __guard, version GLIBC_2.3.2 not defined in file libc.so.6 with link time reference
some advise to get back to a working system is also welcome
You could get your /etc/make.conf off the system and attach it here. And you could at least list the target of the /etc/make.profile symlink you use there. It's probably best to reboot into something bootable and then replace the glibc package using an autobuild tbz2 that you download from [1]. [1] http://tinderbox.dev.gentoo.org/
The system has been emerged a week ago, revdep rebuild has also been run after that. So the system was fairly clean before starting this emerge. make.profile: lrwxrwxrwx 1 root root 57 Sep 27 19:00 /etc/make.profile -> ..//usr/portage/profiles/default/linux/amd64/10.0/desktop Make.conf # These settings were set by the catalyst build script that automatically # built this stage. # Please consult /etc/make.conf.example for a more detailed example. CFLAGS="-O2 -pipe -mno-tls-direct-seg-refs -g -Wl,--as-needed" CXXFLAGS="${CFLAGS}" # This should not be changed unless you know exactly what you are doing. You # should probably be using a different stage, instead. CHOST="x86_64-pc-linux-gnu" MAKEOPTS="-j3" # These settings were set by the catalyst build script that automatically built this stage # Please consult /etc/make.conf.example for a more detailed example ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="PUEL sun-bcla-java-vm dlj-1.1" USE=" -apm -gnome -oss -eds -arts sse sse2 mmx pic X a52 aac aalib acl accessibility acpi activefilter ads aio akode alsa ao apache2 aqua audiofile audit authdaemond automount avahi bash-completion bl bluetooth bookmarks bzip2 cairo caps cdda cddb cdparanoia cdr cgi chm cleartype clvm cman cscope css curl dbus dga directfb dts dv dvb dvd dvdr eap-tls encode esd exif exiscan exiscan-acl expat fam fame fastcgi fax fbcon ffmpeg flac fltk foomaticdb fpx frxp gd ggi gif gimp glib gmp gnokii gnutls gphoto2 graphviz gs gsm gstreamer gtk guile hal howl-compat hpn html http httpd ical icecast idn id3 id3tag ieee1394 ilbc imap imlib ipv6 ithreads irda jabber jack java javascript jbig jingle jpeg jpeg2k joystick justify kde kdeprefix kerberos kipi kqemu ladspa lame laptop lcms ldap libcaca libsamplerate live lm_sensors lmtp loop-aes lua lzma lzo mad mailwrapper matroska mbrola md5sum mdnsresponder-compat memcache mhash mikmod mjpeg mmap mng motif mp2 mp3 mp4 mpeg mplayer musepack musicbrainz mysql nagios-dns nagios-game nagios-ntp nagios-ping nagios-ssh nas netboot network nls nptl nsplugin nvidia obex odbc odk ogg openal openexr opengl oscar oss pda pdf php plotutils png pnm portaudio postscript ppds pth pulseaudio qt3 qt3support quicktime quotas radius rar rdesktop real rle rrdtool rtc ruby samba sasl scanner sdl server skey slang sndfile snmp span speex spell spf sqlite sqlite3 srs ssl subversion svg svga swat symlink sysfs syslog theora threads tiff timidity tools truetype tta unicode ups urandom usb utempter v4l v4l2 vcd vde vidix vim-syntax vnc vorbis wavpack webdav wifi win32codecs winbind wma wmf x264 xanim xattr xfs xine xml xmlreader xmlrpc xmlwriter xosd xpm xscreensaver xv xvid xvmc yaz yv12 zeroconf zip zrtp " ALSA_CARDS="hda-intel usb-audio" VIDEO_CARDS="nvidia nv via vesa vga fbdev" INPUT_DEVICES="evdev keyboard mouse synaptics joystick" CAMERAS="ptp2 canon casio" LINGUAS="en_GB en_US nl_NL nl en" APACHE2_MPMS="peruser" #One of: event itk peruser prefork worker FEATURES="parallel-fetch userpriv sandbox usersandbox" #GENTOO_MIRRORS="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo http://mir.zyrianes.net/gentoo/" GENTOO_MIRRORS="ftp://212.219.56.134/sites/www.ibiblio.org/gentoo/ http://mirror.cambrium.nl/pub/os/linux/gentoo/ http://ftp.twaren.net/Linux/Gentoo/" PORTDIR_OVERLAY=/usr/local/portage # This sets what to log PORTAGE_ELOG_CLASSES="warn error log info qa" # And this is how to do it PORTAGE_ELOG_SYSTEM="save jabber" #Specify the sender jabber account: PORTAGE_ELOG_JABBERFROM="host.chippie@baggus.net:chippiehost" #Specify a list of receivers: PORTAGE_ELOG_JABBERTO="admin@baggus.net nico@baggus.net" PORTAGE_ELOG_JABBERCHAT=" " #emerge-reports@muc.baggus.net/chippie" PORTAGE_ELOG_SUBJECT='${PACKAGE} on ${HOST}' # PORT_LOGDIR=/var/log/portage PORTAGE_TMPFS="/dev/shm" #CONFIG_PROTECT_MASK="/etc/portage" #SYNC="rsync://rsync.nl.gentoo.org/gentoo-portage" source /usr/local/portage/layman/make.conf
__guard is only needed if your system is horribly out of date. i dont plan on re-adding the old ssp symbols to glibc.
so to fix your system, grab a tbz2 of a glibc-2.9 version, and then re-emerge all the packages that still refer to __guard.
So some programs & labraries are linked against an old glibc? maybe glibc for 64bit was adopted to old.... anyway HOW to test for this condition? I tend to agree that old symbols don't need to be reintroduced, at least not Bork a regularly updated system (emerge --sync, emerge -1vauDN world , revdep-rebuild and an occasional emerge -p --depclean) Appearantly this is "somewhat easy" to prevent.... (the only thing is to known HOW to do it...) grep for __guard om executables & libraries. maybe a test in revdep-rebuild?
really dont know what you mean about glibc and 64bit. __guard really has nothing to do with the host architecture. use scanelf to locate broken binaries: scanelf -qRs__guard /bin/ /lib/ also, i lied ... we still support the old __guard compat symbol, but only on hardened profiles. not that you should have had references to __guard in the first place when using a non-hardened profile. perhaps you switched on the fly.
I think that there was some period between the stabilisation of various glibc libraries, amd64 trails in that aspect. Clearly some time ago it the __guard became irrelevant, but somehow on x86 this was already fixed .... f.e. libacl on a x86 was last compiled aug. 18 2008 appearantly then __guard was already gone, the laptop has been setup a little later with amd64 as platform dec 2008 so even then __guard was actually needed then... in that aspect amd64 is different from x86...
If needed I can provide an emerge log
for the record these are the problematic programs... -rwxr-xr-x 1 root root 76120 Sep 7 2008 /bin/gzip -rwxr-xr-x 1 root root 116888 Sep 8 2008 /bin/mail -rwxr-xr-x 1 root root 412576 Sep 7 2008 /bin/tar -rwxr-xr-x 1 root root 34504 Sep 8 2008 /lib/libdm.so.0.0.4 -rwxr-xr-x 1 root root 51160 Aug 31 2008 /lib/libsysfs.so.2.0.1 -rwxr-xr-x 1 root root 39648 Sep 1 2008 /lib/libwrap.so.0.7.6 -rwxr-xr-x 1 root root 87936 Mar 14 2008 /lib/libz.so.1.2.3 -r-xr-xr-x 1 root root 18392 Aug 31 2008 /sbin/paxctl -rwxr-xr-x 1 root root 22656 Aug 31 2008 /sbin/portmap -rwxr-xr-x 1 root root 287552 Sep 8 2008 /sbin/xfsdump -rwxr-xr-x 1 root root 324768 Sep 8 2008 /sbin/xfsrestore -rwxr-xr-x 1 root root 262416 Sep 8 2008 /usr/sbin/atmsigd -rwxr-xr-x 1 root root 127080 Sep 10 2008 /usr/bin/ltrace -rwxr-xr-x 1 root root 320704 Sep 11 2008 /usr/bin/rateup -rwxr-xr-x 1 root root 811104 Sep 11 2008 /usr/bin/silc -rwxr-xr-x 1 root root 1549392 Sep 12 2008 /usr/lib/opensync-1.0/plugins/python-module.so -rwxr-xr-x 1 root root 31176 Oct 29 2008 /usr/bin/rle2gif -rwxr-xr-x 1 root root 22920 Oct 29 2008 /usr/bin/gif2rle -rwxr-xr-x 1 root root 4835904 Apr 16 2009 /usr/bin/fwbuilder -rwxr-xr-x 1 root root 31176 Sep 30 22:39 /usr/bin/rletopnm -rwxr-xr-x 1 root root 35368 Sep 30 22:39 /usr/bin/pnmtorle ----------------------- scanelf shows about 241 hits in /bin, /lib, /sbin, /usr/bin, /usr/lib, /usr/sbin ----------------------- match from tbz2 -rwxr-xr-x 1 root root 119064 Jun 29 2009 /lib/ld-2.9.so -rwxr-xr-x 1 root root 1334448 Jun 29 2009 /lib/libc-2.9.so
whether __guard refs made it into your binaries doesnt matter on the arch. the default profiles (i.e. non-hardened) have never forced ssp into things. you either were using SSP flags manually, or you were using the hardened profile and then you switched away w/out rebuilding things. i cant think of any scenario otherwise.
*** Bug 300808 has been marked as a duplicate of this bug. ***
hm yes hardened was attempted once, it didn't actually work out and I undid it. It was followed by an 'emerge -e world' ... that should have teken care of it I guessed, appearantly it didn't exactly work out that way it now appears.
the trouble is that you would have had to re-emerge gcc first and make sure the spec settings in your profile/env were reverted to vanilla. if they werent, then an -e world wouldnt have fixed everything. if i get more reports of this issue biting people, then i can add a sanity check before emerging things ... but i'd prefer not to of course ...
The sanity in my system is back to normal. One thing to keep in mind also is to explicitly check /lib64 & /lib32 differently if affected. because /lib is not found to get back to installable ebuild names. I doubt i'm the only one with problems because I gave up on hardened after too much shit hit the proverbial fan. My intent was to get a tamper resistant laptop. Using encrypted partition/volumes should do it for now.
use scanelf to find libraries having the __guard symbol scanelf -qRs__guard /lib64 /usr/lib64 (for 64 bit) scanelf -qRs__guard /lib /usr/lib (for 32 bit) This gives a list of files: /bin/gzip /bin/mail /bin/tar /lib64/libdm.so.0.0.4 /lib64/libsysfs.so.2.0.1 using epm you can find the packages that produced the files (mind the /lib64 for 64bit...) epm -qGf /bin/mail epm -qGf /bin/tar epm -qGf /lib64/libdm.so.0.0.4 epm -qGf /lib64/libsysfs.so.2.0.1 ... giving you the package names like f.e. mail-client/mailx-8.1.2.20050715-r1 sys-apps/dmapi-2.2.8 ... Which can be emerged. Before emerging various packages BE SURE to block the glibc update (temporarily as a masked packages using /etc/portage/package.mask) After all old pains have been fixed you can remove the glibc package.mask. Then apply all updates again.
*** Bug 302341 has been marked as a duplicate of this bug. ***
You can use the fix in Bug 125988 ------- Comment #14 From SpanKY 2006-03-16 20:34:35 0000 [reply] ------- ok, glibc-2.4-r1 should resolve this if you guys have a broken system and are unable to sync/re-emerge glibc, then you can grab prebuilt lib's to work around this issue: # bb # wget http://dev.gentoo.org/~vapier/amd64_libssp_simple.so # mv amd64_libssp_simple.so /lib/libssp_simple.so # echo /lib/libssp_simple.so > /etc/ld.so.preload for x86 users, just change the "amd64" to "x86" once you've installed glibc-2.4-r1, then just delete /lib/libssp_simple.so and /etc/ld.so.preload and you should be all set thanks to solar for this little hack workaround
*** Bug 320063 has been marked as a duplicate of this bug. ***
Do I understand correctly that switching to hardened profile for compiling glibc will protect me against this bug? (Please do NOT answer like "to switch to hardened profile you need to recompile world". I obviously won't and I still didn't find clear documentation explaining why just setting "hardened" use flag to have hardened toolchain is not possible anymore). If support for __guard will be dropped even for hardened profiles, can you tell when?
