rpm db fehler (nicht vorhanden, rebuild nicht möglich)

[kenny_2008]

Hallo Linux Community,
bin nicht nur neu hier im Forum sondern hab zum ersten mal in meinem Leben mit Linux zu tun. Hab also kaum Erfahrung.

Es geht um ein PC mit Fedora 4. Soll mich jetzt um ein PC kümmern, bei dem keine Installationen möglich sind.

bisher habe ich herausgefunden:
es sind keine db dateien in dem verzeichnis /var/lib/rpm
(hat aber angeblich keiner gelöscht)
hab natürlich erstmal in foren/wikis und faqs gesucht und gefunden:

rpm --rebuild

leider kommt direkt darauf die meldung "Speicherzugriffsfehler". so auch bei rpm --initdb

und dann bin ich auch schon am ende meines lateins. ich weiss nicht was ich auf dem linux rechner nun alles überprüfen muss und was dort konfiguriert wurde. 1,5 gig ram (falls das mit speicher gemeint ist) insgesamt.
bitte seid gnädig, falls ich was übersehen habe, und ich wäre sehr dankbar, wenn ich eure lösungsvorschläge auch verstehen kann (bitte kein fachsimpeln :D )

danke im voraus für eure hilfe, bis morgen,
kenny

[Rain_maker]

und ich wäre sehr dankbar, wenn ich eure lösungsvorschläge auch verstehen kann

Kannst Du haben:

Nutzerdaten sichern und etwas _Aktuelles_ neu installieren, alleine schon weil FC4 schon so tot ist, daß es nicht mal mehr stinkt.

[kenny_2008]

^^ naja bisher hieß es bei dem pc "don't change a running system"

nur jetzt ist halt was kaputt also muss es gefixt werden :)

Wo finde ich denn die Nutzerdaten? Bei Windows würde ich einfach Eigene Dateien sichern... Alles aus dem /home verzeichnis?
und etwas neues installieren, meinst du IRGENDwas oder etwas was schon drauf ist einfach eine neue version? oder fedora einfach erneuern? hab vorhin gelesen, dass man ab fedora 9 einfach drüberinstallieren kann, sozusagen aktualisieren.

aber wenn die rpm datenbank nicht da ist, und zudem ein speicherzugriffsfehler besteht, wie kann dann überhaupt etwas installiert werden?

[Rain_maker]

^^ naja bisher hieß es bei dem pc "don't change a running system"

Und was ist an dem System noch "running"?

Support ist vor Jahren ausgelaufen, auf einem toten Pferd kann auch der beste Cowboy nicht nach Westen reiten.



Wo finde ich denn die Nutzerdaten? Bei Windows würde ich einfach Eigene Dateien sichern... Alles aus dem /home verzeichnis?

Ja, ggf. noch /etc aber nicht zum direkten Zurückspielen, sondern um ggf. eine Vorlage für die neuen Konfigurationen zu haben.



und etwas neues installieren, meinst du IRGENDwas oder etwas was schon drauf ist einfach eine neue version? oder fedora einfach erneuern? hab vorhin gelesen, dass man ab fedora 9 einfach drüberinstallieren kann, sozusagen aktualisieren.

Man _kann_ jede Distribution aktualisieren, aber über mehrere Versionen hinweg geht um so eher schief, je mehr Versionen man überspringen will, das kannst Du so oder so vergessen.



aber wenn die rpm datenbank nicht da ist, und zudem ein speicherzugriffsfehler besteht, wie kann dann überhaupt etwas installiert werden?

Das kommt noch hinzu, ich schrieb ja schon "neu installieren" und genau das war damit gemeint, ob das dann ein aktuelles Fedora oder etwas Anderes wird, ist Deine Entscheidung.

[kenny_2008]

Vielen Dank für deine schnellen Antworten! Super Forum hier :)

Ich hab das jetzt so vorgeschlagen.
Eine Neuinstallation ist wohl keine Option, da das System nur kurzzeitig down sein darf und die Desktop Version zur Server Version umkonfiguriert wurde. Angeblich "wochenlange" Einstellungen am Networker wurden gemacht und andere Konfigurationen wie sendmail etc. (natürlich nichts dokumentiert).

weitere Ansätze sind evtl:
liegt ein Library Fehler vor?
ist Hardware defekt?
wurde Speicher falsch zugewiesen?
falsche Verlinkungen?

Was macht davon Sinn und wie gehe ich das Problem jetzt an, wenn ich nicht neuinstallieren soll und auch nicht parallel ein gleiches System aufsetzen kann, da keine HW zur Verfügung steht und die wochenlange Konfig nicht nochmal sein soll.

THX

//edit:

ist hier vielleicht etwas vermurkst?

cat meminfo
MemTotal: 1555940 kB
MemFree: 1052248 kB
Buffers: 39116 kB
Cached: 400280 kB
SwapCached: 0 kB
Active: 208668 kB
Inactive: 250180 kB
HighTotal: 655344 kB
HighFree: 335892 kB
LowTotal: 900596 kB
LowFree: 716356 kB
SwapTotal: 5242872 kB
SwapFree: 5242872 kB
Dirty: 196 kB
Writeback: 0 kB
Mapped: 33832 kB
Slab: 18268 kB
CommitLimit: 6020840 kB
Committed_AS: 61252 kB
PageTables: 1284 kB
VmallocTotal: 114680 kB
VmallocUsed: 14688 kB
VmallocChunk: 98804 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 4096 kB

cat swaps
Filename Type Size Used Priority
/dev/mapper/vg_hdd01-lv_swap partition 5242872 0 -1

free -m -t
total used free shared buffers cached
Mem: 1519 492 1027 0 38 390
-/+ buffers/cache: 62 1456
Swap: 5119 0 5119
Total: 6639 492 6147

[pferdefreund]

Der Speicherzugriffsfehler entsteht vermutlich daher, daß das Programm
rpm keine Daten hat - rpm geht eventuell einfach davon aus, dass die
rpm-dbs da sind und dann ist der filepointer NULL und schon knallts.
Aber wenn das System schon so alt ist und quasi das Herz hinüber ist, dann hilft
wirklich nur eine Neuinstallation. Gibts eventuell Backups - wenn ja, wie lange,
wenn lange, welche, wo under /var die rpm-dbs noch da sind - eventuell mal
die zurückladen - Versuch macht klug

[kenny_2008]

Aber rpm rebuild bzw initdb ist doch gerade dafür da, die db neu zu erstellen oder nicht? Somit müssen diese Befehle doch davon ausgehen, dass sie nicht exisiteren oder beschädigt sind.

Backups gibt es zwar, reichen aber leider nicht weit genug zurück.

Ich würde gerne alles mögliche untersuchen wie es zum speicherzugriffsfehler kam und was man dagegen tun kann. zb kann ich mir gut vorstellen, dass jemand unerfahrenes (wie ich *gg*) an irgendwelchen dateien gebastelt hat ohne die auswirkungen zu kennen. bloß muss ich dazu wissen was alles mit rpm der rpmdb und dem speicher zu tun hat. stehe leider immer noch bei 0.

mag sein dass fedora 4 uralt ist (naja 1 1/2 jahre älter als windows vista...), aber da es alles mal funktioniert hat, warum sollte man da nicht den fehler finden können.

Aber wenn ihr sagt bei der fehlermeldung "speicherzugriffsfehler" KANN MAN NICHTS unternehmen, keine chance, nur neuinstallation, dann lass ich euch in ruhe :rolleyes:

[Rain_maker]

<Dr. McCoy Modus>
Herrgott Jim, ich bin Arzt und kein Totengräber!
</Dr. McCoy Modus>

:-)

[undefined]

Aber rpm rebuild bzw initdb ist doch gerade dafür da, die db neu zu erstellen oder nicht? Somit müssen diese Befehle doch davon ausgehen, dass sie nicht exisiteren oder beschädigt sind.
Nein RPM Rebuild macht ein rebuild auf eine Vorhandene Struktur.
Weil es sich aber dabei um ein Berkley DB Handelt kannst die Struktur auch wieder von Hand herstellen. Das wird dir in diesen fall auch nichts bringen weil du einen Kompletten Datenverlust erlitten hast. Die Frage ist eher macht Fedora backups wie z.B. SuSE unter /var/adm/backups ?
Wenn ja dann kannst du Recovern. Wenn du ein RPM DB oberhalb von rpm >= 5.* hast dann gibt es das Verzeichnis /var/spool/repackage Dort kannst auch ein Rebuild machen.
EDIT: Wie stelle ich eine DB wieder her.


#!/bin/sh

mkdir -p /var/spool/repackage
mkdir -p /var/lib/rpm
for dbi in \
Basenames Conflictname Dirnames Group Installtid Name Packages \
Providename Provideversion Requirename Requireversion Triggername \
Filemd5s Pubkeys Sha1header Sigmd5 \
__db.001 __db.002 __db.003 __db.004 __db.005
do
touch /var/lib/rpm/$dbi
done

PS: Danach initdb und rebuild - Aber wie schon geschrieben wo nichts ist kann nichts hergestellt werden.

[stefan.becker]

Sind vielleicht die Platten / Partitionen voll?

Trotzdem neu machen, du kriegst keine Updates mehr für die Kiste.

Statt Neuinstallation besser nen neuen/anderen Rechner, Daten hinterher rüberkopieren. Dann kannst du den neuen Server erstmal testen und dann nachher ohne Zeitverlust in Betrieb nehmen.

[kenny_2008]

Also vielleicht habe ich was falsch verstanden,
ich dachte, dass ich keine Datenbank mehr habe, weil die __db* Dateien weg sind. Also folgende Dateien sind noch vorhanden:


cd /var/lib/rpm
Basenames Group Providename Requireversion
Conflictname Installtid Provideversion Sha1header
Dirnames Name Pubkeys Sigmd5
Filemd5s Packages Requirename Triggername

besteht also doch noch die DB?
wie ist die Situation dann zu beurteilen? Ist es doch nicht mehr soo aussichtslos? :o
und was sind dann die __db* Dateien?

RPM Version 4.4.1
kann ich trotzdem das skript benutzen um die DB wiederherzustellen?

Plattenplatz genügend vorhanden, vollste Partition ist /home mit 68%.

[undefined]

Ja du kannst mein Script verwenden weil es keine lösch Operationen ausführt.
Aber zuvor wie immer "Man weiss ja nie" ein Sicherung machen.
Es ist wichtig das touch und nicht ein zuweisungs Operator beim erstellen verwendet wird. Berkley DB mag das garnicht.
Im Prinzip benötigst du nur die for Schleife, von mir aus kannst du noch ein test -z einbauen.

was sind dann die __db* Dateien?
Das sind die Berkley Datenbank Dateien, du must also kein initdb ausführen

PS: Wenn die Files nicht zero oder 0 sind dann hast du eine reale Chance sie wieder her zu stellen.
Ich würde für meinen Teil auf jeden fall versuchen sie herzustellen.
Einen so alten Server macht man wegen den Ganzen Konfigurationen nicht platt.
Ich habe selbst noch zwei alte Server und sehe keinen Grund diese zu erneuern.

[kenny_2008]

ok habe das skript ausgeführt, jetzt existieren auch die db dateien:

-rw-r--r-- 1 rpm rpm 10113024 17. Mär 14:09 Basenames
-rw-r--r-- 1 rpm rpm 12288 17. Mär 14:09 Conflictname
-rw-r--r-- 1 root root 0 17. Mär 14:09 __db.001
-rw-r--r-- 1 root root 0 17. Mär 14:09 __db.002
-rw-r--r-- 1 root root 0 17. Mär 14:09 __db.003
-rw-r--r-- 1 root root 0 17. Mär 14:09 __db.004
-rw-r--r-- 1 root root 0 17. Mär 14:09 __db.005
-rw-r--r-- 1 rpm rpm 2408448 17. Mär 14:09 Dirnames
-rw-r--r-- 1 rpm rpm 10518528 17. Mär 14:09 Filemd5s
-rw-r--r-- 1 rpm rpm 28672 17. Mär 14:09 Group
-rw-r--r-- 1 rpm rpm 16384 17. Mär 14:09 Installtid
-rw-r--r-- 1 rpm rpm 49152 17. Mär 14:09 Name
-rw-r--r-- 1 rpm rpm 49123328 17. Mär 14:09 Packages
-rw-r--r-- 1 rpm rpm 352256 17. Mär 14:09 Providename
-rw-r--r-- 1 rpm rpm 126976 17. Mär 14:09 Provideversion
-rw-r--r-- 1 rpm rpm 12288 17. Mär 14:09 Pubkeys
-rw-r--r-- 1 rpm rpm 421888 17. Mär 14:09 Requirename
-rw-r--r-- 1 rpm rpm 237568 17. Mär 14:09 Requireversion
-rw-r--r-- 1 rpm rpm 159744 17. Mär 14:09 Sha1header
-rw-r--r-- 1 rpm rpm 81920 17. Mär 14:09 Sigmd5
-rw-r--r-- 1 rpm rpm 12288 17. Mär 14:09 Triggername

bloß immer noch der fehler

rpm --rebuilddb
Speicherzugriffsfehler
auch rpm --initdb gab den Speicherzugriffsfehler
wozu ist test -z da bzw. wie wende ich es an?

[undefined]

Ok dann machen wir uns jetzt erst mal eine Testumgebung


#!/bin/sh

set +x

mkdir -p $PWD/rpm
rm -rf $PWD/rpm/*

## wird von RPM erstellt wenn ein paket eingefügt wird
IST_RPM_DB="Packages"
for dbi in \
Basenames Conflictname Dirnames Group Installtid Name ${IST_RPM_DB} \
Providename Provideversion Requirename Requireversion Triggername \
Filemd5s Pubkeys Sha1header Sigmd5 \
__db.001 __db.002 __db.003 __db.004 __db.005
do
touch $PWD/rpm/$dbi
done

set -x

rpm --initdb --dbpath $PWD/rpm

rpm --rebuilddb --dbpath $PWD/rpm

rpm -qa --dbpath $PWD/rpm


Wenn dann immer noch Speicherfehler kommt liegt es an was anderem.

PS: kannst du als Standard Benutzer machen.

[kenny_2008]

Hm ich selbst verstehe das Skript nicht, dazu habe ich zu wenig Linux/Shell/Skript -Kenntnisse. Also hab ich das einfach mal copy pastet (wie auch das obige skript von dir) oder muss man da noch in einen bestimmten pfad? oder etwas beachten?

also hier die ausgabe (systemnamen habe ich durch XXYY ersetzt)


[root@XXYY ~]# set +x

[root@XXYY ~]#
rm -rf $PWD/rpm/*
[root@XXYY ~]# mkdir -p $PWD/rpm
[root@XXYY ~]# rm -rf $PWD/rpm/*

## wird von RPM erstellt wenn ein paket eingefügt wird
IST_RPM_DB="Packages"
for dbi in \
Basenames Conflictname Dirnames Group Installtid Name ${IST_RPM_DB} \
Providename Provideversion Requirename Requireversion Triggername \
Filemd5s Pubkeys Sha1header Sigmd5 \
__db.001 __db.002 __db.003 __db.004 __db.005
do
touch $PWD/rpm/$dbi
done

set -x

rpm --initdb --dbpath $PWD/rpm

rpm --rebuilddb --dbpath $PWD/rpm

rpm -qa --dbpath $PWD/rpm
[root@XXYY ~]#
[root@XXYY ~]# ## wird von RPM erstellt wenn ein paket eingefügt wird
[root@XXYY ~]# IST_RPM_DB="Packages"
[root@XXYY ~]# for dbi in \
> Basenames Conflictname Dirnames Group Installtid Name ${IST_RPM_DB} \
> Providename Provideversion Requirename Requireversion Triggername \
> Filemd5s Pubkeys Sha1header Sigmd5 \
> __db.001 __db.002 __db.003 __db.004 __db.005
> do
> touch $PWD/rpm/$dbi
> done
[root@XXYY ~]#
[root@XXYY ~]# set -x
++ echo -ne '\033]0;root@XXYY:~\007'
[root@XXYY ~]#
++ echo -ne '\033]0;root@XXYY:~\007'
[root@XXYY ~]# rpm --initdb --dbpath $PWD/rpm
+ rpm --initdb --dbpath /root/rpm
Speicherzugriffsfehler
++ echo -ne '\033]0;root@XXYY:~\007'
[root@XXYY ~]#
++ echo -ne '\033]0;root@XXYY:~\007'
[root@XXYY ~]# rpm --rebuilddb --dbpath $PWD/rpm
+ rpm --rebuilddb --dbpath /root/rpm
Speicherzugriffsfehler
++ echo -ne '\033]0;root@XXYY:~\007'
[root@XXYY ~]#
++ echo -ne '\033]0;root@XXYY:~\007'
[root@XXYY ~]# rpm -qa --dbpath $PWD/rpm
+ rpm -qa --dbpath /root/rpm
Fehler: cannot open Packages database in /root/rpm
++ echo -ne '\033]0;root@XXYY:~\007'

jetzt kommt immer diese echo-Zeile, ist das ok? soll das so sein? oder hab ich was falsch gemacht?
ales es gepastet war musste ich return drücken oder? weil irgendwie wird es 2 mal ausgeführt? sorry ich komme da gerade nicht mehr hinterher, ich bemühe mich aber es zu verstehen.

Auf jeden Fall danke das du mir hilfst und diese Skripte schreibst, und mich unterstützt den weg des reparierens zu gehen und nicht den des plattmachens :)

[undefined]

Das ist ein Shellscript und keine direkt Eingabe ;)
Erstelle dir eine testrpm.sh in /tmp z.B: testrpm.sh und füge meinen Code ein.
Danach mit "sh testrpm.sh" aufrufen.
Sorry aber wenn du hierbei schon scheiterst dann wird das was noch kommen wird, ein gekrampfe werden, und ich weiß nicht ob ich mir das dann weiter an tue ;) Als Administrator sind solche Kleinigkeiten ein muss.

[kenny_2008]

Hm, du hast warscheinlich recht, ich hatte gehofft, dass es nicht allzu viel wird.
Allerdings sitze ich immer noch vor dem Problem. Wo hast du denn die Infos her? Kann ich das vielleicht irgendwo nachlesen? Oder ist das allgemeines fortgeschrittenes Linux-Wissen, welches du spezifisch für dieses Problem anwendest, was ich also nicht wirklich nachlesen kann, es sei denn ich eigne mir nach und nach mehr Linux Wissen an?

Ich habe jetzt das skript ausgeführt. Wenn ich das richtig sehe, wird der Ordner rpm in tmp erstellt, und die DB Dateien erstellt. Das meintest du mit Testumgebung. Leider immer noch der Speicherzugriffsfehler:


+ rpm --initdb --dbpath /tmp/rpm
testrpm.sh: line 21: 26923 Speicherzugriffsfehler rpm --initdb --dbpath $PWD/rpm
+ rpm --rebuilddb --dbpath /tmp/rpm
testrpm.sh: line 23: 26924 Speicherzugriffsfehler rpm --rebuilddb --dbpath $PWD/rpm
+ rpm -qa --dbpath /tmp/rpm
Fehler: cannot open Packages database in /tmp/rpm

Also liegts an was anderem. Aber wenn es wohl noch etwas längerfristiges ist, dann ist das wirklich zu mühselig für dich. Es sei denn man könnte das vielleicht übern Chat machen, das geht zeitlich zumindest flotter. Oder wenn du noch ein paar Ideen/Ansätze hast, dann forsche ich ab nun alleine weiter oder aber erkläre den PC doch für nicht reparierbar :ugly:

Könnte es vielleicht daran liegen, dass der PC nur 1,5 gb speicher hat aber einer bestimmten Anwendung oder einer Datenbank 2 gb Speicher zugewiesen hat?

[undefined]

Na also - deine Datenbank ist nicht Defekt sondern rpm.
Du kannst die Datenbank auch auf deinen Linuxrechner Downloaden und mit.

rpm -qa --dbpath $PWD/rpm
testen. Und ich gehe mal davon aus das sie funktionieren wird.

Die frage ist ist jetzt was sich geändert hat.
Die rpm Binary glaube ich nicht weil der Befehl -qa ohne Speicherfehler durchgeht.
Mach mal Testweise eine Paket abfrage.
Also z.B:

rpm -qip /pfad/zum/paket.rpm
Wenn das geht müssen wir weiter sehen und ich kann glibc und libpopt ausschließen.
Nachtrag du kannst deine Datenbank auch mit den db utils testen.
z.B: mit:

db_stat -d rpm/Packages

[kenny_2008]

"auch downloaden"? also meine __db.00* dateien sind ja leer:


[root@XXYY rpm]# rpm -qa
Fehler: cannot open Packages database in /var/lib/rpm

oder ist mit Datenbank alles gesamt gemeint, also sowohl "Basenames Conflictname Dirnames" als auch die __db.00* Dateien?

erst durch das vorhandensein der __db.00* dateien ergibt rpm -qa kein speicherzugriffsfehler mehr zurück sondern den oben zitierten.

Soll ich DB mal downloaden?

erstmal die anderen codes:

[root@XXYY packstation]# rpm -qip mc-4.6.1a-0.9.ppc.rpm
Fehler: cannot open Packages database in /var/lib/rpm
Warnung: mc-4.6.1a-0.9.ppc.rpm: Header V3 DSA signature: NOKEY, key ID 12345
allerdings ist mc eigentlich schon installiert. komischerweise:

[root@XXYY packstation]# rpm -e mc-4.6.1a-0.9.ppc.rpm
Fehler: cannot open Packages database in /var/lib/rpm
Fehler: Paket mc-4.6.1a-0.9.ppc.rpm ist nicht installiert

db util test:

[root@XXYY rpm]# db_stat -d Packages
db_stat: unable to join the environment
61561 Hash magic number
8 Hash version number
Little-endian Byte order
Flags
4096 Underlying database page size
0 Specified fill factor
846 Number of keys in the database
846 Number of data items in the database
6 Number of hash buckets
10273 Number of bytes free on bucket pages (58% ff)
7657 Number of overflow pages
1760778 Number of bytes free in overflow pages (94% ff)
2 Number of bucket overflow pages
4528 Number of bytes free in bucket overflow pages (44% ff)
0 Number of duplicate pages
0 Number of bytes free in duplicate pages (0% ff)
4325 Number of pages on the free list

[undefined]

Deine Datenbank ist wie ich mir schon gedacht habe in Ordnung.
Da durch das die db_utils keinen Fehler bringen sieht das gut aus.
Lass ab jetzt die Datenbank links liegen die ist in Ordnung.
Du kannst sie in ein tar paket Packen und sichern.
Also:

tar -czf rpm_backup_20090318.tar.gz /var/lib/rpm

Jetzt wird es Kompliziert.
Es gibt im prinzip unter Linux 3 Gründe das ein Programm ohne weitere Fehlermeldungen abstürzt.
1) 80% sind Zugriffsfehler. (also Permissions)
Deshalb erst mal nachsehen das die Berechtigungen stimmen nicht etwaige Sticky bits auf dem Weg zur Datenbank gesetzt sind. Dies gilt auch für das /proc und /dev Filesystem.
2) korrupte Dateien oder links. Das kann man herausfinden wenn man find mit den -mtime Funktionen verwendet. Ein Programm geht nicht durch eigen verschulden defekt.
In dem Beispiel kannst du nachsehen welches Programm in /bin und /usr/bin die letzten 24 Stunden verändert wurde, erhöst du den Wert -1 jeweils ums eins geht es immer 24 Stunden weiter zurück.

find /bin -type f -mtime -1 -ls; find /usr/bin -type f -mtime -1 -ls;
Das gleiche kannst du auch auf lib und usr/lib machen.

find /usr/lib -maxdepth 1 -type f -mtime -1 -ls;
3) linkerfehler dazu brauche ich aber mehr Info.
Ein ldd auf /bin/rpm zeigt die Bindungen zu den Bibliotheken an.
Beispiel:

ldd /usr/bin/rpm5
linux-gate.so.1 => (0xffffe000)
librpmbuild-5.0.so => /usr/lib/librpmbuild-5.0.so (0xa7ebd000)
librpm-5.0.so => /usr/lib/librpm-5.0.so (0xa7e4f000)
librpmdb-5.0.so => /usr/lib/librpmdb-5.0.so (0xa7df2000)
librpmio-5.0.so => /usr/lib/librpmio-5.0.so (0xa7d65000)
librpmmisc-5.0.so => /usr/lib/librpmmisc-5.0.so (0xa7c37000)
libxar.so.1 => /usr/lib/libxar.so.1 (0xa7c21000)
.....

Danach die verbunden Bibliotheken prüfen z.B:


cd /tmp
ld /usr/lib/librpmbuild-5.0.so
ld: warning: cannot find entry symbol _start; not setting start address

Die Warnung kann Ignoriert werden ( das zu erklären ist zu viel ;) )
Sollte aber eine Meldung wie "undefined reference" kommen dann hast du ein linker Problem.
Das liegt daran das die Symbole der Bibliothek nicht mehr kompatible sind.
was sind symbole? guckst du...Beispiel

nm -g -D -C --defined-only /usr/lib/librpmbuild-5.0.so
Mit dem Befehl werden dir alle Methoden aufgelistet die eine Bibliothek einem Programm zu Verfügung stellen kann.
Ich weiß, schwere kost, aber anders wirst du den Fehler nicht finden.

[kenny_2008]

Danke für den ausführlichen Post.

Also mit -mtime wurde nichts gefunden.

Die Linkprüfung ergab folgendes:

linux-gate.so.1 => (0x00666000)
librpm-4.4.so => /usr/lib/librpm-4.4.so (0x00a3f000)
librpmdb-4.4.so => /usr/lib/librpmdb-4.4.so (0x00930000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00dd7000)
librpmio-4.4.so => /usr/lib/librpmio-4.4.so (0x00111000)
libpopt.so.0 => /usr/lib/libpopt.so.0 (0x001a8000)
libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x0073f000)
libelf.so.1 => /usr/lib/libelf.so.1 (0x00623000)
libbeecrypt.so.6 => /usr/lib/libbeecrypt.so.6 (0x00796000)
libm.so.6 => /lib/libm.so.6 (0x005e1000)
libneon.so.24 => /usr/lib/libneon.so.24 (0x006d1000)
libssl.so.5 => /lib/libssl.so.5 (0x003d1000)
libcrypto.so.5 => /lib/libcrypto.so.5 (0x00209000)
libdl.so.2 => /lib/libdl.so.2 (0x00608000)
libz.so.1 => /usr/lib/libz.so.1 (0x0060e000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x0031d000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x0035d000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00337000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00318000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x00204000)
libresolv.so.2 => /lib/libresolv.so.2 (0x001b0000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x0071e000)
librt.so.1 => /lib/librt.so.1 (0x001c3000)
libpthread.so.0 => /lib/libpthread.so.0 (0x006f9000)
libbz2.so.1 => /usr/lib/libbz2.so.1 (0x07077000)
libc.so.6 => /lib/libc.so.6 (0x004b6000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0080b000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0084f000)
/lib/ld-linux.so.2 (0x00498000)

Die meisten symbolischen Links waren nicht gesetzt. Nach dem setzen der Links ist aber immer noch der Speicherzugriffsfehler. Oder war ich zu voreilig?

was ist denn mit der "linux-gate.so.1" datei? fehlt die? aber bei deinem beispiel war ja auch keine datei dem link zugewiesen...(?)
Diese library ist nicht auf dem sytem vorhanden. wäre es möglich fedora 4 erneut zu installieren um an diese lib ranzukommen?

soll ich mit nm alle symbolischen links prüfen?

[undefined]

Was viel wichtiger ist hast du Punkt 1 die Berechtigungen geprüft?

[post]
Kannst du auch nicht finden weil ...
linux-gate.so (linux gather dynamic shared object) wird vom /proc Sytem erstellt und beinhaltet z.B: LOCALES siehe cat /proc/self/maps
Diese Virtuelle Bibliothek enthält also die Umgebungs Variablen und sammelt alle Methoden und Funktionen die ein Programm oder Bibliothek zur Laufzeit benötigt.

ja du mußt alle Bibliotheken prüfen mit einem Script geht das am schnellsten und die LOG kannst du dann anhängen.


#!/bin/bash

pushd /tmp

rm -f linker.log.txt
touch linker.log.txt

for lib in /usr/lib/librpm-4.4.so /usr/lib/librpmdb-4.4.so \
/lib/libselinux.so.1 /usr/lib/librpmio-4.4.so \
/usr/lib/libpopt.so.0 /usr/lib/libsqlite3.so.0 \
/usr/lib/libelf.so.1 /usr/lib/libbeecrypt.so.6 \
/lib/libm.so.6 /usr/lib/libneon.so.24 \
/lib/libssl.so.5 /lib/libcrypto.so.5 \
/lib/libdl.so.2 /usr/lib/libz.so.1 \
/usr/lib/libgssapi_krb5.so.2 /usr/lib/libkrb5.so.3 \
/usr/lib/libk5crypto.so.3 /usr/lib/libkrb5support.so.0 \
/lib/libcom_err.so.2 /lib/libresolv.so.2 \
/usr/lib/libexpat.so.0 /lib/librt.so.1 \
/lib/libpthread.so.0 /usr/lib/libbz2.so.1 \
/lib/libc.so.6 /lib/libgcc_s.so.1 \
/usr/lib/libstdc++.so.6 ; do
echo "### Check `basename $lib` ###"
if test -L $lib ; then
ld $lib >> linker.log.txt
else
echo "MISSING $lib ###" >> linker.log.txt
fi
done

popd

[kenny_2008]

Berechtigungen der Daten die in /var/lib/rpm , /proc und /dev sind? wie müssen die berechtigungen sein?

Das Script ergibt:

### Check librpm-4.4.so ###
### Check librpmdb-4.4.so ###
### Check libselinux.so.1 ###
### Check librpmio-4.4.so ###
### Check libpopt.so.0 ###
ld: warning: cannot find entry symbol _start; not setting start address
...[und so weiter]...
### Check libstdc++.so.6 ###
ld: warning: cannot find entry symbol _start; not setting start address
/tmp


Die Log:

MISSING /usr/lib/librpm-4.4.so ###
MISSING /usr/lib/librpmdb-4.4.so ###
MISSING /lib/libselinux.so.1 ###
MISSING /usr/lib/librpmio-4.4.so ###


Was mich wundert, weil wenn ich manuell tippe:

ld /usr/lib/librpm-4.4.so
ld: warning: cannot find entry symbol _start; not setting start address


Also warum ist es in der Log, aber die anderen nicht?
Bis morgen.

Grüße
kenny

[undefined]

Das ist ok weil ich von einem Link im Script ausgegangen bin.
Ersetze die zeile:

if test -L $lib ; then
mit

if test -e $lib ; then
dann noch mal.

[kenny_2008]

Ok hab ich geändert und erneut gestartet. Die Logfile ist 0 Byte groß also gibt es keine Linkerfehler (?)

/var/lib/rpm nach dem touch waren die __db Files zunächst root, habe ich aber geändert zu rpm (wie alle anderen auch).
alle -rw-r--r--.

/proc die meisten -r--r--r--

/dev größtenteils brw-r----- oder crw-------

Sorry ich hoffe das habe ich richtig verstanden, weiss nicht ob du bestimmte files meinst.
Edit: Also Sticky Bits sind nicht gesetzt wenn ich das richtig sehe.

[undefined]

Dann kann es nur noch ein IO Lesefehler sein.
Hänge die log als txt an.

strace rpm -qa >& rpm_log.txt

[kenny_2008]

Moin,

habe auch mal strace rpm --rebuilddb gelogt, dachte das könnte auch aufschlussreiches liefern, weil da ja der Speicherzugriffsfehler kommt.

[undefined]

Das kann nur ein Berechtigungs Fehler sein.
Er steigt genau an der stelle aus wo das erste DB File _db.000 zum lesen und schreiben geöffnet werden sollte.
Zeige bitte nochmal das dir auf /var/lib/rpm

dir -a /var/lib/rpm
Des weiteren würde ich dir empfehlen die Datenbank zu packen und auf deinem Heimrechner mal zu testen. Die Befehle dafür kennst du jetzt schon.
Bei mir öffnet er an der stelle wo bei der SIGSEGV kommt die erste DB.


:~/Downloads> grep -a10 'init\.lua' my_rebuild_log.txt
brk(0x80aa000) = 0x80aa000
brk(0x80a9000) = 0x80a9000
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 1000) = 1
read(3, "fix}/share/config\" \\\n export kd"..., 8192) = 6807
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 1000) = 1
read(3, "", 1385) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 1000) = 1
read(3, "", 8192) = 0
close(3) = 0
munmap(0xa7ef2000, 8192) = 0
stat64("/usr/lib/rpm/init.lua", 0xafc216ac) = -1 ENOENT (No such file or directory)
time(NULL) = 1237825768
umask(022) = 022
open("/home/undefined/Downloads/rpm/__db.000", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 3
umask(022) = 022
fcntl64(3, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}, 0xafc21828) = 0
.......

[kenny_2008]

dir -a /var/lib/rpm
. __db.001 __db.005 Installtid Provideversion rpm_backup_20090319.tar.gz
.. __db.002 Dirnames Name Pubkeys Sha1header
Basenames __db.003 Filemd5s Packages Requirename Sigmd5
Conflictname __db.004 Group Providename Requireversion Triggername


Warum eigentlich dir? ls -la bringt doch mehr info, auch zu den Berechtigungen.


ls -la
insgesamt 89620
drwxr-xr-x 2 rpm rpm 4096 19. Mär 08:10 .
drwxr-xr-x 21 root root 4096 30. Jan 11:45 ..
-rw-r--r-- 1 rpm rpm 10113024 18. Mär 13:16 Basenames
-rw-r--r-- 1 rpm rpm 12288 18. Mär 13:16 Conflictname
-rw-r--r-- 1 rpm rpm 24576 19. Mär 08:13 __db.001
-rw-r--r-- 1 rpm rpm 278528 19. Mär 08:13 __db.002
-rw-r--r-- 1 rpm rpm 98304 19. Mär 08:13 __db.003
-rw-r--r-- 1 rpm rpm 450560 19. Mär 08:13 __db.004
-rw-r--r-- 1 rpm rpm 16384 19. Mär 08:13 __db.005
-rw-r--r-- 1 rpm rpm 2408448 18. Mär 13:16 Dirnames
-rw-r--r-- 1 rpm rpm 10518528 18. Mär 13:16 Filemd5s
-rw-r--r-- 1 rpm rpm 28672 18. Mär 13:16 Group
-rw-r--r-- 1 rpm rpm 16384 18. Mär 13:16 Installtid
-rw-r--r-- 1 rpm rpm 49152 18. Mär 13:16 Name
-rw-r--r-- 1 rpm rpm 49123328 18. Mär 13:16 Packages
-rw-r--r-- 1 rpm rpm 352256 18. Mär 13:16 Providename
-rw-r--r-- 1 rpm rpm 126976 18. Mär 13:16 Provideversion
-rw-r--r-- 1 rpm rpm 12288 18. Mär 13:16 Pubkeys
-rw-r--r-- 1 rpm rpm 421888 18. Mär 13:16 Requirename
-rw-r--r-- 1 rpm rpm 237568 18. Mär 13:16 Requireversion
-rw-r--r-- 1 root root 23641880 19. Mär 08:10 rpm_backup_20090319.tar.gz
-rw-r--r-- 1 rpm rpm 159744 18. Mär 13:16 Sha1header
-rw-r--r-- 1 rpm rpm 81920 18. Mär 13:16 Sigmd5
-rw-r--r-- 1 rpm rpm 12288 18. Mär 13:16 Triggername

rpm ist (bis auf das archiv) der Eigentümer. 644 ist auch ok? Ich log mich immer als root ein (anderen user kenn ich hier nicht) und der "darf alles" oder nicht?

übrigens: falls du dich wunderst, warum die __db files jetzt auf einmal nicht mehr leer sind, die habe ich in /root gefunden, und dachte das sind die richtigen/verloren-gegangenen und habe sie ersetzt. Macht das sinn oder ist das quatsch bzw. sind das andere dbs?
aber ich habe auch immer wieder mal die __db.* dateien (eigentümer root), die anfangs erstellt wurden, getestet. aber wie eh und je der speicherzugriffsfehler.

[undefined]

Warum eigentlich dir? ls -la bringt doch mehr info, auch zu den Berechtigungen.
Kommt auf die System Konfiguration an, bei mir liefert "dir" immer ein ls -l also eher gewohnheit.

Entferne das tar Paket aus deiner Datenbank Struktur und wiederhole bitte noch mal den strace Befehl. Fremde Dateiformate haben in einer Datenbank Struktur nichts zu suchen. Das Verfälscht unsere Debug Bemühungen ;)

Zum Thema Dateirechte, ja als root sollte es die bezüglich keine Probleme geben, die einzige Ausnahme sind falsche mount Einträge in der /etc/fstab wenn zum Beispiel ein "resgid" auf einem root Dateisystem gesetzt ist.

Aber ich habe mittlerweile eher die Vermutung das bei dir ein Syntax Fehler in einer der rpm Macro Dateien ist. Ich komme drauf weil schreibst das RPM Rebuild die Datenbank Dateien im root Verzeichnis abgelegt hat.
Ich würde deshalb auch einmal nachsehen welche der macros unter /etc/rpm/* und /usr/lib/rpm zuletzt berührt wurde.