it-swarm.com.de

Fehler: Fehler beim Initialisieren der NSS-Bibliothek

Beim Installieren von Updates oder Patches in RHEL-7.7.3 wird eine Fehlermeldung angezeigt.

fehler: Fehler beim Initialisieren der NSS-Bibliothek

Beim Importieren eines der Module Python) ist ein Problem aufgetreten

erforderlich, um lecker zu laufen. Der Fehler, der zu diesem Problem führte, war:

Name ts kann nicht importiert werden

Bitte installieren Sie ein Paket, das dieses Modul enthält, oder

stellen Sie sicher, dass das Modul korrekt installiert ist.

Es ist möglich, dass das obige Modul nicht mit dem übereinstimmt

aktuelle Version von Python, die ist:

2.7.5 (Standard, 2. August 2016, 04:20:16)

[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)]

Wenn Sie dieses Problem nicht selbst lösen können, gehen Sie bitte zu

die yum faq bei:

http://yum.baseurl.org/wiki/Faq

WIE kann ich das beheben?

5
Puneet Dixit

Dies könnte mit einem Fehler zusammenhängen, der gestern bei der Installation von glibc.686 auf einer neuen Installation von RHEL 7.3 aufgetreten ist, wodurch sowohl yum als auch rpm unterbrochen werden. Siehe diesen Beitrag zu Red Hat-Lösungen. Leider habe ich derzeit keine Lösung, wie das Problem nach der Installation von glibc.686 behoben werden kann. Die Lösung auf dieser Seite für 7.3 besteht jedoch darin, nspr nebeneinander zu installieren davon. Sie können RHEL 7.3 neu installieren oder aus einer Sicherung wiederherstellen und dann Folgendes ausführen:

yum installiere glibc.i686 nspr

Dies umgeht angeblich das Problem.

Bearbeiten: Ich konnte dies auf einer defekten Instanz von RHEL 7.3 zum Laufen bringen, indem ich manuell eine nspr-Bibliothek herunterlud und den folgenden Befehl ausführte:

LD_PRELOAD =./Libnspr4.so yum update nspr

Dies wird Ihr Yum und Ihre Drehzahl korrigieren. Viel Glück.

4
centrahome

Die Antwort, die bei mir funktioniert hat:

laden Sie das nspr-Paket von nspr-4.13.1-1.0.el7_3.x86_64.rpm herunter

rpm2cpio nspr-4.13.1-1.0.el7_3.x86_64.rpm | cpio -idmv

LD_PRELOAD =./Usr/lib64/libnspr4.so yum update nspr (Verzeichnis kann abweichen, sollte aber meistens gut sein)

Problem gelöst. Vielen Dank für diejenigen, die den Hinweis gegeben haben.

Christian COMMARMOND

Wenn Sie wie ich sind und versuchen, einen Server, der unter der üblichen (unnötigen) Paketverwaltungskraft angeschnallt wurde, aus einer Rettungs-/Chroot-Umgebung zu retten,

- Stellen Sie sicher, dass Sie ein gültiges /dev - Dateisystem in der Chroot binden.

Denn wie strace -f rpm --help Zeigt, braucht es einen /dev/urandom.


Aufklärungsrequisiten gehen zu diese GitHub-Ausgabe , die das /dev/urandom - Ding hervorhob, das ich definitiv in der Nähe von ENOENT im strace-Protokoll gesehen habe, aber irgendwie nicht beachtet habe. Ich habe auch /{proc,sys} Für ein gutes Maß gebunden. Das Problem ging weg; Server gerettet, yay!

4
ulidtko
0
nullne co

Wir bekommen das auch. Nach der Neuinstallation von VM) haben wir nspr neben glibc.i686 ausprobiert und es schien das Problem zu beheben, ebenso wie die Installation von nspr zuerst, aber auf dem nächsten Server funktioniert es nicht.

Das Problem (für uns) scheint tatsächlich eine Abhängigkeit zu sein - nss-softokn-freebl. * Die .x86_64-Version stimmt nicht mit der .i686-Version überein, daher wird versucht, beide zu aktualisieren, und die neueste Version löst das Problem aus.

Ich arbeite immer noch daran. Hoffe das hilft jemandem.

0
Paul