4

I am performing a yum update from CentOS 7.4 to CentOS 7.5, when nspr and nss soft-softoken receive the updates, I am left with the following error:

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

The packages that are updated to:

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

Troubleshoot attempts: It should be noted by the reader, the upgraded filesystem is version controlled. Each of the following steps were performed at the same point in time, and reverted before moving on to the next troubleshooting step.

Each of these articles and solutions have not provided fix my particular issue.

Thank you for your time.

Arlion
  • 590
  • 1
  • 4
  • 17

3 Answers3

11

Special thank you to TrevorH and jhodrien on #centos.

The problem was that chroot prevents access to /dev/urandom (as desgined). The update installed to succeeded required those random bits to initialize GnuTLS.

The solution is:

mount -o bind /dev dev/

to the chroot and proceed with the update as usual.

Or if you don't want to mount the entire /dev directory, you may create your own!

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

Problem fixed.

Arlion
  • 590
  • 1
  • 4
  • 17
  • 2
    thanks worked. wanted to note, you run this before you chroot in, or if your already in can run from another terminal, in your mouted root dir, without being chrooted in, and on the term that has your open chroot env, will become auto accessible. – Brian Thomas Feb 27 '19 at 22:47
  • The amount of sheer BS one finds online regarding this error message and “solutions”, is hard to fathom. Thanks for setting the record straight. – DomQ May 18 '20 at 10:33
0

The accepted answer indicates that the problem is caused by chroot(8), in which case I realized that I should have used systemd-nspawn(1).

Using a systemd-nspawn container solved the exact issue perfectly for me.

iBug
  • 1,048
  • 2
  • 9
  • 21
0

Arlion is right, but there is a down side, a big one. Better to use 

mount -o bind /dev/urandom dev/urandom

In my experience with Centos 7 if all of /dev is mounted much of the time even after it is unmounted /dev/pts is screwed up so that ssh logins to that machine will fail. When this is happening ssh willl not connect and this message is observed:

Server refused to allocate pty

There is nothing in /var/log/messages or dmesg to indicate a problem. While an interactive session will not connect it is still possible to recover via ssh with:

ssh root@stuck_machine 'umount /dev/pts; mount devpts /dev/pts -t devpts'
mathog
  • 111
  • 1
  • 3
  • The suggested fix with mount -o bind on /dev works but it breaks something else, whereas only mounting /dev/urandom does not. This turned up in the same context (chroot to run yum) when doing so broke ssh incoming connections. It was posted so the next person who comes here does not lock themselves out of their machine by using Arlion's first command. – mathog Sep 18 '19 at 00:55