![](https://seccdn.libravatar.org/avatar/8c3c40c634277ad02bc114e708b7577d.jpg?s=120&d=mm&r=g)
Hallo David, wie gut, dass es Dich gibt. Am Dienstag 17 März 2009 schrieb David Haller:
Am Mon, 16 Mär 2009, Helga Fischer schrieb:
Am Montag 16 März 2009 schrieb Helga Fischer:
Am Montag 16 März 2009 schrieb David Haller:
[..]
zu prüfen u.a. mit 'rpm -Vf /lib/libzypp.so.dingens' und löschen
Meinst Du wirklich, den ganzen Verzeichnisbaum unter /var/cache/zypp löschen?
Äh, was genau hab ich nicht geschaut, IIRC aber ja.
Hab' ihn halt umbenannt. Das Ergebnis nach einem zypper refresh war immer eine leere Datenbank. [...]
oder 'catchsegv zypper ...' laufenlassen um zu gucken, ob der Segfault in der libzypp auftritt. Aber viel mehr als libzypp und libc gibt's da nicht.
Den habe ich mal unter http://www.eschkitai.de/tmp/catchsegv-zypper geparkt. Ich kann damit nichts anfangen.
Ich schon. Welche SUSE hast du nochmal?
10.3 (und die möchte ich auch noch eine ganze Weile benutzen, bis meine HW auch unter 11.1 läuft und meine Lieblingsapplikationen entweder portiert wurden oder ich einen adäquaten Ersatz gefunden habe).
Unter der 11.1 hab ich hier die libzypp.so.523.2.3, die tut's.
Der zypper ist eine ganz andere Versionsnummer.
Jedenfalls, wenn ich mich nicht irre wird der Segfault beim Zusammenspiel von libzypp und libsqlite3 verursacht, und zwar wohl beim Zugriff auf den Cache von libzypp(!).
sqlite3 ging mir auch so als Verdächtiger durch den Kopf. Das war nämlich eines der letzten Pakete, die sich dem Update entzogen. Das löste sich zwar dann ohne Zwang irgendwann mal auf, aber ich meine, danach war das Problem mit dem zypper da.
Schau dir mal im "Backtrace:" die lesbaren Teile der Funktionen (von unten her beginnend) an...
zypp RepoManager buildCache ... zypp cache CacheInitializer ... [was aus der libboost] sqlite3x sqlite3_connection ... sqlite3x sqlite3_connection resetprogresshandlerEv [PENG]
OK, ich guck' noch mal rein.
D.h. -> Cache von Zypp kapott -> s.o., Cache wird bei 'zypper ref' wiederhergestellt. Evtl. reicht auch statt dem "manuellen" löschen der Caches ein 'zypper clean'.
Bei mir wird gar nichts mehr neu aufgebaut. Die zypp.db enthält lediglich die Tabellendefinitionen, die knoda gar nicht auslesen kann. Dazu mußte ich kwrite nehmen. Die alte zypp.db läßt sich mit knoda öffnen und ich kann da auch in den Tabelleninhalten 'spazieren gehen'.
Falls das mit dem Cache nicht hilft wären die Kandidaten für Up-/Downgrades dann: libzypp, libboost*, libsqlite3.
Ja, da werde ich wohl nicht drum rum kommen, nachdem ein Update der libzypp nicht geholfen hat. Und ein Neueinspielen vom zypper auch nicht.
Genaue Pakete:
rpm -qf /usr/lib/libsqlite3.so.0.8.6 \ /usr/lib/libboost_filesystem.so.1.33.1 \ /usr/lib/libboost_regex.so.1.33.1 \ /usr/lib/libzypp.so.324.3.3
Über Abhängigkeiten dürften noch Pakete dazukommen (sqlite3-devel, sqlite3 etc).
Das Geschäft lasse ich mir für heute Abend ;). Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org