PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : [ Problem ] - Suse 8.1 update der glibc



weissnet
25.09.04, 08:52
Moin!

Ich habe hier gerade ein Problem bei dem ich nicht weiterkomme.
Ich habe hier ne Server-Maschine, auf der wurde die glibc auf version 2.3.2 geupgraded.
Ja, ich weiß glibc ... wichtigste und am meisten benutze/benötigte Komponente nach dem Kernel und überhaupt die kritischte Komponente was updates angeht ...
Wie auch immer, ich versuche ja nur die Maschine zu retten ... erschwerend kommt hinzu das ich bisher nur einmal Suse überhaupt in den Fingern hatte und das war version 4.3 vor 7 oder 8 Jahren ... vielleicht fällt ja irgendwem ein Kardinalfehler in meinem Vorgehen auf, oder es gibt noch mehr Möglichkeiten (last resort wird wohl die Neuinstallation sein ... das wird bei einem Server in irgendeinem RZ fern der Heimat aber entweder recht kostspielig oder recht mühsam)

Also:
Nachdem der Server rebootet wurde ging fast nix mehr ... Aufgefallen ist es dadurch, das der Teamspeak-Server den Start mit nem SegFault verweigert.
Ich gehe davon aus, dass irgendeine Inkompatibilität zwischen den Libs herrscht.
Ja, Teamspeak ist auf Kylix gebaut, und Kylix hat viele Probleme, aber als ich mir das genauer ansehen wollte fingen die Probleme ja erst an.
Wollte also gdb installieren, weil der strace hier leider keine Rückschlüsse erlaubt.
rpm -U gdb-5.3-51.i586.rpm terminierte mit nem SegFault

Da Glibc das einzige war was geändert wurde:
rpm -qa | grep glibc => SegFault
rpm -qi glibc => glibc-2.3.2
rpm -V glibc-2.3.2-6.i586.rpm => the package is not installed
rpm --rebuilddb => OK
rpm -V glibc-2.3.2-6.i586.rpm => the package is not installed
(wurde aber installiert mit yast -i glibc-2.3.2-6.i586.rpm ... vermutlich ist das schon die Wurzel des Problems)

alle straces (auf rpm und teamspeak) protokollierten mehr oder weniger unmittelbar vor dem SegFault aber immer als letzte geladene Lib libs aus /lib/gconv (also aus glibc-locale)

Zwischendurch ging auch mal kurz ein rpm -qa bei dem ich herausfand, das glibc-devel und glibc-locale nicht mitgeupdatet wurde und noch Version 2.2.5 tragen.
Also:
rpm -Fvh --test glibc-locale-2.3.2-6.i586.rpm glibc-devel-2.3.2-6.i586.rpm => SegFault
ohne --test dasselbe
rpm -U --oldpackage --test glibc-2.2.4-163.i586.rpm => SegFault

jeder Versuch den Paket-Manager im yast aufzurufen (und wenns nur zum gucken nach Inkonsistenzen ist) resultiert in 98% CPU-Auslastung und kehrt nicht wieder. Versuche die Pakete ebenfalls mit yast via Kommando-Zeile zu installieren werden mit O-Ton "Package not found on source" quittiert. Jeder Versuch die Installationsquelle zu ändern reultiert ebenfalls in 98% CPU-Auslastung ohne wiederkehr.

Hab dann also die glibc-Sourcen von ftp.gnu.org gesaugt, gebaut und dann in /usr/local/lib installiert.
Dann noch entsprechend /etc/ld.so.conf geprüft ob /usr/local/lib eingetragen ist und in /etc/profile ein
LD_LIBRARY_PATH=/usr/local/lib
export LD_LIBRARY_PATH
ergänzt.
Weil ich dachte, ich könnte so das System überreden temporär jetzt den komplett gebauten und konsistenten glibc-Stand zu verwenden, und dann so die rpms glattziehen.
Allerdings geht auch das irgendwie nicht ... immernoch SegFaults wie bisher und im strace stehen immernoch die libs aus /lib/gconv.

Installierten Kernel ist 2.4.23 (mit gcc 2.95-irgendwas gebaut).
Installierter GCC ist 3.3.2
Proz ist ein P4 1800

Danke schonmal fürs lesen :D

PS: Die Daten sind so aus der Erinnerung, war dann doch schon spät geworden gestern und jetzt habe ich gerade keinen Zugriff auf das System ...

PPS: Würde es vielleicht etwas bringen, zu versuchen das System mit apt4rpm wieder konsistent zu bekommen, oder benutzt apt dann unter der Haube dann auch nur wieder rpm.
Was mich beim rpm etwas wundert, ist, dass es ja eigentlich statisch gelinkt ist (ldd bestätigt das), also eigentlich unabhängig von (nicht) installierten libs sein sollte aber trotzdem nach dem glibc-update nicht mehr richtig läuft.

Die alte glibc ist natürlich auch nicht mehr drauf, und läßt sich demnach auch nicht durch ein Umsetzen von links reaktivieren, kann man ein rpm auch einfach so entpacken, dann könnte man ja die links in ein alternatives lib-Verzeichnis. legen ...

RichieX
25.09.04, 10:37
Ein ähnlich geartetes Problem hatte ich auch schon mit einer SuSE 7.3, ist aber schon etwas länger her. Damals musste ich auch irgenwie die glibc updaten, da ein anderes Paket diese benötigte - fataler Fehler wie sich dann herausstellte. Ich weiss noch, dass die einzigste Möglichkeit zur Rettung das System war, mit einer Rettungs-CD hochfahren und dann versuchen das System wieder in einen stabilen Zustand zu bringen. Bei dir macht diese Methode aber wenig Sinn (Remote) :(

RichieX