PanicのLinuxカーネルをすばやく修復するテクニック

この文章を書くには理由がある。完全なサイレント起動を構成するために、筆者は自分のワークコンピュータ上で実行するLinuxに対して、mkinitcpioを無視したため、不適切なmkinitcpio操作を実行した。confファイルの論理エラーです。これによりmkinitcpioは新しいカーネルファイルを生産しましたが、このカーネルファイルは正常に動作しません。再起動の際、カーネル起動はPanic状態で停止します。

一般的に、新しいカーネルが正常に動作しない場合は、initramfsカーネルファイルのfallbackバージョンを使用してシステムを起動したり、直接fallbackバージョンを上書きして変更をロールバックすることもできますが、今回は、mkinitcpioがvmlinuzのカーネルファイルを同時に変更し、vmlinuzにはfallbackバージョンがありません。一般ユーザーに対して、直接システムを再インストールして解決することができます。しかし、筆者のワークステーション環境の構成は非常に複雑で、これは私の作業ファイルを失う可能性があるほか、開発環境を再構成するのに多くの時間がかかることを意味します。

パートタイムLinuxサーバの運用とメンテナンスの経験から、カーネルを修復するための一時的なLinux環境をLiveCDで起動できることをすぐに考えました。

筆者はArch Linux 64ビット版を使用しているので、Arch LinuxからのLive CDからスタートします。LiveCDに組み込まれているrootユーザーに正しくアクセスした後、自分のプライマリハードディスク(HDD)のデバイス名を確認する必要があります。fdisk-lを実行します。筆者の場合、私のメインハードディスク、ルートディレクトリにマウントされているパーティションに対応するデバイスファイルは/dev/sdb 2です。

ハードディスク(HDD)のシステムルートディレクトリにchrootを接続し、ハードディスク(HDD)のシステムコンポーネントを正常に呼び出してハードディスク(HDD)のシステムを変更するには、まずハードディスク(HDD)のルートパーティションを手動でマウントします。実行(私のデバイスファイルは/dev/sdb 2):

焦らないでください。このときchrootから/mntまではハードディスク上のメインシステムのbashにアクセスできますが、複雑なタスクを正しく完了することはほとんどできません。重要なディレクトリがマウントされていないためです。procディレクトリ、/sysディレクトリ、/devディレクトリ、/runディレクトリをそれぞれマウントするコマンドを実行します。/mntに入り、それぞれ実行:

これらのものをマウントすると、chrootをメインハードディスクのルートディレクトリに移動できます。

後悔薬++。私にとって、私はmkinitcpioを修正するだけです。confファイルを再実行し、mkinitcpio操作を再実行すると、正しいカーネルファイルを再生成できます。一般に,構成によるカーネルPanicを誤って修正した場合,この環境は大部分の問題を解決できる.

1、多くのプロファイルはLiveCDの中のそのシステムの中で正しいバージョンあるいは手本があって、もし正常な时どんな様子を覚えていないならば、それらを参照することができます;

2、Arch Linuxに対して、chrootから/mntまでの場合、pacstrap指令を直接使用して/mntというマウントポイントをパッケージ管理することができる。

3、2つのttyで操作することができ、chrootから/mntまでの後もLiveCDのファイルシステムから/mntにファイルを転送することができます。

このチュートリアルは、ほとんどのLinuxリリースで使用できるはずです。一部のLinuxユーザーに役立つようにしてください。

Linuxシステムはどのようにデュアルグラフィックスを構成しますか?