yum/rpm Не удалось инициализировать библиотеку NSS в chroot

Я выполняю 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

Попытки устранения неполадок: Читатель должен отметить, что обновленная файловая система контролируется версией. Каждый из следующих этапов был выполнен в один и тот же момент времени и отменен перед переходом к следующему этапу устранения неполадок.

Каждая из этих статей и решений не предоставила решения моей конкретной проблемы.

Спасибо за ваше время.

Источник

1 ответ

Решение

Отдельное спасибо Тревору и Йодриену на #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'
Источник
Другие вопросы по тегам