[Risolto] yum non si avvia-libreria librpm.so.3 mancante o danneggiata

salve a tutti,
sono nuovissimo del forum, anche se ogni tanto faccio una capatina per imparare qualcosa.

ho istallato fedora kde (18 a 64bit) da appena 20 giorni(quindi la mia esperienza è limitatissima) e sto faticando ad adattarmi (ubuntu per 4 anni senza troppe difficoltà) anche se l’impressione è di una maggiore stabilità rispetto all’isteria delle ultime versioni di ubuntu.

da circa un paio di giorni però il gestore degli aggiornamenti mi è “impazzito”:
ogni 20 minuti circa mi appare una notifica di errore, che mi fa capire che la ricerca di nuovi aggiornamenti è fallita a causa di un grave errore in un fantomatico bakend, presumo io si tratti di apper.
lascio dormire la bestia(cioè il problema), confidando che si tratti di qualche pacchetto minore e che magari tra qualche giorno gli aggiornamenti automatici sistemino la cosa, ma ovviamente non succede.
così oggi mi decido ad avviare un aggiornamento “manuale” aprendo apper > “Controlla nuovi aggiornamenti” e istantaneamente appare:

The backend exited unexpectedly. This is a serious error as the spawned backend did not complete the pending transaction

avendo capito che gli aggiornamenti di sistema passano attraverso yum, ho cercato di trovare qualche informazione riguardo a questo problema sui vari forum.
ma il fatto essenziale è che appena digito yum (come utente root) appare il messaggio:

[code][root@Host-001 ~]# yum
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

/lib64/librpm.so.3: file too short

Please install a package which provides this module, or
verify that the module is installed correctly.

It’s possible that the above module doesn’t match the
current version of Python, which is:
2.7.3 (default, Aug 9 2012, 17:23:57)
[GCC 4.7.1 20120720 (Red Hat 4.7.1-5)]

If you cannot solve this problem yourself, please go to
the yum faq at:
http://yum.baseurl.org/wiki/Faq[/code]

stessa storia con qualsiasi comando che chiami yum, come:

yum clean all

il mio primo approccio “stupido” per risolvere il problema era scaricare questa fantomatica libreria librpm.so.3 e incollarla brutalmente dentro la cartella /lib64, eventualmente sovrascrivendo il file danneggiato.
così ho scaricato il pacchetto rpm-libs-4.10.1-3.fc18.i686.rpm, l’ho scompattato, ho copiato quel file librpm.so.3
tuttavia, anche come superutente, nella cartella /lib64 non ho la capacità di incollare nulla.

ad occhio presumo la procedura sia sbagliata o incompleta e che anche per istallare per bene o reistallare questo pacchetto rpm mi servierebbe yum, ma se yum nemmeno si avvia che faccio?
preso dalla disperazione, continuo il naufragio tra vecchi post, di qualsiasi forum, pure in serbo-croato…alla ricerca di qualcosa di simile e possibilmente comprensibile per un principiante.

così, prendo spunto da un altro post di questo forum,sperando che cancellando il link a questa libreria e ricreandolo le cose si potessero risolvere, e mi “invento”, :

rm /lib64/librpm.so.3 ln -s /lib64/librpm.so.3 /lib64/librpm.so.3.0.1

invece ora mi ritrovo che è stato solo rimosso il link simbolico a quella libreria e yum continua a non dare segni di vita

[code]There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

librpm.so.3: cannot open shared object file: No such file or directory

Please install a package which provides this module, or
verify that the module is installed correctly.

It’s possible that the above module doesn’t match the
current version of Python, which is:
2.7.3 (default, Aug 9 2012, 17:23:57)
[/code]

per completezza aggiungo che python funziona correttamente(sto lavorando da giorni con eric4 e le pyqt senza nessun problema).

mi scuso per la lunghezza, ma essendo la prima volta che chiedo aiuto, ho preferito illustrare il quadro al meglio che potevo.
grazie

[quote=patrizier79]…]
ho istallato fedora kde (18 a 64bit)

…]
il mio primo approccio “stupido” per risolvere il problema era scaricare questa fantomatica libreria librpm.so.3 e incollarla brutalmente dentro la cartella /lib64, eventualmente sovrascrivendo il file danneggiato.
così ho scaricato il pacchetto rpm-libs-4.10.1-3.fc18.i686.rpm, l’ho scompattato, ho copiato quel file librpm.so.3
…]
[/quote]
Ovviamente una tale procedura “non s’ha da farsi”, anche

# rpm -Uvh [pacchetto]

era fuori uso?
A parte questo,su 64bit dovrebbe installarsi rpm-libs-[versione].fc18.x86_64 , non i686…

grazie tempus,

ho provato ora il tuo suggerimento con rpm e questo è ciò che mi risponde:

rpm: error while loading shared libraries: librpm.so.3: cannot open shared object file: No such file or directory

da profano (se non sbaglio qualcos’altro) ho paura che quel file librpm.so.3 corrotto o perso impedisca l’operazione.
confesso che non ho dimistichezza con rpm

Assumo che tu abbia rpm2cpio e cpio installati. Controlla con

 $ whereis cpio; whereis rpm2cpio

Potresti provare così.
Crea una directory temporanea, nella home o in /dev/shm.

$ mkdir /dev/shm/temp

Scarica
http://fedora.mirror.garr.it/mirrors/fedora/linux/updates/18/x86_64/rpm-4.10.3.1-1.fc18.x86_64.rpm
http://fedora.mirror.garr.it/mirrors/fedora/linux/updates/18/x86_64/rpm-libs-4.10.3.1-1.fc18.x86_64.rpm
http://fedora.mirror.garr.it/mirrors/fedora/linux/updates/18/x86_64/rpm-python-4.10.3.1-1.fc18.x86_64.rpm
nella cartella temporanea.

$ cd /dev/shm/temp
$ for i in *; do rpm2cpio $i | cpio -idmv; done
$ mv rpm*rpm ../
$ su -c "cp -r ./* /"

Quindi provare a dare il comando rpm o yum.
Se funziona, uno

# yum reinstall yum* rpm*

sarebbe meglio.

Come hai fatto a finire in questa situazione? Hai installato a mano/maneggiato qualche file di sistema?

grazie dei suggerimenti,
per fortuna cpio e rpm2cpio risultano…
proverò la tua procedura.

riguardo a come sia potuto accadere…non ho la più pallida idea.
la cosa più ardita che abbia fatto da quando ho messo fedora è stata creare dei file .desktop, per avere dei collegamenti ai miei programmi in python nel menu-applicazioni, ma niente che riguardi il sistema operativo o altre applicazioni(o file) di più basso livello.
i problemi sono emersi 3/4 giorni fa, al termine dell’aggiornamento automatico di apper: nell’area di notifica è iniziato ad apparire quel messaggio di errore. visto che in precedenza c’erano stati altri problemi di compatibilità con la scheda grafica al termine di altri aggiornamenti, “magicamente” risolti con gli aggiornamenti successivi, avevo lasciato correre

niente da fare…
scaricato i pacchetti nella dir temporanea, ma appena lancio quel ciclo for esce il solito messaggio di errore:

temp$ for i in *; do rpm2cpio $i | cpio -idmv; done rpm2cpio: error while loading shared libraries: librpm.so.3: cannot open shared object file: No such file or directory cpio: premature end of archive rpm2cpio: error while loading shared libraries: librpm.so.3: cannot open shared object file: No such file or directory cpio: premature end of archive rpm2cpio: error while loading shared libraries: librpm.so.3: cannot open shared object file: No such file or directory cpio: premature end of archive

sta maledetta librpm.so.3

Nel tuo post originario hai scritto che hai scompattato un rpm da kde; assumo che tu abbia ark installato.
Ripeti la procedura con

$ for i in *; do ark $i; done

al posto di

$ for i in *; do rpm2cpio $i | cpio -idmv; done

.
Si aprirà ark, clicca su “Estrai”, deseleziona “Estrazione nella sottocartella”, seleziona “Mantieni inalterati i percorsi durante l’estrazione”, poi clic su File→Esci, quindi si aprirà ark per i seguenti due file e ripeterai la procedura.

EDIT: il problema maggiore è sorto quando

[quote=patrizier79] …] mi “invento”, :

rm /lib64/librpm.so.3 ln -s /lib64/librpm.so.3 /lib64/librpm.so.3.0.1

invece ora mi ritrovo che è stato solo rimosso il link simbolico a quella libreria e yum continua a non dare segni di vita
…][/quote]
lì hai rimosso un collegamento simbolico e hai invertito destinazione e nome del collegamento simbolico nel comando ln -s (/usr/lib64/librpm.so.3 è il collegamento simbolico che deve puntare alla libreria /usr/lib64/librpm.so.3.x : con quella sintassi, avresti creato /usr/lib64/librpm.so.3.x collegamento simbolico di /usr/lib64/librpm.so.3…)

ancora nulla…

mi posiziono nella dir /dev/shm/temp (dove ho scaricato i 3 pacchetti rpm)
e lancio il comando:

temp$ for i in *; do ark $i; done

si apre ark, estraggo il primo pacchetto nella cartella temp, esco da ark,
si apre di nuovo ark, avvio l’estrazione e ottengo:

ark(2471)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x275d298 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. ark(2471)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/dev/shm" ark(2471)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/dev" ark(2481)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x1f96198 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. ark(2603)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x1f250a8 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. ark(2603)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/dev/shm" ark(2603)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/dev"

a questo punto non capisco se si tratti di qualche altro problema(a occhio mi sembra più un problema di GUI ark o forse ho eseguito male i passaggi?!) o se sia sempre il solito…collegato alla libreria mancante

Cancella la directory temporanea, ripeti la procedura.
Riscarica i pacchetti.
Estrai un pacchetto rpm alla volta.

$ ark rpm-4.10.3.1-1.fc18.x86_64.rpm $ ark rpm-libs-4.10.3.1-1.fc18.x86_64.rpm $ ark rpm-python-4.10.3.1-1.fc18.x86_64.rpm
al posto di $ for i in *; do ark $i; done.

Per ogni pacchetto aperto in ark deseleziona “Estrazione nella sottocartella”, seleziona “Mantieni inalterati i percorsi durante l’estrazione” nel menù di dialogo intermedio.

( visto che il sistema appare danneggiato, forse è meglio procedere da live e sovrascrivere i file sulla / di sistema opportunamente montata)

Avevo pensato anche a quello, considerato che in una live rpm2cpio senz’altro funziona; mi preoccupava l’incognita “uso fedora da 20 giorni”. Se non ce la si fa nemmeno con ark, senz’altro non resta che la live.

Piccola precisazione: alcuni messaggi di ark su terminale sono innocui, quel che conta è che nella directory temporanea abbia creato bin etc usr var. Se così è, può proseguire con

$ mv rpm*rpm ../ $ su -c "cp -r ./* /"

(mi rendo conto.)

a chi lo dici!?
per questo finora avevo cercato di tenermi il più possibile lontano dal terminale…limitandomi all’uso delle interfacce grafiche…almeno lì più del consentito non puoi fare…

tornando ad ark…che si potesse trattare di avvisi standard lo sospettavo, visto che anche dolphin, se lo lanciato da terminale, mi riempe la console di avvsi analoghi…

per quanto riguarda la creazione delle dir bin,etc, usr e var è avvenuta:

temp$ ls bin etc usr var
tuttavia, intrepido come sempre, avevo già provato comq a lancirare il comando:

temp$ mv rpm*rpm ../ mv: impossibile eseguire stat di "rpm*rpm": File o directory non esistente

ora sto uscendo,appena rientro proverò a spacchettare i 3 rpm singolarmente.

nello sfortunato caso in cui non funzionasse e approfittando della vostra disponibilità, potreste farmi capire concettualmente cosa intendete con “procedere da live”?

avvio il sistema col cd di fedora, mi sposto come dir di lavoro sul disco di fedora e da lì lancio l’installazione di yum o simili in modo che rimetta tutte le librerie a posto giusto?
grazie ancora

Probabilmente il comando mv lo avevi già dato, e se avessi fatto ls …/rpm*rpm avresti visto i pacchetti rpm che avevi originariamente scaricato nella cartella temporanea; la medesima cartella temporanea ove, a un “ls” restituisce ora bin etc usr var.

Accertato che nella cartella temporanea ci siano dette directory e non più i pacchetti .rpm da cui provengono,
procedi direttamente con il passo successivo,

$ su -c "cp -r ./* /"

Quanto alla live: non basta “reinstallare rpm e yum” in quanto una reinstallazione avverrebbe nei confronti del sistema operativo live. Occorrerebbe montare opportunamente come detto da virus la radice del tuo sistema operativo installato e quindi, avvalendosi del sistema live funzionante per scompattare gli rpm, trasferire i file ottenuti verso l’opportuno punto di mount della live ove è stata montata la radice del tuo sistema operativo reale/su disco. Occorre quindi anche preventivamente accertare che ad es. tu non abbia differenziato i punti di mount ad es. /bin o /usr dalla radice, per quanto ciò sia inusuale (puoi controllare i punti di mount predefiniti del tuo sistema guardando in /etc/fstab - $ cat /etc/fstab).

EDIT: ad ogni buon conto, non temere il terminale - è più chiaro e semplice e “senza sorprese” di una GUI in molteplici occasioni. In futuro, dai anche una occhiata http://doc.fedoraonline.it/Primi_passi_nel_terminale.

(@tempus si potrebbe pensare anche ad un yum --installroot /punto/di/montaggio diretto)

@virus pensando alla improponibilità di un chroot in questo caso avevo mentalmente eliminato e scordato quella possibilità, anche molto semplice e lineare, che sarebbe pensata proprio per casi come questo…
Ipotizzando che la radice venga vista dalla live ad es. come /dev/sda2 (puro esempio),
basterebbe forse dalla live

# mkdir /media/rescueme
# mount /dev/sda2 /media/rescueme
# yum --installroot /media/rescueme --releasever=/ --nogpg reinstall rpm* yum* 

scusate la latitanza…ma (sudando freddo) stavo cercando di rieseguire i passaggi suggeriti, evitando possibilmente di formattare l’hd mio e del vicino…

riepilogo di cosa ho combinato:

mkdir /dev/shm/temp

ci scarico i 3 paccheti rpm
li spacchetto uno alla volta con ark:

[code]$ ark rpm-4.10.3.1-1.fc18.x86_64.rpm

$ ark rpm-libs-4.10.3.1-1.fc18.x86_64.rpm

$ ark rpm-python-4.10.3.1-1.fc18.x86_64.rpm

$ mv rpmrpm …/
$ su -c "cp -r ./
/"
Password:
cp: impossibile sovrascrivere la non-directory “/bin” con la directory “./bin”
[/code]
il che non credo che sia bene, seppure non abbia la più pallida idea di che significhi.

tuttavia mentre sono avvinto da queste domande esistenziali, magicamente vedo in basso, nell’area di notifica, che riappare l’icona degli aggiornamenti disponibili (il demone di apper insomma).
questa cosa mi sembra già un progresso, visto che finora apper non riusciva neppure a connettersi per controllare gli aggiornamenti da fare.
risultano 127 aggiornamenti e in cima alla lista ci sono 4/5 elementi con l’icona del bug relativi a yum,
del tipo:
yum
yum-plugin+fastestmirror
yum-utils
ecc…

che faccio? un’offerta votiva a s.antonio e poi clicco su “istalla” sperando che funzioni…
oppure non mi fido della…gui e torno a sudare freddo coi punti di mount ?

nota folkloristica:
lo so, non dovrei dirlo neppure, ma…
nella mia testolina si fa sempre più spazio una vocina (tipo quella di gollum) che dice…formaaaaatta:wall:

non ho saputo resistere…no, non ho formattato,
però ho lanciato l’installazione dei 127 aggiornamenti di sistema: la procedura è stata completata con successo, ho riavviato.

la notifica di errore fatale sembra sparita, da terminale ho digitato yum e finalmente non appare più il messaggio di errore relativo alla libreria mancante:

[code]$ yum
Plugin abilitati:fastestmirror, langpacks, presto, refresh-packagekit
È necessario specificare un comando
Usage: yum [options] COMMAND

List of Commands:
…]
[/code]
insomma sembra funzionare correttamente.
tra l’altro funziona anche apper.

ora, con tutta la devozione per s.antonio, senza essere ingrato, penso che la procedura di tempus mi abbia permesso di reistallare le librerie che bloccavano yum (anche se yum continuava a non partire) e che in questo modo si sia sbloccato il demone di apper che controlla gli aggiornamenti…
morale della favola:
ho apprezzato tantissimo il vostro aiuto(credo determinante).
sono più confuso di prima.
spero col tempo e l’esperienza di farmi un quadro più organico del s.o. e delle funzioni principali.
quello che detesto è mettere insieme nozioni a macchia di leopardo.

a questo proposito, durante il “naufragio” alla ricerca frenetica di informazioni su yum, mi è capitato di leggere più di qualche volta che è preferibile installare yum extender: senza chiedervi il segreto della giovinezza, volevo sapere se è effettivamente utile installarlo.
da quel poco che ho capito avrebbe una migliore risoluzione delle dipendenze, ma alla fine sempre di yum si tratta…

grazie ancora

lancia

$ rpm

da terminale.
Se ti restituisce come output “RPM versione 4.10.3.1” seguito da una sintesi delle opzioni d’uso possibili, sei a cavallo. Non ti preoccupare della segnalazione circa la non-directory bin.
Sono moderatamente ottimista.
Se tutto è come dovrebbe,

# yum reinstall yum* rpm* --skip-broken -y
# rpm --rebuilddb
# yum update --skip-broken -y

Riavvia e dovresti essere a posto. Ultimo controllo eventuale con

$ package-cleanup --problems

EDIT: ho visto adesso il tuo ultimo post, esegui comunque i comandi di cui sopra
EDIT2: sì, yumex (yum extender) è un interfaccia grafica di yum alternativa spesso apprezzata.

allora “sono a cavallo” (della serie le ultime parole famose):
ho eseguito i comandi da te indicati e sembra tutto a posto:

RPM versione 4.10.3.1,
yum aggiornato perfettamente
e package-cleanup --problems restituisce No Problems Found

ora proverò ad installare yumex per concludere.

grazie veramente per la pazienza :slight_smile: