yum / rpm Échec d'initialisation de la bibliothèque NSS dans le chroot

2

J'effectue une mise à jour yum de CentOS 7.4 à CentOS 7.5, lorsque nspr et nss soft-softoken reçoivent les mises à jour, l'erreur suivante me reste:

yum update nspr
error: Failed to initialize NSS library
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   cannot import name ts

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.5 (default, Apr 11 2018, 07:36:10) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]

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

Les packages mis à jour pour:

nss                         3.34.0-4.el7                                           
nss-softokn                 3.34.0-2.el7                                           
nss-softokn-freebl          3.34.0-2.el7                                           
nss-sysinit                 3.34.0-4.el7                                           
nss-tools                   3.34.0-4.el7                                           
nss-util                    3.34.0-2.el7

Tentative de dépannage: le lecteur doit noter que le système de fichiers mis à niveau est contrôlé par la version. Chacune des étapes suivantes a été effectuée au même moment, puis annulée avant de passer à l’étape de dépannage suivante.

Pour tenter de résoudre ce problème, j'ai effectué les étapes suivantes: https://access.redhat.com/solutions/3134931
A suivi toutes les différentes solutions ici: erreur: impossible d'initialiser la bibliothèque NSS
J'ai mis à jour glibc.i686 et nspr avant la mise à jour.
rpm -e --nodeps --justdb nspr
rpm -e --nodeps --justdb nss nss-softokn nss-softokn-freebl nspr
https://bugzilla.redhat.com/show_bug.cgi?id=1477308

Chacun de ces articles et solutions n'ont pas fourni de solution à mon problème particulier.

Merci pour votre temps.

— Arlion
source

6

Un merci spécial à TrevorH et jhodrien sur #centos.

Le problème était que chroot empêche l'accès à / dev / urandom (tel que défini). La mise à jour installée avec succès a requis ces bits aléatoires pour initialiser GnuTLS.

La solution est:

mount -o bind /dev dev/

sur le chroot et procédez à la mise à jour comme d'habitude.

Ou si vous ne voulez pas monter le répertoire / dev tout entier, vous pouvez créer le vôtre!

mknod -m 666 /dev/random c 1 8
mknod -m 666 /dev/urandom c 1 9

Problème résolu.

— Arlion
source

merci a travaillé. Je voulais le noter, vous le lancez avant de chrooter, ou si votre déjà dedans peut être lancé depuis un autre terminal, dans votre répertoire racine monté, sans être chrooté, et sur le terme qui a votre open chroot env, deviendra auto accessible.

— Brian Thomas

0

Arlion a raison, mais il y a un inconvénient, un gros. Mieux vaut utiliser

mount -o bind /dev/urandom dev/urandom

D'après mon expérience avec Centos 7, si tout le répertoire / dev est monté la plupart du temps, même après son démontage, le répertoire / dev / pts est vissé de sorte que les connexions SSH sur cette machine échouent. Lorsque cela se produit, ssh ne se connecte pas et ce message est observé:

Server refused to allocate pty

Il n'y a rien dans / var / log / messages ou dmesg qui indique un problème. Si une session interactive ne se connecte pas, il est toujours possible de récupérer via ssh avec:

ssh root@stuck_machine 'umount /dev/pts; mount devpts /dev/pts -t devpts'

— mathog
source

Le correctif suggéré avec mount -o bind sur / dev fonctionne mais il casse autre chose, alors que monter seulement / dev / urandom ne le fait pas. Cela s'est présenté dans le même contexte (chroot pour exécuter yum), ce qui a brisé les connexions entrantes ssh. Il a été posté pour que la prochaine personne qui vient ici ne s'enferme pas en utilisant la première commande d'Arlion.

— mathog