「カーネルパニック」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎定義: 内容を追加)
(→‎定義: ノートを追加)
15行目: 15行目:
 
== 定義 ==
 
== 定義 ==
 
Linuxカーネルが回復不能な障害状態になると、カーネルパニックが発生します。この状態は通常、バグのあるハードウェアドライバーが原因で、マシンがデッドロック状態になり、応答しなくなり、再起動が必要になります。デッドロックの直前に、診断メッセージが生成されます。これは、障害が発生したときのマシン状態、障害を認識したカーネル機能につながる呼び出しトレース、および現在ロードされているモジュールのリストです。ありがたいことに、カーネルのメインラインバージョン(公式リポジトリで提供されているものなど)を使用してカーネルパニックが発生することはあまりありませんが、発生した場合は、対処方法を知る必要があります。
 
Linuxカーネルが回復不能な障害状態になると、カーネルパニックが発生します。この状態は通常、バグのあるハードウェアドライバーが原因で、マシンがデッドロック状態になり、応答しなくなり、再起動が必要になります。デッドロックの直前に、診断メッセージが生成されます。これは、障害が発生したときのマシン状態、障害を認識したカーネル機能につながる呼び出しトレース、および現在ロードされているモジュールのリストです。ありがたいことに、カーネルのメインラインバージョン(公式リポジトリで提供されているものなど)を使用してカーネルパニックが発生することはあまりありませんが、発生した場合は、対処方法を知る必要があります。
  +
  +
{{Note|カーネルパニックは、[[Wikipedia:ja:Linux_kernel_oops|OOP]]またはカーネルOOPと呼ばれることもあります。障害状態の結果としてパニックとoopsの両方が発生しますが、oopsはより一般的なものであり、必ずしもデッドロックされたマシンになるわけではありません。カーネルは、問題のあるタスクを強制終了して実行することでoopsから回復できる場合があります。}}
   
 
== すべきこと ==
 
== すべきこと ==

2020年2月21日 (金) 05:31時点における版

この記事またはセクションは情報が古くなっています。
理由: この記事の内容は古くなっており、この記事のとおりに行なえないか、行えても正常に動作しないかもしれません。 (Discuss)

このページでは、起動時のカーネルパニックを修復する方法を説明します。これはカーネルと起動ルーチンに関する記事です。(グラフィカルインターフェイスに関する問題や、プログラムのフリーズなどは他のページを参照してください。)

定義

Linuxカーネルが回復不能な障害状態になると、カーネルパニックが発生します。この状態は通常、バグのあるハードウェアドライバーが原因で、マシンがデッドロック状態になり、応答しなくなり、再起動が必要になります。デッドロックの直前に、診断メッセージが生成されます。これは、障害が発生したときのマシン状態、障害を認識したカーネル機能につながる呼び出しトレース、および現在ロードされているモジュールのリストです。ありがたいことに、カーネルのメインラインバージョン(公式リポジトリで提供されているものなど)を使用してカーネルパニックが発生することはあまりありませんが、発生した場合は、対処方法を知る必要があります。

ノート: カーネルパニックは、OOPまたはカーネルOOPと呼ばれることもあります。障害状態の結果としてパニックとoopsの両方が発生しますが、oopsはより一般的なものであり、必ずしもデッドロックされたマシンになるわけではありません。カーネルは、問題のあるタスクを強制終了して実行することでoopsから回復できる場合があります。

すべきこと

問題はOSが正常に起動しないとうことです。コンピュータがフリーズするかもしれないし、OSがエラーメッセージを表示してくれるかもしれない、もしくは期待した場所(コマンドプロンプトやデスクトップなど)を表示できないかもしれません。 もしコマンドプロンプトを起動できるか、起動ディスクからコマンドプロンプトを起動できるなら、コマンドラインからの基本的なトラブルシューティングが必要となります。

トラブルシューティング

トラブルシューティングを簡単にするため、カーネルがquietモードでないことを確認してください。GRUBの設定のカーネルの行に'quiet'があるなら取り除いてください。 ブート時にカーネルパニックの直前の出力をチェックし、役に立つ情報があるかどうか確認してください。カーネルパニックには、このページに書かれた様々な要因があります。 /bootの設定が正しいことを確認してください。また、ハードウェアが故障していないか確認してください。インストール/レスキューCDなどのユーティリティからmemtestを実行することをおすすめします。 もし/bootの設定に誤りがあるようならば選択肢1に進み、ブートローダの設定を改善してください。 カーネル自身に問題があるようならば選択肢2に進み、最新または古いバージョンのカーネルを再インストールしてください。

選択肢1:ブートローダの設定

ブートローダの設定(/boot/grub/menu.lst など)に誤りがないかを確認します。 ハードディスクのパーティションの変更をした場合は、ルートとカーネルのパーティションの構成が正しいか確認してください。 次に、ファイルにスペルミスがないかを調べてください。余分な空白や不正な文字はカーネルパニックを引き起こす原因になります。

選択肢2:カーネルの再インストール

カーネルの再インストールは、他の主要なシステムを改変していない場合に最善の策です。

インストールCDから起動

インストールCDからArchを起動し、"root"ユーザとしてログインしてください。

# root

パーティションのマウント

起動したら、最小限のGNU/Linux環境といくつかのツールが使えます。標準のrootパーティションを/mntにマウントします。

# mount /dev/sdXY /mnt

ブートパーティションを分けている場合は、ブートパーティションもマウントします。

# mount /dev/sdXZ /mnt/boot

バックアップ

再インストールの前に、新しいカーネルで起動したときに変更したくないデータを、メインパーティションの別ディレクトリやUSBメモリに保存します。

chroot

新しいカーネルは、カーネル環境のセットアップにイニシャルRAMディスク(initrd)を使用します。カーネルを再インストールすると、initrdはmkinitcpioで作り直されます。mkinitcpioはコンピュータの起動にどんなカーネルモジュールが必要であるかを自動検出します。この自動検出を動作させるため、/proc、/sys、/devをマウントします。

# mount -t proc none /mnt/proc
# mount -t sysfs none /mnt/sys
# mount --bind /dev /mnt/dev

マウントしたディレクトリをchrootします。

# chroot /mnt

カーネルのダウングレード

旧バージョンカーネルのpacmanパッケージを持っているなら、簡単にダウングレードができます。 まず、pacmanパッケージを検索します。

# cd /var/cache/pacman/pkg
# find kernel*

pacmanを使ってインストールします。

# pacman -U /var/cache/pacman/pkg/kernel26-2.6.23.xx-x.pkg.tar.gz

pacmanパッケージを持っていないならインストールCDをチェックしてください。例えば、2008.06 i686のCDにはaddons/core-pkgs/kernel26-2.6.25.6-1-i686.pkg.tar.gzが含まれています。

再起動

コンピュータを再起動し、システムの改変によりカーネルパニックを回避できたか確認します。もし古いバージョンのカーネルを使ったなら、何がカーネルの構築に不適切であったのかarch-newspageを忘れずにチェックしてください。 arch-newspageに記述が無い場合には、バグレポートで検索してみてください。 バグレポートも無い場合には、新たにバグレポートを開き、上記のトラブルシューティング中に保存したファイルを添付してください。

ノート: 再起動する前に他に何かした場合、chroot環境を継続しているためログインしなおす必要があります。