[Gentoo]libdl.so.2, invalid ELF format

[Rainmaker]

Ik heb een beetje vreemd probleem. Gisteravond heb ik, zoals altijd een emerge --sync && emerge -uDv world gedaan. Hierbij zijn een 2tal pakketen ge-update, util-linux en portage, volgens mij niets bijzonders. Hierna begon hij met pakket 3, en kreeg ik "C compiler cannot create executables".

Niks bijzonders, dacht ik, zal wel iets de nieuwe portage icm CFLAGS zijn. Dus downgraden. Ik lees later de docs wel om te kijken wat ik in make.conf aan moet passen.

So far, so good. Nu start ik echter mijn PC op, en krijg zodra het ding op de init scripts uitkomt "libdl.so.2, invalid ELF format". Daarna meteen een login prompt.

Nou ja, ik maar een livecd gedownload en gebrand. Ik opstarten, fsck.reiser4 gedraaid, niets gevonden. Hierna probeerde ik te chrooten (chroot /mnt/gentoo /bin/bash), maar krijg ik "bash: cannot execute /bin/bash".

Dus ik proberen:

code:

/mnt/gentoo/bin/bash
"Cannot execute binairy"
/mnt/gentoo/usr/bin/gzip
"Cannot execute binairy"
/mnt/gentoo/usr/bin/gzcat   <--- Is bij mij een symlink naar gzip
"Usage: gzip <file>..."

Waarom werkt een symlink wel, maar een binairy niet?

Dus ik

code:

ln -s /mnt/gentoo/bin/bash /mnt/gentoo/blabla
chmod +x /mnt/gentoo/blabla
chroot /mnt/gentoo /blabla
"Cannot execute binairy file"
/mnt/gentoo/blabla
"Cannot execute binairy file"

Heb ergens via google gevonden dat dit door een probleem met binfmt_misc kan worden veroorzaakt. Heb de kernelconfig van de livecd bekeken, en zit erin gecompileerd.

Probleem is dus dat ik nu met geen mogelijkheid mijn instalatie niet inkom. Snapt iemand hier dit probleem?

[Osiris]

Die symlink verwijst probably naar je gzip buiten je /mnt/gentoo, dus naar de gzip op de live-CD, vandaar dat die wel werkt

Wat zegt `file /mnt/gentoo/bin/bash` bijvoorbeeld trouwens?

[ Voor 20% gewijzigd door Osiris op 05-03-2007 21:19 ]

[Rainmaker]

Osiris schreef op maandag 05 maart 2007 @ 21:18:
Wat zegt `file /mnt/gentoo/bin/bash` bijvoorbeeld trouwens?

code:

/mnt/gentoo/bin/bash
"Cannot execute binairy"

Met die symlink kun je wel eens gelijk hebben

[Osiris]

Het programma `file` zegt "Cannot execute binairy"?

[Rainmaker]

excuseer, fout gelezen.

stat /mnt/gentoo/bin/bash zegt "regular file"

file heb ik eerlijk gezegd nog niet geprobeerd. Ik heb /mnt/gentoo/bin/bash wel in vi geopend, en het zag eruit als een binairy.

De X bit staat trouwens ook goed.

[DataGhost]

code:

helios ~ # ldd /bin/bash
        linux-gate.so.1 =>  (0xb7f9a000)
        libncurses.so.5 => /lib/libncurses.so.5 (0xb7f4a000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7f46000)
        libc.so.6 => /lib/libc.so.6 (0xb7e2a000)
        /lib/ld-linux.so.2 (0xb7f9b000)

Zie ook regel 4. Als dat bestand stuk is werkt bash dus niet.

code:

helios ~ # for i in /bin/* /sbin/* /usr/bin/*; do echo -en "${i}: `ldd ${i} | grep libdl`\n" >> libdloutput; done             
helios ~ # grep libdl libdloutput | wc -l
326
helios ~ # grep -v libdl libdloutput | wc -l
1345

Het lijkt er ook op dat een redelijk deel van je systeembinaries er gebruik van maakt.

code:

helios ~ # equery b libdl.so.2
[ Searching for file(s) libdl.so.2 in *... ]
sys-libs/glibc-2.4-r4 (/lib/libdl.so.2 -> libdl-2.4.so)

kennelijk is er dus iets stuk aan glibc...

Probeer of je toevallig dit bestand van een andere machine kan halen (desnoods de livecd) en bouw dan glibc opnieuw. Let wel een klein beetje op de versie. Andere tips heb ik nu niet echt

edit: Je hebt niet toevallig te strakke CFLAGS ergens staan? Je systeem is verder ook stabiel (geheugen enzo)?

[ Voor 5% gewijzigd door DataGhost op 05-03-2007 21:43 ]

[Rainmaker]

DataGhost schreef op maandag 05 maart 2007 @ 21:41:

code:

helios ~ # equery b libdl.so.2
[ Searching for file(s) libdl.so.2 in *... ]
sys-libs/glibc-2.4-r4 (/lib/libdl.so.2 -> libdl-2.4.so)

kennelijk is er dus iets stuk aan glibc...

Dank, die zocht ik

Ik heb niet al te strakke CFLAGS, probleem is dat ik niks kan emergen zolang ik niet kan chrooten. Ik zal eens kijken of ik degene van de livecd kan gebruiken...

[Rainmaker]

file <bestand> gaf dus alleen "data".

Ik heb de bestanden uit een tarball gehaald op http://tinderbox.x86.dev.gentoo.org/default-linux/amd64/

Ik ben nu in ieder geval weer opgestart. Naast glibc lijkt ook gcc hetzelfde probleem te geven.

Ik krijg nu ook bij de emerge van een aantal pakketten (waaronder dus glibc)

code:

gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -O2 -pipe -c popcount.c  -fPIC -DPIC -o .libs/popcount.o
 gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -O2 -pipe -c pow_ui.c  -fPIC -DPIC -o .libs/pow_ui.o
Inconsistency detected by ld.so: rtld.c: 1219: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!
make[2]: *** [popcount.lo] Fout 1
make[2]: *** Wachten op onvoltooide taken...
Inconsistency detected by ld.so: rtld.c: 1219: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!
make[2]: *** [pow_ui.lo] Fout 1
make[2]: Map '/var/tmp/portage/dev-libs/gmp-4.2.1/work/gmp-4.2.1/mpz' wordt verlaten
make[1]: *** [all-recursive] Fout 1
make[1]: Map '/var/tmp/portage/dev-libs/gmp-4.2.1/work/gmp-4.2.1' wordt verlaten
make: *** [all] Fout 2

Ik ga weer googlen

Bedankt voor de tips

Iemand trouwens enig idee wat zoiets kan veroorzaken? fsck vindt niets vreemds, evenals revdep-rebuild...

[ Voor 4% gewijzigd door Rainmaker op 06-03-2007 02:02 ]

[MrBarBarian]

Dat fschk niets vindt klinkt wel logisch.. De vraag is natuurlijk wat je aan je cflags had aangepast ..

Ik denk dat het niet onverstandig is om je gehele world eens te rebuilden eigelijk..

[SA007]

^^ Je doet je naam eer aan: tot volgende week

Afhankelijk van wat voor bak het is zou ik ook 's chkrootkit draaien, heb 's iets vergelijkbaars gehad, was een rootkit die een hoop binairy's han aangepast.

[Rainmaker]

MrBarBarian schreef op dinsdag 06 maart 2007 @ 08:28:
Dat fschk niets vindt klinkt wel logisch.. De vraag is natuurlijk wat je aan je cflags had aangepast ..

Ik denk dat het niet onverstandig is om je gehele world eens te rebuilden eigelijk..

code:

Medusa ~ $ emerge -eDvp world
...
...
...
Total: 938 packages (11 upgrades, 1 new, 1 in new slot, 925 reinstalls, 2 blocks), Size of downloads: 1,963,399 kB

Medusa ~ $ emerge -eDvp world | genlop --pretend
...
...
Estimated update time: 1 day, 5 hours, 44 minutes.

Valt nog mee

code:

emerge --info | grep CFLAGS
CFLAGS="-march=nocona -O2 -pipe -fomit-frame-pointer -funroll-loops -fweb -ftree-vectorize"

Valt volgens mij nog wel mee. Zag wel dat ik ze al terug had gezet naar -O2 -pipe voordat ik glibc / gcc had gecompileerd...

SA007 schreef op dinsdag 06 maart 2007 @ 23:27:
^^ Je doet je naam eer aan: tot volgende week

Afhankelijk van wat voor bak het is zou ik ook 's chkrootkit draaien, heb 's iets vergelijkbaars gehad, was een rootkit die een hoop binairy's han aangepast.

Het is geen server, er staat een clarkconnect bakje als firewall tussen, enige poort die geforward wordt is voor azureus. Dus denk dat dat wel mee zal vallen.

Heb nu nog iets vreemd gemerkt: heb een paar keer gcc-config 2 (die volgens mij wat symlinks in /usr/bin update) gedraaid, en lijkt nu prima te werken

Snap niet waarom, maar tot nu toe geen problemen meer gehad...

Leuke tip voor mensen die willen kijken met welke CFLAGS een pakket gecompileerd is:

code:

cd /var/db/pkg
grep -r CFLAGS *

Ik gebruik:

code:

for i in $(grep -R -- "-O2 -pipe" * | grep CFLAGS | grep -v -- "-march=nocona" | cut -d / -f 1,2 ) ; do emerge -1vp =$i; done

om de pakketen te hercompileren die met -O2 -pipe zijn gecompileerd en niet met mijn "normale" CFLAGS

Als het nu straks weer de soep inloopt, weet ik in ieder geval zeker dat het aan mn CFLAGS ligt...

[ Voor 20% gewijzigd door Rainmaker op 07-03-2007 02:20 ]

[Rainmaker]

OK, nu heb ik het tot 3 keer toe meegemaakt:

code:

Medusa /var/db/pkg $ gcc
bash: /usr/bin/gcc: cannot execute binary file
Medusa /var/db/pkg $ su
Wachtwoord: 
Medusa pkg # gcc-config 2 
 * Switching native-compiler to x86_64-pc-linux-gnu-4.1.2 ...

 * Your gcc has a bug with GCC_SPECS.
 * Please re-emerge gcc.
 * http://bugs.gentoo.org/68395
                                                                          [ ok ]
Medusa pkg # gcc-config 2
 * Switching native-compiler to x86_64-pc-linux-gnu-4.1.2 ...             [ ok ]
Medusa pkg # gcc
gcc: geen invoerbestanden

Dit kan toch haast niet met te strakke CFLAGS of schijffouten te maken hebben? Misschien een bug in gcc-config?

Gcc is al ge-emerged met -O2 -pipe en met mn normale CFLAGS, in beide gevallen gebeurd dit.

[ Voor 34% gewijzigd door Rainmaker op 07-03-2007 02:48 ]