Versions-Problem glibc/glibc-devel

[Discipulus]

Hallo zusammen

Als ich heute wieder einmal Yast startete (auf einem SLES8) und ein neues Paket installieren wollte, wurde ich auf ein dependency-problem aufmerksam gemacht, was mir gar nicht gefällt.
Zusammengefasst meldete mir Yast, dass glibc-devel (sowie lsb-runtime) das Paket glibc-2.2.5 benötigt.

rpm -qa | grep ergibt:
glibc-i18ndata-2.2.5-235
glibc-2.3.5-40
glibc-devel-2.2.5-235
glibc-locale-2.3.5-40

Da hat sich eine neue Version von glibc eingeschlichen.
Soviel ich weiss, kommt es selten gut wenn die glibc aktualisiert wird.
Wurde dieses Paket von Suse eingespielt (autoupdate)? Erscheint mir merkwürdig.
Jedenfalls stellt sich mir die Frage wie ich dieses Problem am besten löse.
Downgrade von glibc-2.3.5 auf "original" 2.2.5 oder update der anderen Pakete auf 2.3.5?
Gibt es irgendwas zu beachten bei einem downgrade? Können Probleme auftreten?

Danke

[Discipulus]

Hilfe?

(Sorry wegen Doppelpost)

[traffic]

Durchsuch mal die Datei /var/log/YaST2/y2logRPM nach "glibc".

Und lass es im Zweifelsfall einfach, wie es ist, wenn das System läuft und Du unsicher bist.

Zum eigentlichen Problem: Ein glibc-Upgrade aus Binärpaketen ist normalerweise weniger gefährlich, als man denkt. Was man lieber nicht machen sollte, ist der Versuch, die glibc durch eine selbstkompilierte zu ersetzen.

Nur eines ist nicht besonders gut: Ein Downgrade. Upgrades sind nicht gefährlich unter der Voraussetzung, dass die Pakete wirklich vom Distributor stammen und nicht von irgendwo anders.

Was mich noch interessieren würde, wäre die Ausgabe von

rpm -qi glibc | head
rpm -qi glibc-devel | head
um zu bestimmen, woher die Pakete kommen.

[Discipulus]

Erstmal danke für die Antwort.
Hier die Ausgabe von "cat /var/log/YaST2/y2logRPM | grep glibc":

glibc-i18ndata-2.2.5-163.i586.rpm installed ok
glibc-2.2.5-164.i686.rpm installed ok
glibc-locale-2.2.5-163.i586.rpm installed ok
glibc-devel-2.2.5-163.i586.rpm installed ok
glibc-2.3.5-40.i686.rpm installed ok
execution of glibc-2.2.5-235 script failed, exit status 1
glibc-locale-2.3.5-40.i586.rpm installed ok
glibc-devel-2.3.5-40.i586.rpm failed
glibc-devel-2.3.5-40.i586.rpm failed

Das heisst also, dass glibc-2.3.5-40 wirklich von YaST installiert wurde, die gleiche Version von glibc-devel jedoch aus irgend einem Grund nicht installiert werden konnte!?

rpm -qi glibc | head:

Name : glibc Relocations: (not relocateable)
Version : 2.3.5 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
Release : 40 Build Date: Fri Sep 9 19:37:21 2005
Install date: Thu Aug 17 23:07:15 2006 Build Host: belana.suse.de
Group : System/Libraries Source RPM: glibc-2.3.5-40.src.rpm
Size : 7664786 License: GPL, LGPL
Packager : http://www.suse.de/feedback
URL : http://www.gnu.org/software/libc/libc.html
Summary : Standard Shared Libraries (from the GNU C Library)

rpm -qi glibc-devel | head:

Name : glibc-devel Relocations: (not relocateable)
Version : 2.2.5 Vendor: UnitedLinux LLC
Release : 235 Build Date: Thu Jan 26 15:19:22 2006
Install date: Thu Jul 20 10:39:07 2006 Build Host: boltzmann.suse.de
Group : Development/Libraries/C and C++ Source RPM: glibc-2.2.5-235.src.rpm
Size : 42101069 License: LGPL, BSD
Packager : http://www.unitedlinux.com/feedback
URL : http://www.gnu.org/software/libc/libc.html
Summary : Libraries for the C compiler


Bei der Ausgabe von glibc ist mir etwas aufgefallen:
Distribution: SUSE LINUX 10.0 (i686)

Ich setze aber SLES-8.1 ein.
Kann es sein das im Yast falsche Installation-Sources angegeben wurden und daher das neue Paket kommt?

Würdest ihr nun ein Downgrade der glibc oder ein Upgrade der glibc-devel, glibc-i18ndata und lsb-runtime vorschlagen?

[traffic]

Jo. glibc ist falsch. Ich erkenne das gleich hieran:

glibc
Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany

glibc-devel
Vendor: UnitedLinux LLC

Dort sollte eigentlich überall "UnitedLinux LLC" stehen.

Überprüf mal die Installationsquellen, da ist offenbar wirklich eine verkehrte "reingerutscht" (natürlich nicht von alleine, aber wer weiß warum...)

Mit dem Downgrade ist das jetzt etwas schwierig. Die verkehrte glibc muss ja aus irgendeinem Grund installiert worden sein, wahrscheinlich weil jemand (wer?) ein Programm installieren wollte, das die neuere glibc braucht. Das Downgrade wird dann dazu führen, dass dieses Programm nicht mehr läuft, die Original-Programme aber schon.

Probier mal:

rpm -e --test glibc 2>&1 | grep '2\.3'
rpm -e --test glibc 2>&1 | grep '2\.2\.6'
"Eigentlich" besser wäre das Downgrade auf die Original-Versionen vom SLES8, aber ohne zu wissen, wer das Paket warum installiert hat, würde ich es fast eher so lassen wie es ist und den Konflikt ignorieren.

[Discipulus]

Bei den Installations-Sourcen war ein Pfad auf openSUSE dabei, welcher natürlich nicht sein sollte.
Ich habe das System leider übernommen, daher weiss ich nicht woher dieser Eintrag kommt, werde den aber entfernen.

Hier die Ausgaben der RPM-Tests:

rpm -e --test glibc 2>&1 | grep '2\.2\.5'

glibc = 2.2.5 is needed by lsb-runtime-1.2-105
glibc = 2.2.5 is needed by glibc-devel-2.2.5-235
ld-linux.so.2 is needed by glibc-devel-2.2.5-235
ld-linux.so.2 is needed by timezone-2.2.5-235
libc.so.6 is needed by glibc-devel-2.2.5-235
libc.so.6 is needed by timezone-2.2.5-235
libc.so.6(GLIBC_2.0) is needed by glibc-devel-2.2.5-235
libc.so.6(GLIBC_2.0) is needed by timezone-2.2.5-235
libc.so.6(GLIBC_2.1) is needed by glibc-devel-2.2.5-235
libc.so.6(GLIBC_2.1) is needed by timezone-2.2.5-235
libdl.so.2 is needed by glibc-devel-2.2.5-235
libdl.so.2(GLIBC_2.0) is needed by glibc-devel-2.2.5-235
libdl.so.2(GLIBC_2.1) is needed by glibc-devel-2.2.5-235
glibc = 2.2.5 is needed by lsb-runtime-1.2-105
glibc = 2.2.5 is needed by glibc-devel-2.2.5-235
rpm -e --test glibc 2>&1 | grep '2\.3\.5'

glibc = 2.3.5 is needed by glibc-locale-2.3.5-40
libc.so.6 is needed by glibc-locale-2.3.5-40
libc.so.6(GLIBC_2.0) is needed by glibc-locale-2.3.5-40
libc.so.6(GLIBC_2.1) is needed by glibc-locale-2.3.5-40
libc.so.6(GLIBC_2.1.3) is needed by glibc-locale-2.3.5-40
glibc = 2.3.5 is needed by glibc-locale-2.3.5-40


Mir sagt diese Ausgabe, dass glibc 2.3.5 weniger Abhängigkeiten hat, vor allem nur auf glibc-locale-2.3.5, was verständlich ist, daher sollte ich wohl einen Downgrade von glibc-2.3.5 sowie glibc-locale-2.3.5 wagen ...?

[Discipulus]

Ich habe nun glibc sowie glibc-locale in der Version 2.2.5 installiert.

Dazu musste ich über eine Live-CD gehen, da ich die Pakete irgendwie nicht im laufenden Betrieb installieren konnte.

Nach langem Suchen nach einer Live-CD die mein Raid-Controller unterstützt (schlussendlich mit Scientific Linux), habe ich die zwei Pakete mit folgendem Befehl installiert:

rpm --root /mnt/sda2 -Uvh --oldpackage --nodeps /mnt/sda2/.../glibc-2.2.5... /mnt/sda2/.../glibc-locale-2.2.5...

Dies hat dann auch funktioniert.
Aber zu früh gefreut!
Beim ersten Boot ins System mit der "alten" glibc erhielt ich nur Fehlermeldungen die etwa meinten:
GLIBC_PRIVATE not set/not found
GLIBC_2.3 not set/not found

Die genaue Meldung weiss ich nicht mehr.

Gibt es noch eine Chance dieses System zu retten oder stehe ich vor einer unausweichlichen Neuinstallation?

Danke für schnelle Hilfe :(

[bla!zilla]

Also SUSE pumpt über YOU keine neue GlibC auf einen SLES. Gut möglich das der über die OpenSUSE Quelle reingekommen ist.

[Discipulus]

Danke für deine Info.

Ich dachte mir bereits dass die neue glibc nicht nicht über ein Update installiert wurde.

Ich habe eine falsche Quelle im Yast gefunden. So wie es aussieht wurde die neue glibc installiert, als eine Abhängigkeit aufgelöst wurde (ruby) welche von der falschen Quelle installiert wurde.

Mein grosses Problem ist nun, dass das System nicht mehr startet (Abbruch mit oben beschriebener Meldung)

[Discipulus]

Ich habe das System nun neu installiert, daher ist das Problem "behoben".

Habe bereits ein neues, werde dazu aber einen neuen Beitrag machen.

Danke für eure Hilfe

[RichieX]

Und lass es im Zweifelsfall einfach, wie es ist, wenn das System läuft und Du unsicher bist.

Hab diesen Thread erst jetzt gesehen. Diese Aussage hättest du wirklich ernst nehmen sollen. Don't touch running systems. Ein Problem hättest du natürlich irgendwann bei den nächsten Updates gehabt. Ich hatte vor Jahren auch schon mal ein ähnliches Desaster (was, wie bei dir ursprünglich keins war). Am Ende hab ich auch neu installiert. ;)

RichieX

[Discipulus]

Wäre warscheinlich besser gewesen, dass System so zu lassen wie es war.
Habe den Tipp von traffic irgendwie übersehen :D

Ich musste jedoch ein neues Paket installieren/kompilieren. Dies war jedoch nicht möglich mit dem Version-Mismatch. Daher musste das Problem gelöst werden, was es jetzt ja irgendwie ist ... leider auf eine unschöne weise, aber ja...