LinuxがGlibcをアップグレードするとき、私は何をすべきですか？

Linuxシステムでは、ソフトウェアのインストール時にGlibc-2.7バージョンが必要ですが、アップグレードするにはGlibcバージョンが低すぎるため、システムがクラッシュします。どうすればいいですか。次の小シリーズでは、LinuxがGlibcをアップグレードするときのシステムクラッシュの解決策を紹介します。

現象：

HPのハードウェアモニタ（hpasmcli）をインストールヒントマシンがglibcで、2.5である一方で、アップグレードはGlibcのを持っているようだ、glibcで-2.7に依存している、と残念ながらアップグレード他のサーバーにhpasmcliをインストールしたときはとてもスムーズだと思いました他のサーバーのglibcライブラリファイルを直接マシンにコピーすることを考えました：

/lib /libc-2.5.so＃32ビットシステム

/lib64/libc-2.5.so＃64ビットシステム

私が運用しているサーバーシステムは64ビットなので、/lib64を上書きします。 /libc-2.5.soファイルの瞬間に、次のように多数のカーネルエラーが画面に報告されます（hostはサーバーのホスト名を表します）。

syslogd @ at Fri Apr 26 18:10:35 2013からのメッセージ。 。 。ホストカーネル：in6b rsp 00007fff8c0b8698エラー4 syslogd @ at Fri Apr 26 18:10:35 2013からのメッセージ。 。 。ホストカーネル：init [1]：segfault at 0000000000000000 rip 00002b28b2052e6b rsp 00007fff8c0b8698 error 4 syslogd @ at Fri Apr 26 18:10:35 2013からのメッセージ。 。 。ホストの最後のメッセージが17回繰り返されましたsyslogd @ at Fri Apr 26 18:10:35 2013からのメッセージ。 。 。ホストカーネル：init [1]：segfau6b rsp 00007fff8c0b8698 error 4 syslogd @ at Fri Apr 26 18:10:35 2013からのメッセージ。 。 。ホストカーネル：init [16b rsp 00007fff8c0b8698 error 4

すると、システムがクラッシュしてログインできなくなります。

サーバーを再起動するためにサーバールームに緊急連絡し、サーバーを起動できないことを示します。

こんにちは、私は個人的に事故を引き起こしました！

重要：

glibcは、gnuによってリリースされたlibcライブラリで、cランタイムライブラリです。 GlibcはLinuxで最低レベルのAPIであり、他のほとんどのランタイムはglibcに依存しています。 Linuxオペレーティングシステムによって提供されるシステムサービスをカプセル化することに加えて、glibc自体が必要な機能サービスの他の多くの実装を提供します。 glibcはUNIXに共通のほぼすべての標準をカバーしているので、それがすべてを網羅していると想像することができます。

Glibcのアップグレード：実行中のシステムにGlibcをインストールしないと、システムがクラッシュする可能性がありますので、現在使用しているGlibcを上書きしないように、新しいGlibcを別のディレクトリにインストールする必要があります。 （私は無知をカバーします、ねえ！）

解決策：

コンピュータ室に行きますが、幸いに置き換え前に元のライブラリファイルを/libディレクトリに保存しました（libc-2.5）。 Linuxのシステムディスクを使用して「レスキューモード」に入り、交換した2つのライブラリファイルを復元してシステムを再起動します。

システムが正常に起動したら、他の部門に引き渡されます。同僚はデータを回復するために行きます。

上記はLinuxがGlibcをアップグレードしたときのシステムクラッシュの解決策の紹介です。この方法はとても簡単で、レスキューモードに入り、置き換えられたライブラリファイルを復元する必要があります。元のGlibcを上書きしなくてもシステムがクラッシュすることはありません。