Ошибка: не удалось инициализировать библиотеку NSS
Я получаю сообщение об ошибке при установке обновлений или исправлений в RHEL-7.7.3.
ошибка: не удалось инициализировать библиотеку NSS
Не удалось импортировать один из модулей Python
требуется запустить ням. Ошибка, приводящая к этой проблеме:
не может импортировать имя ts
Пожалуйста, установите пакет, который предоставляет этот модуль, или
убедитесь, что модуль установлен правильно.
Возможно, что вышеупомянутый модуль не соответствует
текущая версия Python, которая:
2.7.5 (по умолчанию, 2 августа 2016 г., 04:20:16)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)]
Если вы не можете решить эту проблему самостоятельно, перейдите по ссылке
ням часто задаваемые вопросы по адресу:
http://yum.baseurl.org/wiki/Faq
КАК я могу решить это?
6 ответов
Это может быть связано с ошибкой, возникшей вчера с установкой glibc.686 в новой установке RHEL 7.3, которая приводила к разрыву как yum, так и rpm. Смотрите этот пост по решениям Red Hat. К сожалению, на данный момент у меня нет решения о том, как это исправить после установки glibc.686, однако решение на этой странице для 7.3 - установить nspr рядом с ним. Вы можете переустановить RHEL 7.3 или восстановить из резервной копии, а затем запустить:
ням установить glibc.i686 nspr
Это якобы обходит проблему.
Редактировать: я смог заставить это работать на сломанном экземпляре RHEL 7.3, вручную загрузив библиотеку nspr и выполнив следующую команду:
LD_PRELOAD =. / Libnspr4.so yum update nspr
Это исправит ваши ням и обороты. Удачи.
Если вы похожи на меня, то пытаетесь спасти сервер, переполненный как обычно ненужными силами управления пакетами, из среды спасения /chroot,
- не забудьте привязать-смонтировать действительный /dev файловая система внутри chroot.
Для нас strace -f rpm --help показывает, это нужно /dev/urandom,
Реквизиты Просвещения идут к этой проблеме GitHub, которая выдвинула на первый план /dev/urandom вещь, которую я определенно видел вблизи ENOENT в strace лог, но как-то не обращал внимания. Я привязал /{proc,sys} а для хорошей меры. Проблема ушла; сервер спас, ууу!
Ответ, который работал для меня:
скачать пакет nspr с nspr-4.13.1-1.0.el7_3.x86_64.rpm
rpm2cpio nspr-4.13.1-1.0.el7_3.x86_64.rpm | cpio -idmv
LD_PRELOAD =. / Usr/lib64/libnspr4.so yum update nspr (каталог может отличаться, но в основном должен быть хорошим)
Задача решена. Спасибо за тех, кто дал подсказку.
Кристиан КОММАРМОНД
@Christian все работает, но вам нужна свежая ссылка для скачивания http://rpm.pbone.net/index.php3/stat/4/idpl/36086786/dir/scientific_linux_7/com/nspr-4.13.1-1.0.el7_3.x86_64.rpm.html
Мы тоже это получаем. После переустановки виртуальной машины мы попробовали nspr вместе с glibc.i686, и она, похоже, устранила проблему, как и первая установка nspr, но на следующем сервере она не работает.
Проблема (для нас), по-видимому, на самом деле является зависимостью - nss-softokn-freebl.* Версия.x86_64 не соответствует версии.i686, поэтому она пытается обновить их обе, и последняя вызывает проблему.
Все еще работаю через это. Надеюсь, это кому-нибудь поможет.
Вот ссылка на исправление - https://access.redhat.com/solutions/3134931 Надеюсь, это поможет.