Upgrade 8.1 --> 8.2/9.0
Hallo! Ich hab ein kleines Problem mit dem Upgrade (per Yast2 über eine SSH shell) von Suse 8.1 auf 8.2 oder 9.0, bei beiden das gleiche. 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. Mit einem --nodep deinstallieren des glibc 2.3.2 und eines installieren des alten 2.2.5 von Suse 8.1 kann ich rpm dann wiederbeleben. Dieses Verhalten des Upgrade ist identisch bei einem Upgrader auf 8.1 oder 9.0, beide wollen glibc updaten und hängen dannach. Irgendeine Idee? Danke und cu
Hallo Mekonikum, ein Realname wäre wünschenswert und wird hier gerne gesehen. Am Samstag, 3. April 2004 21:56 schrieb Mekonikum:
Ich hab ein kleines Problem mit dem Upgrade (per Yast2 über eine SSH shell) von Suse 8.1 auf 8.2 oder 9.0, bei beiden das gleiche.
Ein derartiges System-Upgrade läßt sich nicht über YaST online machen. Normalerweise sollte man dies von einer CD machen. Es gibt jedoch eine Möglichkeit dies mit "apt-get" zu machen. http://www.geocities.com/tanjakostic/linux/upgrade-82to90.html hth ... Martin -- Proud Member of the Forte Agent Beta Team http://www.forteinc.com/
Mekonikum wrote:
[...] 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), entsprechende Boot-Images gibt es zum Download... Prinzipielle Vorgehensweise steht auch in der SDB[1] erklaert. CU, Th. [1]http://portal.suse.com/sdb/de/1998/01/lmuelle_suselinux_internet.html PS: Bitte schraenke Deine Zeilenlaenge auf ein ertraegliches Mass von ca. 70 Zeichen ein und verwende einen Realnamen zum Posten, siehe Etikette dieser Liste.
Thomas Hertweck <Thomas.Hertweck@gpi.uni-karlsruhe.de> 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
Hallo, 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. 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?
Ich selber habe das noch nicht gemacht, da ich auf Servern grundsätzlich Debian den Vorzug gebe. Jedoch scheint der Schöpfer des Artikels dies bereits getan zu haben und das erfolgreich, wenn auch steinig. bis dahin Martin -- Proud Member of the Forte Agent Beta Team http://www.forteinc.com/
Martin Schmitz <martin@msitc.dyndns.org> [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.
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.
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. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Manfred Tremmel <Manfred.Tremmel@iiv.de> 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
Manfred Tremmel <Manfred.Tremmel@iiv.de> [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.
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. Philipp
Am Sonntag, 4. April 2004 03:42 schrieb Philipp Thomas:
Manfred Tremmel <Manfred.Tremmel@iiv.de> [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
Manfred Tremmel <Manfred.Tremmel@iiv.de> [4 Apr 2004 13:43:39 +0200]:
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),
Uuups, nicht nett.
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,
Also ich gehöre definitiv nicht zu den oben genannten Personen, und es hat Fälle gegeben, da habe ich es gewagt, im laufenden Betrieb zu wechseln. Aber i.d.R. boote ich auch vom Rettungssystem, um die glibc auszutauschen.
ich trau mir das nicht zu, würde es also auch nicht weiterempfehlen.
Empfehlen würde ich das auch nicht, dazu kann man sich viel zu schnell das System zerschiessen. Philipp
participants (6)
-
Manfred Tremmel -
Martin Mewes -
Martin Schmitz -
Mekonikum -
Philipp Thomas -
Thomas Hertweck