一般的なトラブルシューティング
この記事では一般的なトラブルシューティングの方法を説明しています。特定のアプリケーションの問題については、そのプログラムの wiki ページを参照してください。
目次
基本手順
注意事項
抱えている問題を解決するには、問題のシステムがどう機能しているのかを根本的に理解することが不可欠です。どうやって動いているのか、またエラーを起こさずに動作させるには何が必要なのか?質問に答えるのが用意ではないという場合、問題が発生している機能に関する Archwiki の記事を見ることを強く推奨します。問題のシステムを理解すれば、問題を突き止めるのが楽になるでしょう。
チェックリスト
システムが機能しないときは以下の質問を考えてみてください。各質問の下には、なぜ質問に答えなければならないのか、詳しいデータを入手したりログやジャーナルを確認するにはどのツールを使えばいいのかを載せています。
- 何が問題ですか?
- できる限り正確に把握してください。特定の情報を確認するときに、混乱したり横道にそれるのを防ぐためです。
- エラーメッセージは存在しますか?
- 問題に関連するエラーメッセージを含んでいる出力を全て、
$HOME/issue.logなどのファイルにコピーアンドペーストしてください。例えば、mkinitcpio コマンドの出力を$HOME/issue.logに書き出すには以下のようにします: $ mkinitcpio -p linux >> $HOME/issue.log
- 問題に関連するエラーメッセージを含んでいる出力を全て、
- 問題を再現できますか?
- 正確に、かつ手順毎に、再現に必要な操作やコマンドを抽出してください。
- 問題が発生し始めたのはいつからで、問題がなかったときから何を変えましたか?
問題の特定
問題を解決しようとするとき、以下のようなアプローチを取ってはいけません:
アプリケーション X が動作しない。
そうではなくて、正確に観察をしましょう:
A または B の状態のときにアプリケーション X を使って作業 Y を行うと Z というエラーが発生する。
他者のサポート
全ての情報はあなたの目の前にあります。あなたのシステムで何が起きてるのか一番良く知ってるのはあなたのはずです。適切な修正を試みて下さい。
他者のサポートが必要なときは、フォーラム や irc.freenode.net の IRC #archlinux で得ることができるでしょう。
助けを求めるときは、あなたが大事だと考えた部分だけでなく、ログや出力などの情報を全て投稿してください。以下のような情報が対象です:
- コマンドの完全な出力。
- systemd の
journalctlからの出力。systemd.log_level=debugブートパラメータを使うことでさらに詳しい出力を得ることができます。 - ログファイル (
/var/logを確認してください)。 - 関連する設定ファイル。
- 関連するドライバー。
- 関連するパッケージのバージョン。
- カーネル:
dmesg。起動時の問題の場合、最後に表示された10行分程度の出力。場合によってはさらに多くの出力。 - ネットワーク: 関連するコマンドや設定ファイルの実際の出力。
- Xorg:
/var/log/Xorg.0.logや、問題のあるログを上書きした場合は前のログ。 - Pacman: アップグレードによって問題が発生したのであれば
/var/log/pacman.log。
情報を投稿するときはオンラインの pastebin を使うと良いでしょう。pbpstAUR または gist パッケージをインストールすることで情報を自動的にアップロードできます。例えば、systemd のジャーナルをアップロードするには:
# journalctl -xb | pbpst -S
リンクが出力されるのでフォーラムや IRC に貼り付けてください。
質問を投稿する前に、賢い質問のしかた や行動規範も読んでください。
起動時の問題
ブートプロセスの問題を調べるときはカーネルパラメータを変更して、システムを再起動します。
システムが起動できない場合、ライブイメージ から起動して既存の環境に Change Root してください。
コンソールメッセージ
ブートプロセスが完了すると、画面の表示は一度消去されてログインプロンプトが表示されます。ユーザーは init の出力やエラーメッセージを読むことができません。以下のセクションに書かれている方法を使うことでエラーが読めるようになります。
どのオプションを使用した場合でも、起動後に dmesg を使用したり journalctl -b を実行することで起動時からのカーネルメッセージを表示することは可能です。
フロー制御
仮想コンソール (vc) を含む、ほとんど全てのターミナルエミュレータに適用される基本的な制御です:
Ctrl+Sを押して出力を停止Ctrl+Qで復帰
write() のコールがブロックされるため、出力が停止されるだけでなく、ターミナルに出力しようとしているプログラムも停止されます。init がフリーズしているように見える場合、システムコンソールが停止していないか確認してください。
既に表示されているエラーメッセージを見る方法は Getty#tty1 にブートメッセージを残すを参照。
スクロールバック
ビデオアダプタと表示端末の間に、スクロールバックバッファと呼ばれるバッファが作成されることで、テキストコンソールの画面から出てしまったテキストを遡って表示するスクロールバックが可能になっています。デフォルトでは、Shift+PageUp と Shift+PageDown のキーの組み合わせでバッファを上下にスクロールできます。
上限までスクロールしても情報が十分得られない場合、スクロールバックバッファを拡張して、保存できる出力の量を増やす必要があります。fbcon=scrollback:Nk カーネルパラメータでカーネルのフレームバッファコンソール (fbcon) を設定することで拡張できます。N を使用したいバッファサイズ (キロバイト) に置き換えてください。デフォルトのサイズは 32k です。
上記の設定が反映されない場合、フレームバッファコンソールが正しく有効になっていません。Framebuffer Console ドキュメント をみて他のパラメータを設定したり、あるいはフレームバッファドライバーを変更してください。
デバッグ出力
ほとんどのカーネルメッセージは起動時には表示されません。様々なカーネルパラメータを設定することでメッセージを表示させることができます:
debugはカーネルと systemd のデバッグメッセージを有効にします。ignore_loglevelは強制的に全てのカーネルメッセージを表示します。
特定のケースでは、他のパラメータを使用する場合もあります:
earlyprintk=vga,keepはブートプロセスの初期段階でカーネルメッセージを表示します。出力が表示される前にカーネルがクラッシュしてしまう場合に使用してください。EFI 環境ではvgaをefiに変える必要があります。log_buf_len=16Mはカーネルのメッセージバッファを大きくすることで (16MB)、デバッグ出力が上書きされないようにします。
bootmem_debug や sched_debug など、特定のサブシステムのデバッグを有効にするデバッグパラメータも複数存在します。詳しくは カーネルパラメータのドキュメント を見てください。
netconsole
netconsole は、カーネルモジュールで、すべてのカーネルログメッセージ(つまり、dmesg)をユーザースペース(例えば、syslogd)を介さずに別のコンピューターにネットワーク経由で送信します。"netconsole" という名前は誤称で、実際には "コンソール" ではなく、リモートログサービスのようなものです。
これは、組み込みまたはモジュールとして使用できます。組み込みの netconsole は、NICカードの直後に初期化し、指定したインターフェースをできるだけ早く起動します。このモジュールは主に、ヘッドレスマシンからのカーネルパニック出力をキャプチャするため、またはユーザースペースが機能しなくなった他の状況で使用されます。
リカバリシェル
デーモンによるエラーや、fstab の記述が間違っている、またはディスプレイマネージャや Xorg に問題が発生していて、起動できない場合、シングルユーザーランレベルを使うことで問題を修正できることがあります。シングルユーザーモードでは起動後に root シェルだけを表示します。リカバリシェルを起動するカーネルパラメータは複数存在しますが、どれも exit で通常シェルに戻り、カーネルが元の状態に復帰します:
rescueは root ファイルシステムが読み書きできる状態で再マウントされたすぐ後にシェルを起動します。emergencyは更に早く、ファイルシステムがマウントされる前にシェルを起動します。- (何らかの理由で上記のパラメータが使えない場合)
init=/bin/shは init プログラムを root シェルに変えます。rescueとemergencyはどちらも systemd に依存しますが、init=/bin/shはたとえ systemd が壊れても使えます。
また、カーネルパラメータに systemd.debug-shell を追加するか、あるいは debug-shell.service を有効化することで tty9 に root シェルを追加することもできます (Ctrl+Alt+F9 でアクセス可能)。root シェルが開きっぱなしになっているとセキュリティ上危険なので、修復が終わったらサービスは無効化してください。
Intel のビデオカードで画面が表示されない
おそらく カーネルモード設定の問題が原因です。モード設定を無効にするかビデオポートを変更してみてください。
カーネルのロード中に止まってしまう
acpi=off カーネルパラメータを追加して ACPI を無効化してみてください。
カーネルモジュールのデバッグ
カーネルモジュール#情報を取得を見てください。
ハードウェアのデバッグ
udev#デバッグ出力を見てください。
フリーズをデバッグする
残念なことに、通常、フリーズはデバッグが難しく、場合によっては再現に多くの時間を要します。フリーズにはデバッグが比較的容易なものがあります:
- 音は流れ続けていますか? もしそうであれば、ディスプレイがフリーズしているだけかもしれません。これは、ビデオドライバの問題である場合があります。
- マシンはまだ応答していますか? 他の TTY に切り替えることができない場合は、SSH を試してください。
- (もしあれば) ディスクのアクティビティ LED は、ディスクに大量に書き込んでいることを示していますか? 大量のスワップはシステムを一時的にフリーズさせる場合があります。大量に書き込みを行った際のフリーズに関する情報はこの StackExchange の回答を参照してください。
どれもうまく行かない場合、クリーンシャットダウンを試してください。電源ボタンを一回おすとシステムのフリーズが治り、停止中のユニットが出力されるいつもの "シャットダウン画面" が表示されるかもしれません。あるいは、マジック SysRq キーでもクリーンシャットダウンを行うことができるかもしれません。Journal にはマシンのフリーズした理由のヒントが含まれている可能性があるので、クリーンシャットダウンが非常に重要なのです。クリーンでないシャットダウンでは、journal がディスクに書き込まれない場合があります。マシン全体が応答しなくなるハードフリーズは、ログを時間内にディスクに書き込めないので、デバッグがより難しくなります。
フリーズによってディスクに何も書き込めない場合は、リモートログインが役立つかもしれません。リモートログインの方法 (他のデバイスから行う必要があります) は、基本的なデバッグに利用できます:
$ ssh フリーズしているホスト journalctl -f
システム全体が応答しなくなり強制シャットダウンが必要になる深刻なフリーズの多くは、バグのあるファームウェアやドライバ、ハードウェアが関連しているかもしれません。別のカーネル (カーネル#リグレッション デバッグ を参照) や別の Linux ディストリビューションや OS を試したり、ファームウェアのアップデートやハードウェアの診断を行うと問題を見つけられるかもしれません。
フリーズのせいでデバッグに必要なあらゆる種類のログや情報を集められない場合、live 環境でフリーズを再現してみてください。フリーズを再現するためにグラフィカル環境が必要な場合や、archiso でフリーズを再現できる場合は、別のディストリビューションの live 環境を使ってください (フリーズがカーネルのバージョンやパッチに関係している可能性を排除するために、Arch ベースでない Linux を使うことが好ましいです)。live 環境でもフリーズが発生する場合、ハードウェア関連であるかもしれません。フリーズが起こらなくなった場合、両システム間の違いを確認しておく必要があります。異なる構成 (設定)、バージョンやカーネルパラメータの違い、その他の似たような変更により、フリーズが修正されたのかもしれません。
ただし、caps lock の LED が点灯している場合は、カーネルパニックが起こっていることを示している可能性があります。環境によっては、カーネルパニックが発生したときに TTY が表示されない場合があります。これは混乱を招き、他の種類のフリーズと勘違いしてしまうかもしれません。
リグレッションをデバッグする
アップデートが問題を引き起こし、特定のパッケージを ダウングレード すると解決する場合、それはおそらく regression でしょう。リグレッションのデバッグで最も重要なのは、問題がすでに修正されているかどうかを確認することです。これを行うには、まずアプリケーションが完全にアップデートされていることを確認します(例えば、アプリケーションが公式リポジトリにあるのと同じバージョンであることを確認します)。もし既にアップデートされていたり、アップデートしても問題が解決しない場合は、実際の最新版を使ってみてください、通常は -git バージョンで、既に AUR にパッケージされていることがあります。もしこれで問題が解決し、修正されたバージョンがまだ公式リポジトリにない場合は、新しいバージョンが公式リポジトリに届くまで待ち、それに戻してください。
それでも問題が解決しない場合、問題をデバッグするかアプリケーションを bisect して、バグが修正されるようにアップストリームのバグトラッカーに報告してください。
カーネルのアップグレード後に一部の周辺機器が使用できない
この現象は、一般的に以下のように現れます (しかし、これだけではないでしょう):
- 新たに挿入した USB デバイスが dmesg に現れるが、
/dev/には現れない。 - カーネルアップデート前に使用したことのないファイルシステムをマウントできない。
- ノート PC で、カーネルアップデート前に有線/無線接続を使用したことのない場合、有線/無線接続を使用できない。
- modprobe を使って、カーネルパッケージのアップデート前に使用したことのないモジュールをロードしようとすると、
FATAL: Module module not found in directory /lib/module/kernelversion。
システムメンテナンス#アップグレード後に再起動 で部分的に説明されている通り、カーネルのパッケージをアップデートしたとしても、再起動しない限り、カーネル自体はアップデートされません。一方、/usr/lib/modules/kernelversion/ 内のカーネルモジュールは、新しいカーネルがインストールされた際に pacman によって削除されます。FS#16702 で説明されている通り、この方法により、パッケージマネージャによって管理されないファイルをシステム上に残留させてしまうことを防ぐことができますが、先に挙げたような症状を引き起こしてしまいます。この問題を解決するには、カーネルのアップデート後に計画的に再起動してください。将来的には (まだ、実装されていませんが)、バージョン管理されたカーネルパッケージを使用することになるでしょう: 主な障害は、もはや必要とされなくなった以前のカーネルバージョンの削除をどう処理するかにあります。
もう一つの解決策は、kernel-modules-hook を使うことです。2つの pacman フックが含まれており、rsync を使ってカーネルアップデート後にカーネルモジュールをファイルシステム上に保持し、有効化されてから4週間後に削除すべき古いモジュールをマークする linux-modules-cleanup.service を使用します。
パッケージ管理
一般的な問題については Pacman#トラブルシューティングを、PGP 鍵に関する問題は pacman-key#トラブルシューティングを見てください。
壊れたシステムを修復する
部分アップグレード が実行された場合は、システム全体をアップデートしてみてください。再起動が必要になる場合があります。
# pacman -Syu
GUI で起動していて、それが失敗する場合は、Ctrl+Alt+F1 から Ctrl+Alt+F6 を押して、動作中の tty にアクセスして pacman を実行できます。
システムが壊れて pacman を実行できない場合は、Arch ISO を USB フラッシュドライブ、光ディスク、または PXE を使用したネットワークから起動します。 (インストールガイドの残りの部分には従わないでください。)
root ファイルシステムをマウントします:
[ISO] # mount /dev/rootFileSystemDevice /mnt
個別に作成した他のパーティションをマウントし、すべてのパーティションにプレフィックス /mnt を追加します。つまり、次のようになります:
[ISO] # mount /dev/bootDevice /mnt/boot
システムの pacman を使用してみてください:
[ISO] # arch-chroot /mnt [chroot] # pacman -Syu
失敗した場合は、chroot を終了して、次のことを試してください:
[ISO] # pacman -Syu --sysroot /mnt
失敗した場合は、次のことを試してください:
[ISO] # pacman -Syu --root /mnt --cachedir /mnt/var/cache/pacman/pkg
fuser
fuser はファイルやファイルシステム、TCP/UDP ポートなどのリソースを使ってプロセスを確認するためのコマンドラインユーティリティです。
fuser は psmisc パッケージに入っており、このパッケージは base メタパッケージの依存関係として既にインストールされているはずです。
セッションのパーミッション
まず、X の中に有効なローカルセッションがあることを確認してください:
$ loginctl show-session $XDG_SESSION_ID
このコマンドの出力に Remote=no と Active=yes が含まれていなければなりません。含まれていない場合は、X がログインを行った tty と同一の tty で動作していることを確認してください。logind セッションを維持するために tty が同一である必要があります。このことはデフォルトの /etc/X11/xinit/xserverrc によって管理されています。
D-Bus セッションも X と一緒に起動する必要があります。詳しくは D-Bus#ユーザーセッションの起動を見てください。
基本的な polkit のアクションはそれ以上の設定を必要としませんが、ローカルセッションだけでなく他の認証を必要とする polkit アクションも存在します。認証するには polkit 認証エージェントを実行する必要があります。詳しくは polkit#認証エージェントを見て下さい。
プログラムを使用しようとすると、以下のようなエラーが出力される場合:
error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory
pacman や pkgfile を使って存在しないライブラリが入っているパッケージはどれか検索してください:
$ pacman -Fs libusb-0.1.so.4
extra/libusb-compat 0.1.5-1
usr/lib/libusb-0.1.so.4
上記の場合、libusb-compat パッケージをインストールしてください。
インストールしたプログラムのパッケージの PKGBUILD に依存パッケージとしてライブラリが記載されていないという可能性もあります。公式パッケージの場合、バグとして報告してください。AUR のパッケージの場合、AUR のウェブサイトからメンテナに報告してください。
参照
- 一般
- 起動の問題
- Memtest86+
- List of Tools for UBCD - memtest のように menu.lst に追加できます。
- Wikipedia の BIOS Boot partition のページ
- QA/Sysrq - sysrq の使用方法
- systemd のドキュメント: Debug Logging to a Serial Console
- How to Isolate Linux ACPI Issues