「一般的なトラブルシューティング」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(同期)
8行目: 8行目:
 
{{Related|ステップバイステップデバッグガイド}}
  
{{Related|ステップバイステップデバッグガイド}}
 
{{Related|デバッグ - トレースを取得}}
  
{{Related|デバッグ - トレースを取得}}
−
{{Related|ブートデバッグ}}
  
 
{{Related3|IRC Collaborative Debugging|IRC 共同デバッグ}}
  
{{Related3|IRC Collaborative Debugging|IRC 共同デバッグ}}
 
{{Related articles end}}
  
{{Related articles end}}
14行目: 13行目:
 
この記事では一般的なトラブルシューティングの方法を説明しています。特定のアプリケーションの問題については、そのプログラムの wiki ページを参照してください。
  
この記事では一般的なトラブルシューティングの方法を説明しています。特定のアプリケーションの問題については、そのプログラムの wiki ページを参照してください。
   
−
== 注意事項 ==
 +
== 基本手順 ==
  +
  +
=== 注意事項 ===
   
 
抱えている問題を解決するには、問題のシステムがどう機能しているのかを根本的に理解することが不可欠です。どうやって動いているのか、またエラーを起こさずに動作させるには何が必要なのか？質問に答えるのが用意ではないという場合、問題が発生している機能に関する [[メインページ|Archwiki]] の記事を見ることを強く推奨します。問題のシステムを理解すれば、問題を突き止めるのが楽になるでしょう。
  
抱えている問題を解決するには、問題のシステムがどう機能しているのかを根本的に理解することが不可欠です。どうやって動いているのか、またエラーを起こさずに動作させるには何が必要なのか？質問に答えるのが用意ではないという場合、問題が発生している機能に関する [[メインページ|Archwiki]] の記事を見ることを強く推奨します。問題のシステムを理解すれば、問題を突き止めるのが楽になるでしょう。
   
−
== チェックリスト ==
 +
=== チェックリスト ===
   
  +
システムが機能しないときは以下の質問を考えてみてください。各質問の下には、なぜ質問に答えなければならないのか、詳しいデータを入手したりログやジャーナルを確認するにはどのツールを使えばいいのかを載せています。
−
The following gives a number of questions for you whenever dealing with a malfunctioning system. Under each question there are notes explaining how you should be answering each question, followed by some light examples on how to easily gather data output and what tools can be used to review logs and the journal.
  
   
 
# 何が問題ですか？
  
# 何が問題ですか？
 
#: 出来る限り正確に把握してください。特定の情報を確認するときに、混乱したり横道にそれるのを防ぐためです。
  
#: 出来る限り正確に把握してください。特定の情報を確認するときに、混乱したり横道にそれるのを防ぐためです。
 
# エラーメッセージは存在しますか？
  
# エラーメッセージは存在しますか？
  +
#: 問題に関連するエラーメッセージを含んでいる出力を全て、{{ic|$HOME/issue.log}} などのファイルにコピーアンドペーストしてください。例えば、[[mkinitcpio]] コマンドの出力を {{ic|$HOME/issue.log}} に書き出すには以下のようにします:
−
#: Copy and paste ''full outputs'' that contain '''error messages''' related to your issue into a separate file, such as {{ic|$HOME/issue.log}}. For example, to forward the output of the following [[mkinitcpio]] command to {{ic|$HOME/issue.log}}:
  
 
#: {{bc|$ mkinitcpio -p linux >> $HOME/issue.log''}}
  
#: {{bc|$ mkinitcpio -p linux >> $HOME/issue.log''}}
 
# 問題を再現できますか？
  
# 問題を再現できますか？
  +
#: 正確に、かつ手順毎に、再現に必要な操作やコマンドを抽出してください。
−
#: If so, give ''exact'' '''step-by-step''' instructions/commands needed to do so.
  
  +
# 問題が発生し始めたのはいつからで、問題がなかったときから何を変えましたか？
−
# When did you first encounter these issues and what was changed between then and when the system was operating without error?
  
−
#:If it occurred right after an update then, list '''all packages that were updated'''. Include ''version numbers'', also, paste the entire update from [[pacman]].log ({{ic|/var/log/pacman.log}}). Also take note of the statuses of ''any'' service(s) needed to support the malfunctioning application(s) using [[systemd]]'s systemctl tools. For example, to forward the output of the following [[Systemd#systemctl の基本的な使い方|systemd]] command to {{ic|$HOME/issue.log}}:
 +
#:アップデートによって問題が発生したのであれば、アップデートしたパッケージを全て挙げてください。バージョン番号や、[[pacman]].log に出力されたテキスト ({{ic|/var/log/pacman.log}}) も重要です。また、[[systemd]] の systemctl ツールを使って問題のアプリケーションを使うのに必要なサービスの状態を確認してください。たお手羽、以下の [[Systemd#systemctl の基本的な使い方|systemd]] コマンドは {{ic|$HOME/issue.log}} にサービスの状態を書き込みます:
 
#: {{bc|$ systemctl status dhcpcd@eth0.service >> $HOME/issue.log}}
  
#: {{bc|$ systemctl status dhcpcd@eth0.service >> $HOME/issue.log}}
−
#: {{Note|Using {{ic|'''>>'''}} will ensure any previous text in {{ic|$HOME/issue.log}} will not be overwritten.}}
 +
#: {{Note|{{ic|'''>>'''}} を使うことで {{ic|$HOME/issue.log}} 内のテキストが上書きされないようにしています。}}
   
−
== 問題の特定 ==
 +
=== 問題の特定 ===
   
 
問題を解決しようとするとき、以下のようなアプローチを取ってはいけません:
  
問題を解決しようとするとき、以下のようなアプローチを取ってはいけません:
44行目: 45行目:
 
''A または B の状態のときにアプリケーション X を使って作業 Y を行うと Z というエラーが発生する。''
  
''A または B の状態のときにアプリケーション X を使って作業 Y を行うと Z というエラーが発生する。''
   
−
== 他者のサポート ==
 +
=== 他者のサポート ===
   
 
全ての情報はあなたの目の前にあります。あなたのシステムで何が起きてるのか一番良く知ってるのはあなたのはずです。適切な修正を試みて下さい。
  
全ての情報はあなたの目の前にあります。あなたのシステムで何が起きてるのか一番良く知ってるのはあなたのはずです。適切な修正を試みて下さい。
   
 
他者のサポートが必要なときは、[https://bbs.archlinuxjp.org フォーラム] や irc.freenode.net の IRC #archlinux で得ることができるでしょう。
  
他者のサポートが必要なときは、[https://bbs.archlinuxjp.org フォーラム] や irc.freenode.net の IRC #archlinux で得ることができるでしょう。
  +
  +
助けを求めるときは、あなたが大事だと考えた部分だけでなく、ログや出力などの情報を全て投稿してください。以下のような情報が対照です:
  +
  +
* コマンドの完全な出力。
  +
* systemd の {{ic|journalctl}} からの出力。{{ic|1=systemd.log_level=debug}} ブートパラメータを使うことでさらに詳しい出力を得ることができます。
  +
* ログファイル ({{ic|/var/log}} を確認してください)。
  +
* 関連する設定ファイル。
  +
* 関連するドライバー。
  +
* 関連するパッケージのバージョン。
  +
* カーネル: {{ic|dmesg}}。起動時の問題の場合、最後に表示された10行分程度の出力。場合によってはさらに多くの出力。
  +
* ネットワーク: 関連するコマンドや設定ファイルの実際の出力。
  +
* Xorg: {{ic|/var/log/Xorg.0.log}} や、問題のあるログを上書きした場合は前のログ。
  +
* Pacman: アップグレードによって問題が発生したのであれば {{ic|/var/log/pacman.log}}。
  +
  +
情報を投稿するときはオンラインの pastebin を使うと良いでしょう。{{pkg|pbpst}} または {{pkg|gist}} パッケージを[[インストール]]することで情報を自動的にアップロードできます。例えば、systemd のジャーナルをアップロードするには:
  +
  +
# journalctl -xb | pbpst -S
  +
  +
リンクが出力されるのでフォーラムや IRC に貼り付けてください。
  +
  +
質問を投稿する前に、[http://www.ranvis.com/articles/smart-questions.ja.html 賢い質問のしかた] や[[行動規範]]も読んでください。
  +
  +
== 起動時の問題 ==
  +
  +
[[ブートプロセス]]の問題を調べるときは[[カーネルパラメータ]]を変更して、システムを再起動します。
  +
  +
システムが起動できない場合、[https://www.archlinuxjp.org/download/ ライブイメージ] から起動して既存の環境に [[Change Root]] してください。
  +
  +
=== コンソールメッセージ ===
  +
  +
ブートプロセスが完了すると、画面の表示は一度消去されてログインプロンプトが表示されます。ユーザーは init の出力やエラーメッセージを読むことができません。以下のセクションに書かれている方法を使うことでエラーが読めるようになります。
  +
  +
どのオプションを使用した場合でも、起動後に {{ic|dmesg}} を使用したり {{ic|journalctl -b}} を実行することで起動時からのカーネルメッセージを表示することは可能です。
  +
  +
==== フロー制御 ====
  +
  +
仮想端末 (vc) を含む、ほとんど全てのターミナルエミュレータに適用される基本的な制御です:
  +
* {{ic|Ctrl+S}} を押して出力を停止
  +
* {{ic|Ctrl+Q}} で復帰
  +
  +
{{ic|write()}} のコールがブロックされるため、出力が停止されるだけでなく、ターミナルに出力しようとしているプログラムも停止されます。''init'' がフリーズしているように見える場合、システムコンソールが停止していないか確認してください。
  +
  +
既に表示されているエラーメッセージを見る方法は [[Getty#tty1 にブートメッセージを残す]]を参照。
  +
  +
==== スクロールバック ====
  +
  +
ビデオアダプタと表示端末の間に、スクロールバックバッファと呼ばれるバッファが作成されることで、テキストコンソールの画面から出てしまったテキストを遡って表示するスクロールバックが可能になっています。デフォルトでは、{{ic|Shift+PageUp}} と {{ic|Shift+PageDown}} のキーの組み合わせでバッファを上下にスクロールできます。
  +
  +
上限までスクロールしても情報が十分得られない場合、スクロールバックバッファを拡張して、保存できる出力の量を増やす必要があります。{{ic|1=fbcon=scrollback:Nk}} [[カーネルパラメータ]]でカーネルのフレームバッファコンソール (fbcon) を設定することで拡張できます。{{ic|N}} を使用したいバッファサイズ (キロバイト) に置き換えてください。デフォルトのサイズは 32k です。
  +
  +
上記の設定が反映されない場合、フレームバッファコンソールが正しく有効になっていません。[https://www.kernel.org/doc/Documentation/fb/fbcon.txt Framebuffer Console ドキュメント] をみて他のパラメータを設定したり、あるいはフレームバッファドライバーを変更してください。
  +
  +
==== デバッグ出力 ====
  +
  +
ほとんどのカーネルメッセージは起動時には表示されません。様々なカーネルパラメータを設定することでメッセージを表示させることができます:
  +
  +
* {{ic|debug}} はカーネルと [[systemd]] のデバッグメッセージを有効にします。
  +
* {{ic|ignore_loglevel}} は強制的に全てのカーネルメッセージを表示します。
  +
  +
特定のケースでは、他のパラメータを使用する場合もあります:
  +
* {{ic|1=earlyprintk=vga,keep}} はブートプロセスの初期段階でカーネルメッセージを表示します。出力が表示される前にカーネルがクラッシュしてしまう場合に使用してください。[[EFI]] 環境では {{ic|vga}} を {{ic|efi}} に変える必要があります。
  +
* {{ic|1=log_buf_len=16M}} はカーネルのメッセージバッファを大きくすることで (16MB)、デバッグ出力が上書きされないようにします。
  +
  +
{{ic|bootmem_debug}} や {{ic|sched_debug}} など、特定のサブシステムのデバッグを有効にするデバッグパラメータも複数存在します。詳しくは [https://www.kernel.org/doc/Documentation/kernel-parameters.txt カーネルパラメータのドキュメント] を見てください。
  +
  +
{{Note|見たいところまでブート時の出力をスクロールバックできない場合、[[#スクロールバック|スクロールバックバッファ]]のサイズを大きくしてください。}}
  +
  +
=== リカバリシェル ===
  +
  +
デーモンによるエラーや、fstab の記述が間違っている、またはディスプレイマネージャや Xorg に問題が発生していて、起動できない場合、シングルユーザー[[systemd#ターゲット|ランレベル]]を使うことで問題を修正できることがあります。シングルユーザーモードでは起動後に root シェルだけを表示します。リカバリシェルを起動するカーネルパラメータは複数存在しますが、どれも {{ic|exit}} で通常シェルに戻り、カーネルが元の状態に復帰します:
  +
* {{ic|rescue}} は root ファイルシステムが読み書きできる状態で再マウントされたすぐ後にシェルを起動します。
  +
* {{ic|emergency}} は更に早く、ファイルシステムがマウントされる前にシェルを起動します。
  +
* (何らかの理由で上記のパラメータが使えない場合) {{ic|1=init=/bin/sh}} は init プログラムを root シェルに変えます。{{ic|rescue}} と {{ic|emergency}} はどちらも [[systemd]] に依存しますが、{{ic|1=init=/bin/sh}} はたとえ ''systemd'' が壊れても使えます。
  +
  +
また、[[カーネルパラメータ]]に {{ic|systemd.debug-shell}} を追加するか、あるいは {{ic|debug-shell.service}} を[[有効化]]することで {{ic|tty9}} に root シェルを追加することもできます (Ctrl+Alt+F9 でアクセス可能)。root シェルが開きっぱなしになっているとセキュリティ上危険なので、修復が終わったらサービスは無効化してください。
  +
  +
=== Intel のビデオカードで画面が表示されない ===
  +
  +
おそらく [[Kernel Mode Setting]] の問題が原因です。[[Kernel Mode Setting#モードセッティングを無効にする|モードセッティングを無効にする]]か[[Intel Graphics#KMS Issue: コンソールの画面が狭い|ビデオポートを変更]]してみてください。
  +
  +
=== カーネルのロード中に止まってしまう ===
  +
  +
{{ic|1=acpi=off}} [[カーネルパラメータ]]を追加して ACPI を無効化してみてください。
  +
  +
=== カーネルモジュールのデバッグ ===
  +
  +
[[カーネルモジュール#情報を取得]]を見てください。
  +
  +
=== ハードウェアのデバッグ ===
  +
  +
[[udev#デバッグ出力]]を見てください。
  +
  +
== パッケージ管理 ==
  +
  +
一般的な問題については [[Pacman#トラブルシューティング]]を、PGP 鍵に関する問題は [[pacman-key#トラブルシューティング]]を見てください。
  +
  +
== fuser ==
  +
  +
''fuser'' はファイルやファイルシステム、TCP/UDP ポートなどのリソースを使ってプロセスを確認するためのコマンドラインユーティリティです。
  +
  +
''fuser'' は {{Pkg|psmisc}} パッケージに入っており、このパッケージは {{Grp|base}} グループの一部として既にインストールされているはずです。
   
 
== セッションのパーミッション ==
  
== セッションのパーミッション ==
60行目: 162行目:
 
このコマンドの出力に {{ic|1=Remote=no}} と {{ic|1=Active=yes}} が含まれていなければなりません。含まれていない場合は、X がログインを行った tty と同一の tty で動作していることを確認してください。logind セッションを維持するために tty が同一である必要があります。このことはデフォルトの {{ic|/etc/X11/xinit/xserverrc}} によって管理されています。
  
このコマンドの出力に {{ic|1=Remote=no}} と {{ic|1=Active=yes}} が含まれていなければなりません。含まれていない場合は、X がログインを行った tty と同一の tty で動作していることを確認してください。logind セッションを維持するために tty が同一である必要があります。このことはデフォルトの {{ic|/etc/X11/xinit/xserverrc}} によって管理されています。
   
−
D-Bus セッションも X と一緒に起動する必要があります。詳しくは [[D-Bus#ユーザーセッションの起動]] を見て下さい。
 +
D-Bus セッションも X と一緒に起動する必要があります。詳しくは [[D-Bus#ユーザーセッションの起動]]を見てください。
   
−
基本的な [[polkit]] のアクションはそれ以上の設定を必要としませんが、ローカルセッションだけでなく他の認証を必要とする polkit アクションも存在します。認証するには polkit 認証エージェントを実行する必要があります。詳しくは [[polkit#認証エージェント]] を見て下さい。
 +
基本的な [[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]] を使って存在しないライブラリが入っているパッケージはどれか検索してください:
  +
  +
{{hc|$ pacman -Fs libusb-0.1.so.4|
  +
extra/libusb-compat 0.1.5-1
  +
usr/lib/libusb-0.1.so.4
  +
}}
  +
  +
上記の場合、{{Pkg|libusb-compat}} パッケージを[[インストール]]してください。
   
  +
インストールしたプログラムのパッケージの [[PKGBUILD]] に依存パッケージとしてライブラリが記載されていないという可能性もあります。公式パッケージの場合、[[バグ報告ガイドライン|バグとして報告]]してください。[[AUR]] のパッケージの場合、AUR のウェブサイトからメンテナに報告してください。
−
[[ブートデバッグ]]を見て下さい。
  
   
 
== file: could not find any magic files! ==
  
== file: could not find any magic files! ==
   
  +
''例:'' パッケージのアップデートやインストールを行った後に以下のエラーが表示される:
−
''Example:'' After an every-day routine update or following the installation of a package you are given the following error:
  
 
# file: could not find any magic files!
  
# file: could not find any magic files!
  +
上記が表示されるときはシステムが破損しています。問題のあるパッケージを再コンパイル・再インストールしようとしても無駄です。また、[[initramfs]] を再生成しようとすると以下のように出力されます:
−
This will most likely leave your system crippled. And, any attempts made to recompile/reinstall the package(s) responsible for the breakage will fail. Also, any attempts made to try to rebuild the [[mkinitcpio|initramfs]] will result in the following:
  
 
# mkinitcpio -p linux
  
# mkinitcpio -p linux
 
==> Building image from preset: 'default'
  
==> Building image from preset: 'default'
83行目: 198行目:
 
@==> ERROR: invalid kernel specifier: `/boot/vmlinuz-linux'
  
@==> ERROR: invalid kernel specifier: `/boot/vmlinuz-linux'
   
  +
大抵の場合、前にインストールしたアプリケーションによって {{ic|/etc/ld.so.conf.d/}} に作成された設定ファイルや {{ic|/etc/ld.so.conf}} に加えられた変更に問題があります。以下の手順で解決できます:
−
Typically a previously installed application had placed a configuration file within {{ic|/etc/ld.so.conf.d/}} or it had made changes to {{ic|/etc/ld.so.conf}} which are now invalid.
  
−
#Boot into the Arch Linux Live CD / Installation Media.
 +
#Arch Linux のライブ CD / インストールメディアを起動。
−
#Mount your root ({{ic|'''/'''}}) partition to {{ic|/mnt}} and using [[Change Root#Change_root|arch-chroot]], [[Change Root|chroot]] into your system.
 +
#ルートパーティション ({{ic|'''/'''}}) を {{ic|/mnt}} にマウントして [[Change Root#arch-chroot を使う|arch-chroot]] を使ってシステムに [[chroot]]。
−
{{Note|[[Change Root#Change_root|arch-chroot]] leaves mounting the {{ic|/boot}} partition up to the user.}}
 +
{{Note|[[Change Root#arch-chroot を使う|arch-chroot]] では {{ic|/boot}} パーティションのマウントはユーザーが行う必要があります。}}
−
#Examine {{ic|/etc/ld.so.conf}} and remove any invalid lines found.
 +
#{{ic|/etc/ld.so.conf}} を編集して問題のある行を削除する。
  +
#{{ic|/etc/ld.so.conf.d/}} ディレクトリ内のファイルを確認して問題のあるファイルを削除する。
−
#Examine the files located inside the directory {{ic|/etc/ld.so.conf.d/}} and remove all invalid files.
  
−
#Rebuild the [[initramfs]].
 +
#[[initramfs]] を再生成:
 
# mkinitcpio -p linux
  
# mkinitcpio -p linux
  +
#再起動する。
−
#Reboot back to your installed system.
  
  +
#起動したら、問題のあるパッケージを再インストール:
−
#Once booted, reinstall the package that was responsible for leaving your system inoperable using:
  
 
# pacman -S <package>
  
# pacman -S <package>
   
−
== fuser ==
 +
== 参照 ==
−  
−
''fuser'' はファイルやファイルシステム、TCP/UDP ポートなどのリソースを使ってプロセスを確認するためのコマンドラインユーティリティです。
  
−
 
−
''fuser'' は {{Pkg|psmisc}} パッケージに入っており、このパッケージは {{Grp|base}} グループの一部として既にインストールされているはずです。
  
−  
−
== NTFS パーティションに書き込みできない ==
  
−
標準では、NTFS ファイルシステムの読み込みしか出来ないようになっています。書き込みを行いたい場合は、{{Pkg|ntfs-3g}} パッケージをインストールしてください。
  
   
  +
;一般
−
== Spellcheck を実行するとテキストが全部ミス判定されてしまう ==
  
−
{{Pkg|aspell}} 辞書はインストールされていますか? {{ic|pacman -Ss aspell}} を実行して、入手可能な辞書を確認してください。
  
   
  +
*[http://www.maximumpc.com/article/features/linux_troubleshooting_guide_fix_most_common_problems Fix the Most Common Problems]
−
インストールされている辞書は {{ic|aspell dicts}} で確認できます:
  
  +
*[https://www.reddit.com/r/archlinux/comments/tjjwr/archlinux_a_howto_in_troubleshooting_for_newcomers/ A how-to in troubleshooting for newcomers]
−
{{hc|$ aspell dicts|
  
−
en
  
−
en_GB
  
−
...etc}}
  
   
  +
;起動の問題
−
aspell および辞書がインストールされていても問題が解決しない場合、{{ic|enchant}} が原因かもしれません。{{ic|/usr/share/enchant/enchant.ordering}} を確認し、目的の言語が期待した設定になっているか確認してください。
  
   
  +
* [http://www.memtest.org/ Memtest86+]
−
== 参照 ==
  
  +
* [http://wiki.ultimatebootcd.com/index.php?title=Tools List of Tools for UBCD] - memtest のように menu.lst に追加できます。
−  
  +
* Wikipedia の [[Wikipedia:BIOS Boot partition|BIOS Boot partition]] のページ
−
*[http://www.maximumpc.com/article/features/linux_troubleshooting_guide_fix_most_common_problems Fix the Most Common Problems]
  
  +
* [https://fedoraproject.org/wiki/QA/Sysrq QA/Sysrq] - sysrq の使用方法
−
*[https://www.reddit.com/r/archlinux/comments/tjjwr/archlinux_a_howto_in_troubleshooting_for_newcomers/ A how-to in troubleshooting for newcomers]
  
  +
* systemd のドキュメント: [http://freedesktop.org/wiki/Software/systemd/Debugging#Debug_Logging_to_a_Serial_Console Debug Logging to a Serial Console]
  +
* [https://web.archive.org/web/20120217124742/http://www.lesswatts.org/projects/acpi/debug.php How to Isolate Linux ACPI Issues]

2016年12月6日 (火) 01:09時点における版

関連記事

この記事では一般的なトラブルシューティングの方法を説明しています。特定のアプリケーションの問題については、そのプログラムの 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>

参照

一般
起動の問題
「https://wiki.archlinux.jp/index.php?title=一般的なトラブルシューティング&oldid=6653」から取得