[Debian] Twee klassieke problemen - Linux en overige clients

zondag 30 december 2007 21:36

Acties:

maleadt

Topicstarter

Eerste hulp bij server-ongevallen nodig

Ik heb namelijk een klassieke fout gemaakt, door het upgraden van glibc

[ per ongeluk een een pakket geinstalleerd dat voor mijn chrooted omgeving bedoeld was...

]
Anyway, kan het probleem steeds verhelpen door de "/lib/tls" map te verwijderen/hernoemen, maar af en toe wil aptitude/apt-get een nieuwe libc installeren, wat dan weer resulteert in een kapot systeem (ondertussen heb ik al een 5tal keer de tls map moeten verwijderen om het weer werkende te krijgen). Is er een manier om dit permanent te fixen? En het blokkeren van updates van libc lijkt me niet echt een kosjere manier

Een ander probleem dat ik last van heb (vermoedelijk sinds mijn libc perikelen), is dat mijn locales verre van in orde zijn. Perl report altijd:

code:

perl: warning: Setting locale failed.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "nl_BE.utf8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Opnieuw een klassiek probleem, waarvoor "dpkg-reconfigure locales" normaal soelaas zou moeten bieden. Maar niks van, hoeveel keer ik de locales ook herconfigureer, ik blijf deze errors krijgen (niet alleen perl, maar vele andere programmas - zoals svn - hebben er last van). Wat kan ik hier aan doen? Wat informatie die zou kunnen helpen:

code:

downloader:/var/www# LC_ALL="nl_BE.utf8" perl -e 'print "Hallo!\n";'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "nl_BE.utf8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Hallo!
downloader:/var/www# dpkg-reconfigure locales
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "nl_BE.utf8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory
Generating locales (this might take a while)...
  nl_BE.UTF-8... done
Generation complete.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "nl_BE.utf8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "nl_BE.utf8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").


downloader:/var/www# locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
C
POSIX
nl_BE.utf8


downloader:/var/www# locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=nl_BE.utf8
LC_CTYPE="nl_BE.utf8"
LC_NUMERIC="nl_BE.utf8"
LC_TIME="nl_BE.utf8"
LC_COLLATE="nl_BE.utf8"
LC_MONETARY="nl_BE.utf8"
LC_MESSAGES="nl_BE.utf8"
LC_PAPER="nl_BE.utf8"
LC_NAME="nl_BE.utf8"
LC_ADDRESS="nl_BE.utf8"
LC_TELEPHONE="nl_BE.utf8"
LC_MEASUREMENT="nl_BE.utf8"
LC_IDENTIFICATION="nl_BE.utf8"
LC_ALL=

Ik snap het niet

De locale nl_BE.utf8 IS gegenereerd mbv "dpkg-reconfigure locales", IS standaard ingesteld, en nog blijf ik foutmeldingen krijgen...
Ook herinstallatie van locales (apt-get remove locales --purge; apt-get install locales) helpt niet.

Alvast bedankt!

zondag 30 december 2007 22:34

Acties:

deadinspace

The what goes where now?

Allereerst, welke Debian distribution draai je precies? Post indien nodig je sources.list.

MALEADt schreef op zondag 30 december 2007 @ 21:36:
Ik heb namelijk een klassieke fout gemaakt, door het upgraden van glibc [ per ongeluk een een pakket geinstalleerd dat voor mijn chrooted omgeving bedoeld was... ]

Welk pakket precies? libc6?

Anyway, kan het probleem steeds verhelpen door de "/lib/tls" map te verwijderen/hernoemen, maar af en toe wil aptitude/apt-get een nieuwe libc installeren, wat dan weer resulteert in een kapot systeem (ondertussen heb ik al een 5tal keer de tls map moeten verwijderen om het weer werkende te krijgen).

Als je /lib/tls niet verwijdert/hernoemt, wat is er dan precies mis? Je hebt het over een kapot systeem, maar wat gebeurt er dan precies?

Een ander probleem dat ik last van heb (vermoedelijk sinds mijn libc perikelen), is dat mijn locales verre van in orde zijn.

Hmm, en wat als je LANG en LANGUAGE eens export?

export LANG=nl_BE.utf8
export LANGUAGE=nl_BE.utf8
perl -e 'print "Hallo!\n";'

En als je eens C probeert?

export LANG=C
export LANGUAGE=C
export LC_ALL=C
perl -e 'print "Hallo!\n";'

zondag 30 december 2007 22:37

Acties:

freggy

Probeer je locales pakket ook te updaten, zodat je dezelfde versie libc6 en locales gebruikt.

zondag 30 december 2007 22:58

Acties:

maleadt

Topicstarter

deadinspace schreef op zondag 30 december 2007 @ 22:34:
Allereerst, welke Debian distribution draai je precies? Post indien nodig je sources.list.

Debian 4.0r1, custom kernel 2.6.23(.0)

Welk pakket precies? libc6?

Inderdaad, libc6.

Als je /lib/tls niet verwijdert/hernoemt, wat is er dan precies mis? Je hebt het over een kapot systeem, maar wat gebeurt er dan precies?

${zowat elke binary}: relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory,
version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference

Hmm, en wat als je LANG en LANGUAGE eens export?
export LANG=nl_BE.utf8
export LANGUAGE=nl_BE.utf8
perl -e 'print "Hallo!\n";'

Zelfde verhaal, ook als ik alle language settings override door LC_ALL te exporten...

En als je eens C probeert?

export LANG=C
export LANGUAGE=C
export LC_ALL=C
perl -e 'print "Hallo!\n";'

No problemo dan

Hier verlies ik dan alle vertaalde binaries, I guess? Kan me eigenlijk niet zoveel schelen, ik ben het Engels gewoon, maar ga ik dan geen problemen ondervinden timezones/keymaps/... of andere "regionale instellingen"?

En het locales pakket is dezelfde versie als libc6.

downloader:/var/www/include# dpkg -s libc6
Package: libc6
Status: install ok installed
Priority: required
Section: libs
Installed-Size: 10808
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Architecture: i386
Source: glibc
Version: 2.3.6.ds1-13etch4
Replaces: ldso (<= 1.9.11-9), timezone, timezones, gconv-modules, libtricks, libc6-bin, netkit-rpc, netbase (<< 4.0)
Provides: glibc-2.3.6.ds1-1, glibc-2.3.6-2
Depends: tzdata
Suggests: locales, glibc-doc
Conflicts: strace (<< 4.0-0), libnss-db (<= 2.2-6.1.1), timezone, timezones, gconv-modules, libtricks, libc6-doc, libc5 (<< 5.4.33-7), libpthread0 (<< 0.7-10), libc6-bin, libwcsmbs, apt (<< 0.3.0), libglib1.2 (<< 1.2.1-2), netkit-rpc, wine (<< 0.0.20031118-1), cyrus-imapd (<< 1.5.19-15), e2fsprogs (<< 1.35-7), initrd-tools (<< 0.1.84.1), libterm-readline-gnu-perl (<< 1.15-2)
Conffiles:
 /etc/init.d/glibc.sh e962bedb636c5499e97ce457878a754a
 /etc/ld.so.conf.d/i486-linux-gnu.conf 36f09aeeab18f6af453d0a1db0a0942c
Description: GNU C Library: Shared libraries
 Contains the standard libraries that are used by nearly all programs on
 the system. This package includes shared versions of the standard C library
 and the standard math library, as well as many others.


downloader:/var/www/include# dpkg -s locales
Package: locales
Status: install ok installed
Priority: standard
Section: libs
Installed-Size: 9848
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Architecture: all
Source: glibc
Version: 2.3.6.ds1-13etch4
Replaces: base-config, lliurex-belocs-locales-data
Depends: glibc-2.3.6.ds1-1, debconf | debconf-2.0
Conflicts: base-config, belocs-locales-bin, belocs-locales-data
Description: GNU C Library: National Language (locale) data [support]
 Machine-readable data files, shared objects and programs used by the
 C library for localization (l10n) and internationalization (i18n) support.
 .
 This package contains the libc.mo i18n files, plus tools to generate
 locale definitions from source files (included in this package). It allows
 you to customize which definitions actually get generated. This is a
 savings over how this package used to be, where all locales were generated
 by default. This created a package that unpacked to an excess of 30 megs.

En bedankt voor de reacties!

[ Voor 0% gewijzigd door maleadt op 30-12-2007 22:59 . Reden: typo ]

zondag 30 december 2007 23:49

Acties:

deadinspace

The what goes where now?

MALEADt schreef op zondag 30 december 2007 @ 22:58:

${zowat elke binary}: relocation error: /lib/tls/libc.so.6: symbol _dl_out_of_memory,
version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference

Hmm, ok. Heb je nog andere libc6 varianten geinstalleerd staan?

dpkg -l 'libc6*'

En kun je eens de md5sums van een paar files geven?

md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6

Wat je verder nog kan doen is een statisch gelinkte rescue shell zoals sash of busybox-static installeren, die zijn dan niet afhankelijk van de libraries op je systeem. Als je zo'n statisch gelinkte shell openhoudt tijdens pogingen dit op te lossen, dan kun je daar vrij makkelijk /lib/tls verwijderen (ik neem aan dat je dat nu vanaf een bootcd ofzo doet).

Wat voor chroot was dat eigenlijk waar die libc6 voor bedoeld was? Dus wat was er anders aan die libc6?

maandag 31 december 2007 11:14

Acties:

maleadt

Topicstarter

Het is allemaal foutgelopen toen ik een toolchain aan het maken was, waarvoor ik alles manueel moest compilen (binutils, libc, gcc, ...). In plaats van een make install in m'n chrooted omgeving ben ik (IIRC) zo stom geweest om die recentere libc6 op mijn server te installeren... Als ik mij niet vergis was dat glibc2.4, wat dus niet overeenkomt met de 2.3.6 die ik op mijn systeem draai (welke de versie is die standaard met Debian 4.0r1 geleverd wordt). Blijkbaar moeten er toch nog ergens restjes van glibc2.4 overgebleven zijn.

Anyway, dpkg zegt dat er maar 1 versie (de juiste) van libc geinstalleerd staat:

downloader:~# dpkg -l 'libc6*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name                              Version                           Description
+++-=================================-=================================-==================================================================================
ii  libc6                             2.3.6.ds1-13etch4                 GNU C Library: Shared libraries
un  libc6-bin                         <none>                            (no description available)
ii  libc6-dev                         2.3.6.ds1-13etch4                 GNU C Library: Development Libraries and Header Files
un  libc6-dev-amd64                   <none>                            (no description available)
un  libc6-doc                         <none>                            (no description available)
ii  libc6-i686                        2.3.6.ds1-13etch4                 GNU C Library: Shared libraries [i686 optimized]
un  libc6-prof                        <none>                            (no description available)
un  libc6.1                           <none>                            (no description available)
un  libc6.1-dev                       <none>                            (no description available)

Enkele MD5sums (tls.old ipv tls, aangezien ik die map hernoemd heb en tls nu niet meer bestaat):

downloader:~# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls.old3/libc.so.6
916c8184d5cfc35fe53335ad2fc476e9  /lib/ld-linux.so.2
9c589870042b8315797864079c2162e0  /lib/libc.so.6
5fd791aab2f881c0c56eb27d411ab558  /lib/tls.old/libc.so.6

En MD5's van de vorige keren dat het fout liep:

downloader:~# md5sum /lib/tls.old/libc.so.6 /lib/tls.old2/libc.so.6 /lib/tls.old3/libc.so.6
8ec66c93aa3c0dfc4fb12e4685c43b5c  /lib/tls.old/libc.so.6  (4/11)
8ec66c93aa3c0dfc4fb12e4685c43b5c  /lib/tls.old2/libc.so.6 (11/11)
5fd791aab2f881c0c56eb27d411ab558  /lib/tls.old3/libc.so.6 (30/12)

Een statisch gelinkte shell is inderdaad een hulp voor wanneer het fout loopt, maar vreemd genoeg heb ik nog maar 1 keer de rescue cd moeten boven halen. De andere keren (zoals gisteren) werkt geen enkele binary meer, maar kan ik nog alles doen met de connected WinSCP client die openstaat. Daarmee hernoem ik dan de TLS map, en alle binaries werken weer zoals voorheen. Het moet zijn dat de sftp server, die in het geheugen geladen is, zonder hulp van externe binaries enkele bewerkingen (zoals hernoemen, of verwijderen) kan uitvoeren; en zo op 1 of andere manier werkzaam blijft

maandag 31 december 2007 13:20

Acties:

jschot

Wat betreft je locale problemen, ik zie twee verschillende notaties.

nl_BE.utf8 (in jouw settings)
nl_BE.UTF-8 (in de output van dpkg-reconfigure locales)

Probeer eens export LANG="nl_BE.UTF-8". Lost dat het probleem op?

maandag 31 december 2007 13:32

Acties:

CyBeR

💩

Je zou libc6-xen kunnen proberen te installeren. Thread-local storage problemen komen vooral voor met gevirtualiseerde linuxen, die libc heeft 't dus niet aan boord.

All my posts are provided as-is. They come with NO WARRANTY at all.

maandag 31 december 2007 13:54

Acties:

Tim

Ik maak het niet op uit je verhaal, maar ik neem aan dat je al geprobeert hebt de packages te herinstalleren? Zo niet:

apt-get install --reinstall libgcc1 libc6 libc6-i686 overige-meuk

Mocht je dat gedaan hebben, dan kan je altijd nog alle bestanden op hun md5 hash controleren om te kijken of je misschien packages gemist hebt. Installeer dlocate en probeer:

dpkg -l | awk '/^i/ {print $2}' | xargs -n 1 dlocate -md5check | grep -v 'OK$'

Eventueel kan je tiger installeren en misbruiken om te zoeken naar bestanden die niet in packages thuis horen, maar dat lijkt me enigzins overbodig.

maandag 31 december 2007 16:10

Acties:

maleadt

Topicstarter

jschot schreef op maandag 31 december 2007 @ 13:20:
Probeer eens export LANG="nl_BE.UTF-8". Lost dat het probleem op?

Jammer genoeg niet, ik heb beide schrijfwijzen geprobeerd (ook in de LC_ALL override), maar het maakt geen verschil. Heb alles dus maar op de C locale ingesteld, zonder localisatie dan maar (en hopelijk zonder andere problemen)

Tes schreef op maandag 31 december 2007 @ 13:54:
Ik maak het niet op uit je verhaal, maar ik neem aan dat je al geprobeert hebt de packages te "herinstalleren?

Libc6 heb ik tot vervelens toe op alle mogelijke manieren verwijderd, maar libc6-i686 had ik nog niet naar gekeken...
Proberen herinstalleren van libc6/libc6-i686 gaf me

E: Internal Error, Could not perform immediate configuration (2) on libgcc1

Dan heb ik maar die drie pakketten apart geherinstalleerd

apt-get install --reinstall libgcc1
-> geen probleem ( = herinstallatie lukt EN systeem werkt nog achteraf)

apt-get install --reinstall libc6
-> geen probleem ( = herinstallatie lukt EN systeem werkt nog achteraf)

apt-get install --reinstall libc6-i686
-> problematisch! ( = herinstallatie lukt, maar systeem werkt niet meer achteraf)
relocation error: /lib/tls/i686/cmov/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference

"/lib/tls" hernoemd, en alles werkte weer. Maar het is dus libc6-i686, en NIET libc6 die mn systeem tijdelijk mank doet lopen... Vreemd, aangezien libc6-i686 en libc6 dezelfde versie zijn (2.3.6.ds1-13etch4)

En wat betreft die MD5sums, buiten het afwezig zijn van /lib/tls* en /lib/tls/i686/* scheelt daar niet veel aan (wat headers in /include die missen, headers van mn zelfgecompilde kernel in /usr/src die ontbreken, aspell md5 failuret lshw md5 failure, ...).

maandag 31 december 2007 16:54

Acties:

Jaap-Jan

Kun je libc6-i686 niet eraf mikken? Ik heb op mijn Debian Etch (amd64) bak ook niet meer dan libc6, geen andere versies, of zoiets.

| Last.fm | "Mr Bent liked counting. You could trust numbers, except perhaps for pi, but he was working on that in his spare time and it was bound to give in sooner or later." -Terry Pratchett

dinsdag 1 januari 2008 23:50

Acties:

deadinspace

The what goes where now?

MALEADt schreef op maandag 31 december 2007 @ 11:14:
Het is allemaal foutgelopen toen ik een toolchain aan het maken was, waarvoor ik alles manueel moest compilen (binutils, libc, gcc, ...). In plaats van een make install in m'n chrooted omgeving ben ik (IIRC) zo stom geweest om die recentere libc6 op mijn server te installeren...

Ah, ok, je hebt dus make install buiten de chroot gedaan, en die heeft lekker een andere libc6 in je /lib/ lopen zetten, buiten het package management om.

ii  libc6                             2.3.6.ds1-13etch4
ii  libc6-i686                        2.3.6.ds1-13etch4

Ok, libc6-i686 moeten we ook meenemen in dit probleem. libc6-i686 bevat een geoptimaliseerde versie voor libc6, waarvan de files in /lib/tls/i686/cmov terecht komen. Deze worden dan gebruikt met voorrang op die in /lib, zodat programma's gebruik maken van de geoptimaliseerde versies.

downloader:~# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls.old3/libc.so.6
916c8184d5cfc35fe53335ad2fc476e9  /lib/ld-linux.so.2
9c589870042b8315797864079c2162e0  /lib/libc.so.6
5fd791aab2f881c0c56eb27d411ab558  /lib/tls.old/libc.so.6

Op mijn server (Debian Etch, ook libc6 en libc6-i686 versie 2.3.6.ds1-13etch4):

% md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
fae0f2490acb4a30f8d3f3a722e69c48  /lib/ld-linux.so.2
7ada02ffc01a25efe3e968fbae6ad1f9  /lib/libc.so.6
5fd791aab2f881c0c56eb27d411ab558  /lib/tls/libc.so.6

Dus die /lib/tls/libc.so.6 in is hetzelfde als de mijne (die zal dpkg overschreven hebben in die updates telkens), maar /lib/ld-linux.so.2 en /lib/libc.so.6 niet. Die twee zullen dus overschreven zijn door je make install.

/lib/ld-linux.so.2 en /lib/libc.so.6 (en waarschijnlijk nog een stel anderen) zullen dus vervangen moeten worden door de versies in Etch, dan zou het weer normaal moeten werken.

Deze zitten beiden in het libc6 package:

% dlocate /lib/ld-linux.so.2; dlocate /lib/libc.so.6                                                                                          [23:33:46]
libc6: /lib/ld-linux.so.2
libc6: /lib/libc.so.6

Ik vraag me dus af waarom een

apt-get install --reinstall libc6

deze niet vervangt. Je zou eens kunnen proberen het libc6 package te downloaden en te installeren met

dpkg -i libc6_2.3.6.ds1-13etch4_i386.deb

... maar vreemd genoeg heb ik nog maar 1 keer de rescue cd moeten boven halen. De andere keren (zoals gisteren) werkt geen enkele binary meer, maar kan ik nog alles doen met de connected WinSCP client die openstaat. Daarmee hernoem ik dan de TLS map, en alle binaries werken weer zoals voorheen. Het moet zijn dat de sftp server, die in het geheugen geladen is, zonder hulp van externe binaries enkele bewerkingen (zoals hernoemen, of verwijderen) kan uitvoeren; en zo op 1 of andere manier werkzaam blijft

Ahja. Dat is inderdaad precies het geval. sshd (die ook de sftp support levert) zal die nieuwe libs pas gebruiken nadat hij herstart is. Als het goed is wordt sshd herstart na een upgrade van libc6, maar het sshd process dat jouw openstaande connectie verzorgt wordt niet herstart en gebruikt dus nog de oude libraries, en werkt daarom nog.

En sshd zal inderdaad geen rm of mv opstarten, maar gewoon direct de libc functies unlink() en rename() gebruiken. Dat is wel zo gebruikelijk

MALEADt schreef op maandag 31 december 2007 @ 16:10:
Jammer genoeg niet, ik heb beide schrijfwijzen geprobeerd (ook in de LC_ALL override), maar het maakt geen verschil.

Voorzover ik weet zijn die schrijfwijzen dan ook equivalent. (Maar daar kan ik naast zitten)

Maar het is dus libc6-i686, en NIET libc6 die mn systeem tijdelijk mank doet lopen...

Nouja, de files in libc6-i686 (die in /lib/tls/i686) doen ook wat met de files in libc6 (in /lib). En ze verwachten daarbij dat die files in /lib bepaalde opties hebben (dat GLIBC_PRIVATE gebeuren). Dat werkt normaal prima, want de libc6 in Debian heeft die opties.

Maar, jouw files in /lib zijn overschreven door die make install, en blijkbaar biedt die libc6 die opties niet.

Vreemd, aangezien libc6-i686 en libc6 dezelfde versie zijn (2.3.6.ds1-13etch4)

Ja, dat denkt het package management. Maar de files in /lib zijn dus overschreven door iets anders. Dpkg denkt dat die files afkomstig zijn uit libc6_2.3.6.ds1-13etch4_i386.deb, maar ze zijn afkomstig uit die make install. Zie ook de md5sums

Jaap-Jan schreef op maandag 31 december 2007 @ 16:54:
Kun je libc6-i686 niet eraf mikken?

Die kan weg ja, hij is optioneel. Maar je wil hem op zich wel op i686 machines, want hij is sneller.

Bovendien, als het werkt zonder libc6-i686, dan heb je het probleem alleen uitgesteld, want die files in /lib zijn nog steeds afkomstig uit make install, en dus niet wat Debian verwacht.

Ik heb op mijn Debian Etch (amd64) bak ook niet meer dan libc6, geen andere versies, of zoiets.

Klopt, want amd64 heeft geen libc6-i686. Alle huidige CPUs van de amd64 architectuur hebben vergelijkbare features, dus een aparte libc6 package met optimalisaties voor modernere CPUs is daar niet nodig.

Op i386 daarentegen werkt het libc6 package op elke CPU vanaf de Intel 80386 (al zou het kunnen dat ze dat tegenwoordig opgeschroefd hebben naar 80486). Maar modernere i386 CPUs bieden wat extra's, dus libc6-i686 werkt op Pentium Pro's en later, en maakt gebruik van deze extra's.

donderdag 3 januari 2008 10:09

Acties:

maleadt

Topicstarter

Alvast bedankt voor de hele uitleg! Maar na je stappenplan gevolgd te hebben snap ik het nog minder

Voor ik aan iets begonnen ben heb ik de MD5's gecontroleerd:

downloader:~# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
916c8184d5cfc35fe53335ad2fc476e9  /lib/ld-linux.so.2
9c589870042b8315797864079c2162e0  /lib/libc.so.6
md5sum: /lib/tls/libc.so.6: No such file or directory

2 corrupte verkeerde bestanden, en 1 die ontbreekt (uit de tls folder die ik systematisch verwijder).

Dus ik herinstalleer libc6, (apt-get install --reinstall libc6). En wat zie ik:

downloader:~# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
fae0f2490acb4a30f8d3f3a722e69c48  /lib/ld-linux.so.2
7ada02ffc01a25efe3e968fbae6ad1f9  /lib/libc.so.6
5fd791aab2f881c0c56eb27d411ab558  /lib/tls/libc.so.6

Which is good, nu hoef ik libc6 niet meer te viseren (deze reinstall heb ik ook al tig keren uitgevoerd).

Dus besloot ik om nog eens te gaan kijken naar libc-i686 (apt-get install libc6-i686), maar na dat gedaan te hebben werkte mijn systeem niet meer. /lib/tls hernoemt, en eens de MD5's gecontroleerd:

downloader:~# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
916c8184d5cfc35fe53335ad2fc476e9  /lib/ld-linux.so.2
9c589870042b8315797864079c2162e0  /lib/libc.so.6
md5sum: /lib/tls/libc.so.6: No such file or directory

Hmm, zit ik opnieuw opgescheept met de "verkeerde" bestanden. (Ook na verwijdering van libc6-i686 blijven de verkeerde bestanden op plaats, dpkg doet zijn werk precies niet goed?)

Ik begon te vermoeden dat een lokaal pakket overschreven moest geraakt zijn met 1 van de paketten uit mn toolchain (hoe vreemd dat ook moge klinken). Dus ik wou libc6 en libc6-i686 eens vervangen met de originele pakketten (downloaden van debian server en installeren met dpkg).

downloader:/tmp# dpkg -i libc6_2.3.6.ds1-13etch4_i386.deb
[snip]
downloader:/tmp# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
fae0f2490acb4a30f8d3f3a722e69c48  /lib/ld-linux.so.2
7ada02ffc01a25efe3e968fbae6ad1f9  /lib/libc.so.6
5fd791aab2f881c0c56eb27d411ab558  /lib/tls/libc.so.6

Zelfde situatie als voorheen, libc6 is dus clean.

downloader:/tmp# dpkg -i libc6-i686_2.3.6.ds1-13etch4_i386.deb
[snip]
downloader:/tmp# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
md5sum: relocation error: /lib/tls/i686/cmov/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
[mv /lib/tls mbv openstaande sftp sessie]
downloader:/tmp# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
916c8184d5cfc35fe53335ad2fc476e9  /lib/ld-linux.so.2
9c589870042b8315797864079c2162e0  /lib/libc.so.6
md5sum: /lib/tls/libc.so.6: No such file or directory

En again...

Maar het vreemde is dat die checksums altijd afwijken van die op jouw server; een mens zou zich beginnen afvragen of jij (@deadinspace) wel libc6-i686 geinstalleerd hebt

Voor het moment draai ik dus zonder libc6-i686, liever een wat trager systeem dan 1 dat er maandelijks het bijltje bij neerlegt

maleadt

[ Voor 1% gewijzigd door maleadt op 03-01-2008 10:10 . Reden: Toevoeging ]

donderdag 3 januari 2008 23:33

Acties:

deadinspace

The what goes where now?

MALEADt schreef op donderdag 03 januari 2008 @ 10:09:
Voor ik aan iets begonnen ben heb ik de MD5's gecontroleerd:
[foute md5sums]

Dus ik herinstalleer libc6, (apt-get install --reinstall libc6). En wat zie ik:
[juiste md5sums]

Dus besloot ik om nog eens te gaan kijken naar libc-i686 (apt-get install libc6-i686), maar na dat gedaan te hebben werkte mijn systeem niet meer. /lib/tls hernoemt, en eens de MD5's gecontroleerd:
[foute md5sums]
Hmm, zit ik opnieuw opgescheept met de "verkeerde" bestanden. (Ook na verwijdering van libc6-i686 blijven de verkeerde bestanden op plaats, dpkg doet zijn werk precies niet goed?)

Ok, ik snap officieel niet waarom dat gebeurt

Op mijn systeem:

# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
fae0f2490acb4a30f8d3f3a722e69c48  /lib/ld-linux.so.2
7ada02ffc01a25efe3e968fbae6ad1f9  /lib/libc.so.6
5fd791aab2f881c0c56eb27d411ab558  /lib/tls/libc.so.6
# apt-get -qq install --reinstall libc6
(Reading database ... 26297 files and directories currently installed.)
Preparing to replace libc6 2.3.6.ds1-13etch4 (using .../libc6_2.3.6.ds1-13etch4_i386.deb) ...
Unpacking replacement libc6 ...
Setting up libc6 (2.3.6.ds1-13etch4) ...

# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
fae0f2490acb4a30f8d3f3a722e69c48  /lib/ld-linux.so.2
7ada02ffc01a25efe3e968fbae6ad1f9  /lib/libc.so.6
5fd791aab2f881c0c56eb27d411ab558  /lib/tls/libc.so.6
# apt-get -qq install --reinstall libc6-i686
(Reading database ... 26297 files and directories currently installed.)
Preparing to replace libc6-i686 2.3.6.ds1-13etch4 (using .../libc6-i686_2.3.6.ds1-13etch4_i386.deb) ...
Unpacking replacement libc6-i686 ...
Setting up libc6-i686 (2.3.6.ds1-13etch4) ...

# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
fae0f2490acb4a30f8d3f3a722e69c48  /lib/ld-linux.so.2
7ada02ffc01a25efe3e968fbae6ad1f9  /lib/libc.so.6
5fd791aab2f881c0c56eb27d411ab558  /lib/tls/libc.so.6

De md5sums van mijn files blijven dus onveranderd na herinstallatie van libc6 en libc6-i686.

downloader:/tmp# dpkg -i libc6-i686_2.3.6.ds1-13etch4_i386.deb
[snip]
downloader:/tmp# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
md5sum: relocation error: /lib/tls/i686/cmov/libc.so.6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference
[mv /lib/tls mbv openstaande sftp sessie]
downloader:/tmp# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
916c8184d5cfc35fe53335ad2fc476e9  /lib/ld-linux.so.2
9c589870042b8315797864079c2162e0  /lib/libc.so.6
md5sum: /lib/tls/libc.so.6: No such file or directory

Hmm, dat sluit iig uit dat je apt-get install --reinstall libc6-i686 een andere versie van libc6 meesleepte ofzo, want dpkg doet dat niet.

Twee dingen die je zou kunnen doen die ons dichter tot een verklaring zouden kunnen brengen:

Zorgen dat je libs de juiste md5sums hebben (bv door libc6-i686 te verwijderen en libc6 te reinstallen), en dan kijken of ergens op je systeem files met die md5sum voorkomen, met bv
```
# find / -type f -print0 | xargs -0 md5sum | grep 9c589870042b8315797864079c2162e0
```
(daar kan je systeem wel eventjes zoet mee zijn overigens, zeker als er nog significante hoeveelheden data op staan)
Eens kijken wat dpkg exact uitvreet als je libc6-i686 installeert, met
```
strace -f -o /tmp/dpkg_strace.log dpkg -i libc6-i686_2.3.6.ds1-13etch4_i386.deb
```
In /tmp/dpkg_strace.log komt dan te staan welke system calls er precies uitgevoerd zijn. Je zou daarin kunnen zoeken op de filenames in kwestie. Je mag de file ook online zetten en hier een link geven, dan kunnen wij er ook in snuffelen. Merk op dat de file aardig groot kan zijn.
(Je moet waarschijnlijk eerst strace installeren trouwens)

En again... Maar het vreemde is dat die checksums altijd afwijken van die op jouw server; een mens zou zich beginnen afvragen of jij (@deadinspace) wel libc6-i686 geinstalleerd hebt

[marcelm@mir ~ .]% dpkg -l libc6\*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=ba
||/ Name                                 Version                             
+++-====================================-====================================
ii  libc6                                2.3.6.ds1-13etch4
un  libc6-bin                            <none>
un  libc6-dbg                            <none>
ii  libc6-dev                            2.3.6.ds1-13etch4
un  libc6-dev-amd64                      <none>
un  libc6-doc                            <none>
ii  libc6-i686                           2.3.6.ds1-13etch4
un  libc6-prof                           <none>
un  libc6.1                              <none>
un  libc6.1-dev                          <none>

Jawel dus

[ Voor 3% gewijzigd door deadinspace op 03-01-2008 23:38 ]

vrijdag 4 januari 2008 13:33

Acties:

maleadt

Topicstarter

Strace log staat online, 15488 lijnen = 11 pagina's. Als je liever het bestand zelf hebt in plaats van een pagina om het te lezen, kan je dpkg_strace.log hier downloaden. Ik moet het zelf nog eens goed bekijken (zal vanavond zijn, nu geen tijd), heb nu gewoon m'n server gewoon aan het controleren gezet

Bedankt voor je hulp!

EDIT: breakthrough!

9c589870042b8315797864079c2162e0  /lib/libc-2.7.so

Dpkg gebruikt bij installatie van libc6-i686 dus libc-2.7.so in plaats van libc-2.3.7.so. Blijkbaar controleert dpkg bij het installeren van libc6 of er toevallig geen nieuwe versie op het systeem aanwezig is, en gebruikt die dan in plaats van het pakket dat de gebruiker specificeert... Maar waarom gebeurt dat dan enkel tijdens installatie van libc6-i686, en niet bij installatie van libc6?
In het log van strace valt libc-2.7 duidelijk te vinden (op pagina 8 van het log), maar jammer genoeg vind ik daar ook veel andere libraries met versienummering 2.7 (in plaats van 2.3.6)...

Een opsomming van alle /lib/*2.3.6 libraries:

-rwxr-xr-x  1 root root    88164 Aug 19 00:03 ld-2.3.6.so
-rw-r--r--  1 root root     5448 Aug 19 00:03 libBrokenLocale-2.3.6.so
-rw-r--r--  1 root root     9868 Aug 19 00:03 libanl-2.3.6.so
-rwxr-xr-x  1 root root  1147548 Aug 19 00:03 libc-2.3.6.so
-rw-r--r--  1 root root   181684 Aug 19 00:03 libcidn-2.3.6.so
-rw-r--r--  1 root root    21868 Aug 19 00:03 libcrypt-2.3.6.so
-rw-r--r--  1 root root     9592 Aug 19 00:03 libdl-2.3.6.so
-rw-r--r--  1 root root   141040 Aug 19 00:03 libm-2.3.6.so
-rw-r--r--  1 root root    72452 Aug 19 00:03 libnsl-2.3.6.so
-rw-r--r--  1 root root    26332 Aug 19 00:03 libnss_compat-2.3.6.so
-rw-r--r--  1 root root    17840 Aug 19 00:03 libnss_dns-2.3.6.so
-rw-r--r--  1 root root    34276 Aug 19 00:03 libnss_files-2.3.6.so
-rw-r--r--  1 root root    17856 Aug 19 00:03 libnss_hesiod-2.3.6.so
-rw-r--r--  1 root root    34320 Aug 19 00:03 libnss_nis-2.3.6.so
-rw-r--r--  1 root root    38340 Aug 19 00:03 libnss_nisplus-2.3.6.so
-rw-r--r--  1 root root    59172 Aug 19 00:03 libresolv-2.3.6.so
-rw-r--r--  1 root root    30616 Aug 19 00:03 librt-2.3.6.so
-rw-r--r--  1 root root     9656 Aug 19 00:03 libutil-2.3.6.so

Een opsomming van alle /lib/*2.7 libraries:

-rw-r--r--  1 root root     2575 Nov  4 16:00 crt1.o
-rwxr-xr-x  1 root root   613985 Nov  4 16:04 ld-2.7.so
-rwxr-xr-x  1 root root    10177 Nov  4 16:01 libBrokenLocale-2.7.so
-rwxr-xr-x  1 root root    57310 Nov  4 16:03 libanl-2.7.so
-rwxr-xr-x  1 root root  7102962 Nov  4 16:04 libc-2.7.so
-rwxr-xr-x  1 root root   107241 Nov  4 16:03 libcrypt-2.7.so
-rwxr-xr-x  1 root root    98508 Nov  4 16:02 libdl-2.7.so
-rw-r--r--  1 root root    32378 Nov  4 16:02 libdl.a
-rwxr-xr-x  1 root root   564027 Nov  4 16:01 libm-2.7.so
-rwxr-xr-x  1 root root   426744 Nov  4 16:04 libnsl-2.7.so
-rwxr-xr-x  1 root root    92178 Nov  4 16:04 libnss_compat-2.7.so
-rwxr-xr-x  1 root root    55441 Nov  4 16:03 libnss_dns-2.7.so
-rwxr-xr-x  1 root root   154029 Nov  4 16:03 libnss_files-2.7.so
-rwxr-xr-x  1 root root    67550 Nov  4 16:03 libnss_hesiod-2.7.so
-rwxr-xr-x  1 root root   170594 Nov  4 16:04 libnss_nis-2.7.so
-rwxr-xr-x  1 root root   227753 Nov  4 16:04 libnss_nisplus-2.7.so
-rw-r--r--  1 root root    29700 Oct 21 21:35 libpam.so.0.79
-rw-r--r--  1 root root    48256 Sep 13  2006 libproc-3.2.7.so
-rwxr-xr-x  1 root root   630013 Nov  4 16:03 libpthread-2.7.so
-rwxr-xr-x  1 root root   234560 Nov  4 16:03 libresolv-2.7.so
-rwxr-xr-x  1 root root   201228 Nov  4 16:03 librt-2.7.so
-rw-r--r--  1 root root    28740 Feb 13  2007 libusb-0.1.so.4.4.4
-rwxr-xr-x  1 root root    24470 Nov  4 16:04 libutil-2.7.so

Mijn systeem is aardig vervuild, I guess

Alle versieloze symlinks staan wel nog correct ingesteld op de 2.3.6 binaries (gelukkig

), maar gewoon verwijderen van alle 2.7 libraries lijkt me niet de beste (lees: veiligste) oplossing. Of wel?

EDIT 2: Nieuwe informatie
De 2.7 libraries behoren tot geen enkel pakket gekend door dpkg, het volgende commando retourneert namelijk niks:

ls /lib | grep "\-2.7" | xargs -n 1 dlocate

EDIT 3: oplossing?
Ik heb een risico genomen, en al de *2.7.so libraries die m'n systeem vervuilden, in een apart mapje gezet (in de hoop dat mijn systeem dat zou overleven

). Maar alles bleek nog naar behoren te werken, meer nog, installatie van libc6-i686 corrupteerde nu geen libraries meer!

downloader:/tmp# apt-get install -qq --reinstall libc6 libc6-i686
downloader:/tmp# md5sum /lib/ld-linux.so.2 /lib/libc.so.6 /lib/tls/libc.so.6
fae0f2490acb4a30f8d3f3a722e69c48  /lib/ld-linux.so.2
7ada02ffc01a25efe3e968fbae6ad1f9  /lib/libc.so.6
5fd791aab2f881c0c56eb27d411ab558  /lib/tls/libc.so.6

Voor de zekerheid heb ik de hele procedure gelogd via strace, en *nergens* vond dpkg nog zogezegd nieuwere 2.7 libraries

EDIT 4: locales werken weer!
Blijkbaar was het locales probleem veroorzaakt door deze library mess-up, want nu dat ik libc6 weer werkende gekregen heb, klaagt geen enkele binary meer als ik de default-locale toch instel op nl_NL.UTF-8

downloader:~# perl
use POSIX qw(locale_h);
print setlocale(LC_CTYPE);
__END__
nl_NL.UTF-8

Hopelijk juich ik niet te vroeg, en kom ik geen andere problemen meer tegen, maar kom voor zover ziet het er goed uit

[ Voor 93% gewijzigd door maleadt op 04-01-2008 18:22 . Reden: Meer info! ]

vrijdag 4 januari 2008 18:33

Acties:

deadinspace

The what goes where now?

MALEADt schreef op vrijdag 04 januari 2008 @ 13:33:
Bedankt voor je hulp!

Graag gedaan, maar we zijn er nog niet

EDIT: breakthrough!
9c589870042b8315797864079c2162e0  /lib/libc-2.7.so
Dpkg gebruikt bij installatie van libc6-i686 dus libc-2.7.so in plaats van libc-2.3.7.so.

Achja, natuurlijk. Je make install heeft die libc-2.7.so neergezet, en een reinstall van libc6 zet natuurlijk vrolijk 2.3.6 er naast neer. En als dan de nieuwste libs voor de symlinks gebruikt worden...

Blijkbaar controleert dpkg bij het installeren van libc6 of er toevallig geen nieuwe versie op het systeem aanwezig is, en gebruikt die dan in plaats van het pakket dat de gebruiker specificeert...

Ja, dat gebeurt omdat dpkg na het installeren van libs ldconfig runt. ldconfig controleert en beheert (onder andere) die symlinks, en ldconfig gebruikt inderdaad de nieuwste aanwezige libs voor de symlinks.
ldconfig wordt aangeroepen vanuit het libc6(-i686) postinst script:

% grep ldconfig /var/lib/dpkg/info/libc6.postinst                                                                                             [18:12:45]
    # Handle upgrades for libdb.so.3. We do this before calling ldconfig,
        ldconfig

En dat is ook terug te zien in het strace log:

% egrep '^[0-9]* exec' dpkg_strace.log | grep ldconfig
29841 execve("/sbin/ldconfig", ["ldconfig"], [/* 14 vars */]) = 0

Maar waarom gebeurt dat dan enkel tijdens installatie van libc6-i686, en niet bij installatie van libc6?

Dat weet ik niet, misschien doet het libc6 postinst script nog wat bijzonders met ldconfig.

Mijn systeem is aardig vervuild, I guess
Alle versieloze symlinks staan wel nog correct ingesteld op de 2.3.6 binaries (gelukkig ), maar gewoon verwijderen van alle 2.7 libraries lijkt me niet de beste (lees: veiligste) oplossing. Of wel?

Je zou die 2.7 libs gewoon moeten kunnen verwijderen, mits ze niet gebruikt worden.

Het beste lijkt het me om als eerste een reservekopie van je /lib te maken met

cp -a

Dan kun je vanuit een static shell altijd je /lib weggooien en die kopie terugzetten.

Daarna zou ik voor elke file in /lib die er niet thuishoort zorgen dat er geen symlink naar wijst, en hem dan verwijderen.

Installeer eens dlocate, en kijk eens wat

 dlocate /lib/libc-2.7.so

te zeggen heeft? Als die geen output geeft, dan is /lib/libc-2.7.so in geen enkel geinstalleerd Debian package gevonden, anders krijg je te horen in welk package die file gevonden is.

Als dat werkt dan zou je met

% for I in /lib/*; do if ! dlocate ${I} > /dev/null; then echo ${I}; fi; done

een lijst met files krijgen die niet in Debian packages gevonden zijn. Dat zijn dan de files die je moet inspecteren en mogelijk verwijderen. Als je er niet zeker van bent welke weg mogen en welke niet, dan mag je de filenames hier posten

Op mijn systeem gaf dat commando alleen /lib/cpp als output, dat is een symlink die blijkbaar niet geregistreerd staat.

Wat ook nuttig kan zijn is kijken naar de datum/tijd op de files in /lib. Te zien aan je ls -l output heb je op 4 november die make install gedaan

En vergeet niet ook de subdirectories van /lib te controleren, daar kunnen ook nog foute libs in staan.

vrijdag 4 januari 2008 19:08

Acties:

maleadt

Topicstarter

Inderdaad, de ldconfig uitleg maakt het geheel weer logisch

Anyway, ik heb juist voor je postte nog wat updates toegevoegd aan m'n vorige post (toegegeven, een nieuwe post was misschien beter op zijn plaats voor wat mogelijk een oplossing is), maar zoals je aanraadde heb ik alle 2.7-so libs verplaatst ("statische" WinSCP in aanslag om het geheel weer ongedaan te maken), en alles lijkt te werken

De output van je dlocate verificatie maakt me helemaal gerust, enkel de verplaatste 2.7 libraries (en de talloze tls.oldXX mapjes

) worden als ongekend gemarkeerd.

En nu de locales nu weer werken, geloof ik er nog meer in. Nu nog enkele dagen testen op stabiliteit, wat pakketten installeren en upgraden, en zien of alles blijft werken.

maleadt

vrijdag 4 januari 2008 19:31

Acties:

deadinspace

The what goes where now?

Mooi dat het weer goed is, nu hopen dat dat zo blijft