より高いバージョンのGLIBCを必要とするDeepin Linux 20にソフトウェアをインストールしようとしています。私が見つけたスタックオーバーフローを実行する方法に関する質問いくつかの答えの指示に従ってください。コンピュータを起動しようとするたびに、Deepinのロゴが表示され、停止します（アニメーションである必要があります）。コンピュータは、ロゴを非表示にしてテキスト出力を表示するキーストロークを含め、どのキーストロークにも応答しません。
端末から起動できない場合は、起動ログを確認したり、この変更をキャンセルしたりするにはどうすればよいですか？別のシステムで起動できますが、基本システムをオフラインで変更する方法がわかりません。
コメントで提案されているように起動オプションを削除したら、問題の詳細を入手できるようになりましたquiet。splash
一番下には次の行があります。
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007f00 ]---
また、カーネルパニックを引き起こすと思われる行もあります。
/init: line 83: wait-for-root: not found
別の行では、カーネルパニックについて詳しく説明します。
/sbin/init: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
答え1
（私はこのガイドラインが突然プール、シンク、または水泳の深いところに投げ込まれているように感じることができることを知っています。このガイドラインが十分に詳細でないようであれば、近いLinuxの経験を持つ人を探してみることを強くお勧めします。問題を解決してください）。
復元するバックアップがない場合の最も簡単な回復方法は、古いライブラリを手動で抽出して再挿入し、システムがchroot可能になったら、パッケージマネージャを使用して最新のライブラリパッケージをダウングレードすることです。
.debar x package.deb3つのファイルを生成するパッケージ手動抽出を使用できます。control.tar.xzプレ/ポストインストール/アンインストールスクリプト（存在する場合）とパッケージマネージャのメタデータが含まれており、解凍した場合は相対パスでパッケージ化された実際のdata.tar.xzファイルが含まれていますdata.tar.xz。システムのルートディレクトリにある場合、ファイルは自動的に予想される場所に抽出されます。
この特別な場合は、バックアップシステムから起動し、破損したプライマリシステムのルートファイルシステムをマウントし、プライマリシステムのルートにあるディレクトリにある対応するdata.tar.xzglibcパッケージからそのファイルシステムを抽出します。つまり、デフォルトのルートファイルシステムをにマウントする場合は、次のように抽出し/mntますdata.tar.xz。
cd /mnt
tar xvf /where/ever/data.tar.xz
また、基本システムの内容も読み取る必要があります/var/log/dpkg.log（つまり、/mnt/var/log/dpkg.log基本オペレーティングシステムのルートファイルシステムがマウントされている場合/mnt）。ファイルには次の行が必要です。
<timestamp> upgrade <package name>:<arch> <old version> <new version>
これは、不運なアップグレード試行を開始する前にどのパッケージバージョンがあったか、glibcのアップグレードによって他のライブラリパッケージもアップグレードされたかどうかを正確に伝えます。もしそうなら、そのパッケージも復元する必要があります。
必要なライブラリの正しいバージョンを復元したら、chrootを介して基本システムをテストできます。プライマリシステムのルートファイルシステムが次にマウントされているとします/mnt。
mount --rbind /dev /mnt/dev
mount --rbind /sys /mnt/sys
mount -t proc proc /mnt/proc
chroot /mnt
これらのコマンドの後、chrootコマンドを入力したシェルセッションは、デフォルトでは、デフォルトシステムが最小限に実行されるように（「シングルユーザーモード」）、デフォルトシステム環境で実行できます。実行して、欠落しているライブラリーがないことを報告することを確認し、ldd /sbin/init重要なシステムバイナリに対しても同じことを行う必要があります。
この時点で、パッケージマネージャを使用して失敗したアップグレードを慎重に元に戻すことができるはずです。これにより、現在インストールされているファイルに対するパッケージマネージャのアイデアが再現可能になります（したがって、後で依存関係の問題は発生しません）。アップグレード中にパッケージが削除されたとマークされている場合は、dpkg.logアップグレード前に存在していた正確な構成に戻すために、削除されたパッケージを再インストールする必要があります。
アップグレードの試行後に手動で作業を行った場合、または基本インストールのファイルタイムスタンプにアップグレードの試行中に更新されたとマークされているupdate-initramfs -u場合は、chrootedシェルセッションで実行して、良いライブラリでプライマリシステムのinitramfsを再構築する必要があるかもしれません。initrd.img-<kernel version>/bootupdate-initramfs -u -k <kernel version>
glibcアップグレードの試行中に更新されたすべてのライブラリパッケージを復元した場合は、プライマリシステムがアップグレード前の状態に戻って再起動できるようになりました。
ディストリビューションの残りの部分もアップグレードせずにGLIBCを更新するのは一般的に悪い考えです。 GLIBCは基本的にシステムのすべての実行可能なバイナリが依存する基礎となることが多く、多くのライブラリファイルもそれに依存します。
ディストリビューションビルダーはコアシステムライブラリバージョンセット（GLIBCを含む）を選択し、一緒にうまく機能するようにビルドして構成します。これらのライブラリの1つを別のディストリビューション（またはそのディストリビューションの他のメジャーバージョン）のパッケージに置き換える場合同じ展開）、これらの相互依存は危険にさらされる可能性があり、期待どおりに実行されないか、まったく実行されない可能性があります。