web-dev-qa-db-ja.com

yum / rpmがchrootのNSSライブラリを初期化できませんでした

CentOS 7.4からCentOS 7.5へのyumアップデートを実行しています。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  

試みを解決して下さい:それは読者によって注意されるべきです、アップグレードされたファイルシステムはバージョン管理されています。以下の各手順は同じ時点で実行され、次のトラブルシューティング手順に進む前に戻されました。

これらの記事とソリューションのそれぞれは、私の特定の問題を修正するものではありません。

お時間をいただきありがとうございます。

2
Arlion

#centosのTrevorHとjhodrienに特別に感謝します。

問題は、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

問題が修正されました。

7
Arlion

Arlionは正しいですが、大きな欠点があります。使いやすい

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'
0
mathog

受け入れられた答えは、問題がchroot(8)によって引き起こされていることを示しています。その場合、私はsystemd-nspawn(1)を使用する必要があることに気付きました。

Systemd-nspawnコンテナーを使用すると、正確な問題が完全に解決されました。

0
iBug