一般的なトラブルシューティング

関連記事

• バグ報告ガイドライン
• ステップバイステップデバッグガイド
• デバッグ - トレースを取得
• IRC 共同デバッグ

この記事では一般的なトラブルシューティングの方法を説明しています。特定のアプリケーションの問題については、そのプログラムの wiki ページを参照してください。

基本手順

注意事項

抱えている問題を解決するには、問題のシステムがどう機能しているのかを根本的に理解することが不可欠です。どうやって動いているのか、またエラーを起こさずに動作させるには何が必要なのか？質問に答えるのが用意ではないという場合、問題が発生している機能に関する Archwiki の記事を見ることを強く推奨します。問題のシステムを理解すれば、問題を突き止めるのが楽になるでしょう。

チェックリスト

システムが機能しないときは以下の質問を考えてみてください。各質問の下には、なぜ質問に答えなければならないのか、詳しいデータを入手したりログやジャーナルを確認するにはどのツールを使えばいいのかを載せています。

1. 何が問題ですか？

   出来る限り正確に把握してください。特定の情報を確認するときに、混乱したり横道にそれるのを防ぐためです。

2. エラーメッセージは存在しますか？

   問題に関連するエラーメッセージを含んでいる出力を全て、$HOME/issue.log などのファイルにコピーアンドペーストしてください。例えば、mkinitcpio コマンドの出力を $HOME/issue.log に書き出すには以下のようにします:

   $ mkinitcpio -p linux >> $HOME/issue.log

3. 問題を再現できますか？

   正確に、かつ手順毎に、再現に必要な操作やコマンドを抽出してください。

4. 問題が発生し始めたのはいつからで、問題がなかったときから何を変えましたか？

   アップデートによって問題が発生したのであれば、アップデートしたパッケージを全て挙げてください。バージョン番号や、pacman.log に出力されたテキスト (/var/log/pacman.log) も重要です。また、systemd の systemctl ツールを使って問題のアプリケーションを使うのに必要なサービスの状態を確認してください。たお手羽、以下の systemd コマンドは $HOME/issue.log にサービスの状態を書き込みます:

   $ systemctl status dhcpcd@eth0.service >> $HOME/issue.log

   ノート: >> を使うことで $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 を使うと良いでしょう。pbpst または 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 など、特定のサブシステムのデバッグを有効にするデバッグパラメータも複数存在します。詳しくは カーネルパラメータのドキュメント を見てください。

ノート: 見たいところまでブート時の出力をスクロールバックできない場合、スクロールバックバッファのサイズを大きくしてください。

リカバリシェル

デーモンによるエラーや、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 のビデオカードで画面が表示されない

おそらく Kernel Mode Setting の問題が原因です。モードセッティングを無効にするかビデオポートを変更してみてください。

カーネルのロード中に止まってしまう

acpi=off カーネルパラメータを追加して ACPI を無効化してみてください。

カーネルモジュールのデバッグ

カーネルモジュール#情報を取得を見てください。

ハードウェアのデバッグ

udev#デバッグ出力を見てください。

パッケージ管理

一般的な問題については Pacman#トラブルシューティングを、PGP 鍵に関する問題は pacman-key#トラブルシューティングを見てください。

fuser

fuser はファイルやファイルシステム、TCP/UDP ポートなどのリソースを使ってプロセスを確認するためのコマンドラインユーティリティです。

fuser は psmisc パッケージに入っており、このパッケージは base グループの一部として既にインストールされているはずです。

セッションのパーミッション

ノート: ローカルセッションを動作させるには init システムとして systemd を使う必要があります。systemd は polkit のパーミッションや様々なデバイスの ACL を使うのに必須です (/usr/lib/udev/rules.d/70-uaccess.rules や [1] を参照)。

まず、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 のウェブサイトからメンテナに報告してください。

file: could not find any magic files!

例: パッケージのアップデートやインストールを行った後に以下のエラーが表示される:

# file: could not find any magic files!

上記が表示されるときはシステムが破損しています。問題のあるパッケージを再コンパイル・再インストールしようとしても無駄です。また、initramfs を再生成しようとすると以下のように出力されます:

# mkinitcpio -p linux
==> Building image from preset: 'default'
 -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
file: could not find any magic files!
==> ERROR: invalid kernel specifier: `/boot/vmlinuz-linux'
==> Building image from preset: 'fallback'
 -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
file: could not find any magic files!
@==> ERROR: invalid kernel specifier: `/boot/vmlinuz-linux'

大抵の場合、前にインストールしたアプリケーションによって /etc/ld.so.conf.d/ に作成された設定ファイルや /etc/ld.so.conf に加えられた変更に問題があります。以下の手順で解決できます:

1. Arch Linux のライブ CD / インストールメディアを起動。
2. ルートパーティション (/) を /mnt にマウントして arch-chroot を使ってシステムに chroot。

ノート: arch-chroot では /boot パーティションのマウントはユーザーが行う必要があります。

1. /etc/ld.so.conf を編集して問題のある行を削除する。
2. /etc/ld.so.conf.d/ ディレクトリ内のファイルを確認して問題のあるファイルを削除する。
3. initramfs を再生成:

# mkinitcpio -p linux

1. 再起動する。
2. 起動したら、問題のあるパッケージを再インストール:

# pacman -S <package>

参照

一般

• Fix the Most Common Problems
• A how-to in troubleshooting for newcomers

起動の問題

• 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