Я выполняю обновление yum с CentOS 7.4 до CentOS 7.5, когда nspr и nss soft-softoken получают обновления, у меня возникает следующая ошибка:
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
Пакеты, обновленные до:
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
Попытки устранения неполадок: читатель должен отметить, что обновленная файловая система контролируется версиями. Каждый из следующих шагов выполнялся в один и тот же момент времени и возвращался перед переходом к следующему шагу устранения неполадок.
Каждая из этих статей и решений не помогала мне решить конкретную проблему.
Спасибо за уделенное время.
Особое спасибо TrevorH и jhodrien на #centos.
Проблема заключалась в том, что chroot предотвращает доступ к / dev / urandom (как было задумано). Установленное для успешного обновления обновление потребовало этих случайных битов для инициализации GnuTLS.
Решение такое:
mount -o bind /dev dev/
в chroot и продолжите обновление как обычно.
Или, если вы не хотите монтировать весь каталог / dev, вы можете создать свой собственный!
mknod -m 666 /dev/random c 1 8
mknod -m 666 /dev/urandom c 1 9
Проблема исправлена.
Принятый ответ указывает на то, что проблема вызвана chroot(8), и в этом случае я понял, что мне следовало использовать systemd-nspawn(1).
Использование контейнера systemd-nspawn идеально решило эту проблему для меня.
Арлион прав, но есть и обратная сторона, большая. Лучше использовать
mount -o bind /dev/urandom dev/urandom
По моему опыту с Centos 7, если весь / dev монтируется большую часть времени, даже после того, как он размонтирован, / dev / pts облажается, так что ssh-вход на эту машину не удастся. Когда это происходит, ssh не подключается, и появляется следующее сообщение:
Server refused to allocate pty
В / var / log / messages или dmesg нет ничего, что указывало бы на проблему. Хотя интерактивный сеанс не будет подключаться, все еще можно восстановить через ssh с помощью:
ssh root@stuck_machine 'umount /dev/pts; mount devpts /dev/pts -t devpts'