Thomas Hertweck writes:

...

[...] Und zwar zieht sich das Upgrade selbst den Boden unter den Füßen weg, es versucht (als ca. 10. rpm der 270) glibc 2.3.2 zu installieren, und sobald dieses Installiert ist funktioniert rpm (Segmention fault) nicht mehr --> tot.

Du versuchst ein Upgrade des laufenden Systems zu machen, das _kann_ nicht funktionieren. Um ein Upgrade zu machen, muss man natuerlich extern booten (nicht das auf der Festplatte installierte System),

"Natürlich" ist das nur bei SuSE. Debian GNU/Linux und NetBSD kann ich hervorragend remote aus dem laufenden System heraus updaten. Jetzt habe ich hier weiter oben den Link zu apt gesehen. Funktioniert das? Hat jemand damit schonmal remote eine SuSE-Box auf den laufenden Stand gebracht? Oder muß ich doch 200km fahren? Martin

Martin Schmitz [Sa, 03 Apr 2004 22:51:11]:

"Natürlich" ist das nur bei SuSE. Debian GNU/Linux und NetBSD kann ich hervorragend remote aus dem laufenden System heraus updaten.

Was in diesem Fall daran liegt, dass weder Debian noch NetBSD rpm benutzen. Aber *alle* pseudostatisch [1] gelinkten Programme funktionieren auf einem glibc2 basierten System nach einem Update der glibc von 2.2.X auf 2.3.X nicht mehr, da sich hier das ABI (die binäre Schnittstelle) für die libnss* geändert hat. Philipp [1] Pseudostatisch nenne ich Programme, die statisch gelinkt sind, aber Funktionen zur Namensauflösung wie gethostyname(3) oder getpwnam(3) verwenden. Diese Funktionen werden seit glibc2 *immer* (also auch bei einem statisch gelinkten Programm!) durch dynamisch geladene Bibliotheken zur Verfügung gestellt, da sich nur so die NSS-Funktionalität (dynamisch über /etc/nsswitch.conf konfigurierbare Wege zur Namensauflösung) realisieren lässt. Seit glibc2 dürfen statisch gegen sie gelinkte Programme keinerlei Funktionen zur Namensauflösung mehr verwenden, wenn sie wirklich statisch, sprich unabhängig von der verwendeten Version der glibc sein sollen. PS: Unter Solaris (die Idee für NSS stammt von Sun) lässt sich solch ein Programm gar nicht erst linken.

Manfred Tremmel writes:

Am Samstag, 3. April 2004 22:51 schrieb Martin Schmitz:

...

"Natürlich" ist das nur bei SuSE. Debian GNU/Linux und NetBSD kann ich hervorragend remote aus dem laufenden System heraus updaten.

Auch bei einem glibc Update? Ich kann mir ehrlich gesagt nicht vorstellen, wie das System nach so nem Update noch in einem stabilen Zustand sein könnte. Selbst wenn Debian das Update durchbringt, dürfte zumindestens ein Neustart fällig werdn.

Wie Debian das macht, weiß ich nicht so genau. NetBSD hat keine glibc, sondern eine eigene libc. Außerdem gibt es dort kein /etc/nsswitch.conf. Gegen einen Neustart habe ich übrigens nichts einzuwenden. Nur eine CD läßt sich so schwer remote einlegen. Wenn es eine Möglichkeit gäbe, den SuSE-Installer von der Platte zu booten und remote darauf zuzugreifen hätte ich auch nichts dagegen. Aber so ist das irgendwie untragbar. :-(

...

Jetzt habe ich hier weiter oben den Link zu apt gesehen. Funktioniert das? Hat jemand damit schonmal remote eine SuSE-Box auf den laufenden Stand gebracht? Oder muß ich doch 200km fahren?

Apt wird an der Problematik, dass nach einem glibc Update rpm nicht mehr funktioniert nichts ändern können.

Ok, das hab' ich zumindest verstanden. Martin

Am Sonntag, 4. April 2004 03:42 schrieb Philipp Thomas:

Manfred Tremmel [So, 4 Apr 2004 00:15 +0200]:

...

Auch bei einem glibc Update? Ich kann mir ehrlich gesagt nicht vorstellen, wie das System nach so nem Update noch in einem stabilen Zustand sein könnte.

Glibc ist, vor allem durch die Verwendung versionierter Symbole (symbol versions), abwärtskompatibel! Solange also keine Schweinereien wie die Verwendung interner Glibcfunktionen bzw. -Variablen oder eben statisch gelinkte Programme mit Aufruf von Funktionen zur Namensauflösung vorkommen, ist i.d.R. der Update der glibc kein Problem.

Ok, wenn Du das sagst ... Ich für meinen Teil hatte bei glibc Updates bisher immer Ärger. Nach dem gestrigen Update glibc 2.3.2 -> 2.3.3 z.B. raucht mir Cups auf meinem PowrBook immer ab (gut, in der Regel druck ich eh nicht von der Kiste), vielleicht behebt ein recompile mit gcc 3.3.3 (der compiliert gerade - der vierte Versuch, immerhin weiß ich jetzt, dass zu viele includes unter /usr/include zu Fehlern in Stage2 führen, wieso ein 'make -C gcc gnatlib' adaint.o, argv.o, cio.o, cstreams.o, tracebak.o, exit.o, raise.o, init.o und adafinal.o unter gcc/ada/rts sucht, wo die doch unter gcc/ada liegen, ist mir noch ein Rätsel, ein paar symlinks sollten helfen). Von meinen 2.0 -> 2.1 oder 2.2 -> 2.3 Erfahrungen will ich erst gar nicht reden.

...

Selbst wenn Debian das Update durchbringt, dürfte zumindestens ein Neustart fällig werdn.

Nö, das geht durchaus auch ohne :) Aber man muss schon sehr genau wissen, wann man es machen kann und wann nicht.

Ok, für jemanden der, wenn er um drei Uhr nachts aus dem Bett geholt wird, die Maschinencodes jedes IA32 Prozessors mit ihren Laufzeiten, die Latenzzeiten von Level 1 und 2 Cache vorsingt und dir den Kernel im laufenden Betrieb im Hauptspeicher austauscht, ohne die Kiste neu zu starten, mag das schon möglich sein, ich trau mir das nicht zu, würde es also auch nicht weiterempfehlen. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de