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

提供: ArchWiki
ナビゲーションに移動 検索に移動
 
(Pkg/AUR テンプレートの更新)
(4人の利用者による、間の15版が非表示)
1行目: 1行目:
[[Category:System administration (日本語)]]
+
[[Category:システム管理]]
[[Category:System recovery (日本語)]]
+
[[Category:システムリカバリ]]
 
[[en:General troubleshooting]]
 
[[en:General troubleshooting]]
[[es:General Troubleshooting]]
+
[[es:General troubleshooting]]
  +
[[ru:General troubleshooting]]
{{Related articles start (日本語)}}
 
  +
[[zh-hans:General troubleshooting]]
{{Related2|Reporting Bug Guidelines (日本語)|バグ報告ガイドライン}}
 
  +
{{Related articles start}}
{{Related2|Step By Step Debugging Guide|ステップバイステップデバッグガイド}}
 
  +
{{Related|バグ報告ガイドライン}}
{{Related2|Debug - Getting Traces|デバッグ - トレースの取得}}
 
{{Related2|Boot debugging|ブートデバッグ}}
+
{{Related|ステップバイステップデバッグガイド}}
  +
{{Related|デバッグ - トレースを取得}}
{{Related2|IRC Collaborative Debugging|IRC 共同デバッグ}}
 
  +
{{Related|IRC 共同デバッグ}}
 
{{Related articles end}}
 
{{Related articles end}}
   
 
この記事では一般的なトラブルシューティングの方法を説明しています。特定のアプリケーションの問題については、そのプログラムの wiki ページを参照してください。
 
この記事では一般的なトラブルシューティングの方法を説明しています。特定のアプリケーションの問題については、そのプログラムの wiki ページを参照してください。
   
== 注意事項 ==
+
== 基本手順 ==
   
  +
=== 注意事項 ===
In order to resolve an issue that you are having, it is ''absolutely crucial'' to have a firm understanding of how that specific system functions. How it works, and what does it need to run without error? If you cannot comfortably answer these question then it is strongly advised that you review the [[Table of contents|Archwiki]] article for the function that you are having troubles with. Once you feel like you've understood the specific system, it will be easier for you to pin-point the problem.
 
   
  +
抱えている問題を解決するには、問題のシステムがどう機能しているのかを根本的に理解することが不可欠です。どうやって動いているのか、またエラーを起こさずに動作させるには何が必要なのか?質問に答えるのが用意ではないという場合、問題が発生している機能に関する [[メインページ|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.
 
   
  +
システムが機能しないときは以下の質問を考えてみてください。各質問の下には、なぜ質問に答えなければならないのか、詳しいデータを入手したりログやジャーナルを確認するにはどのツールを使えばいいのかを載せています。
# What is the issue(s)?
 
  +
#: Be ''as precise as possible''. This will help you not get confused and/or side-tracked when looking up specific information.
 
  +
# 何が問題ですか?
# Are there error messages? (if any)
 
  +
#: 出来る限り正確に把握してください。特定の情報を確認するときに、混乱したり横道にそれるのを防ぐためです。
#: 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}}:
 
  +
# エラーメッセージは存在しますか?
  +
#: 問題に関連するエラーメッセージを含んでいる出力を全て、{{ic|$HOME/issue.log}} などのファイルにコピーアンドペーストしてください。例えば、[[mkinitcpio]] コマンドの出力を {{ic|$HOME/issue.log}} に書き出すには以下のようにします:
 
#: {{bc|$ mkinitcpio -p linux >> $HOME/issue.log''}}
 
#: {{bc|$ mkinitcpio -p linux >> $HOME/issue.log''}}
  +
# 問題を再現できますか?
# Can you reproduce the issue?
 
  +
#: 正確に、かつ手順毎に、再現に必要な操作やコマンドを抽出してください。
#: 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?
 
  +
#:アップデートによって問題が発生したのであれば、アップデートしたパッケージを全て挙げてください。バージョン番号や、[[pacman]].log に出力されたテキスト ({{ic|/var/log/pacman.log}}) も重要です。また、[[systemd]] の systemctl ツールを使って問題のアプリケーションを使うのに必要なサービスの状態を確認してください。例えば、以下の [[Systemd#systemctl の基本的な使い方|systemd]] コマンドは {{ic|$HOME/issue.log}} にサービスの状態を書き込みます:
#: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#Basic_systemctl_usage|systemd]] command to {{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}} 内のテキストが上書きされないようにしています。}}
   
== 問題の特定 ==
+
=== 問題の特定 ===
   
  +
問題を解決しようとするとき、以下のようなアプローチを取ってはいけません:
When attempting to resolve an issue, '''never''' approach it as:
 
   
  +
''アプリケーション X が動作しない。''
''Application X does not work.''
 
   
  +
そうではなくて、正確に観察をしましょう:
Instead, look at it in its entirety:
 
   
  +
''A または B の状態のときにアプリケーション X を使って作業 Y を行うと Z というエラーが発生する。''
''Application X produces Y error(s) when performing Z tasks under conditions A and B.
 
   
== 他者のサポート ==
+
=== 他者のサポート ===
   
  +
全ての情報はあなたの目の前にあります。あなたのシステムで何が起きてるのか一番良く知ってるのはあなたのはずです。適切な修正を試みて下さい。
With all the information in front of you. You should have a good idea as to what is going on with the system. And you can now start working on a proper fix.
 
   
If you require any additional support, it can be found on [https://bbs.archlinux.org the forums] or IRC at irc.freenode.net #archlinux
+
他者のサポートが必要なときは、[https://bbs.archlinux.jp フォーラム] 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.archlinux.jp/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}} パッケージに入っており、このパッケージは {{Pkg|base}} グループの一部として既にインストールされているはずです。
   
 
== セッションのパーミッション ==
 
== セッションのパーミッション ==
   
{{Note|ローカルセッションを動作させるには init システムとして [[systemd (日本語)|systemd]] を使う必要があります。systemd は polkit のパーミッションや様々なデバイスの ACL を使うのに必須です ({{ic|/usr/lib/udev/rules.d/70-uaccess.rules}} や [http://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/] を参照)。}}
+
{{Note|ローカルセッションを動作させるには init システムとして [[systemd]] を使う必要があります。systemd は polkit のパーミッションや様々なデバイスの ACL を使うのに必須です ({{ic|/usr/lib/udev/rules.d/70-uaccess.rules}} や [http://enotty.pipebreaker.pl/2012/05/23/linux-automatic-user-acl-management/] を参照)。}}
   
 
まず、X の中に有効なローカルセッションがあることを確認してください:
 
まず、X の中に有効なローカルセッションがあることを確認してください:
59行目: 163行目:
 
このコマンドの出力に {{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#ユーザーセッションの起動]] を見てさい。
+
D-Bus セッションも X と一緒に起動する必要があります。詳しくは [[D-Bus#ユーザーセッションの起動]]を見てください。
   
基本的な [[polkit (日本語)|polkit]] のアクションはそれ以上の設定を必要としませんが、ローカルセッションだけでなく他の認証を必要とする polkit アクションも存在します。認証するには polkit 認証エージェントを実行する必要があります。詳しくは [[polkit (日本語)#認証エージェント|polkit#認証エージェント]] を見て下さい。
+
基本的な [[polkit]] のアクションはそれ以上の設定を必要としませんが、ローカルセッションだけでなく他の認証を必要とする polkit アクションも存在します。認証するには polkit 認証エージェントを実行する必要があります。詳しくは [[polkit#認証エージェント]]を見て下さい。
   
  +
== 共有ライブラリのロード時にエラーが発生する ==
== シングルユーザーモード ==
 
   
  +
プログラムを使用しようとすると、以下のようなエラーが出力される場合:
If you cannot boot due to errors caused by a daemon, display manager or Xorg, you may be able use the single user [[Runlevels|runlevel]]:
 
  +
#Boot to single-user mode. For GRUB 2:
 
  +
error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory
##In the GRUB2 boot menu, select the Arch Linux entry, and press {{ic|e}} to edit it.
 
  +
##Find the kernel line; it will start with {{ic|linux /boot/vmlinuz-linux...}}
 
  +
[[pacman]] や [[pkgfile]] を使って存在しないライブラリが入っているパッケージはどれか検索してください:
##Appending {{ic|1}} or {{ic|s}} to this line
 
  +
##Press F2 to start the boot process
 
  +
{{hc|$ pacman -Fs libusb-0.1.so.4|
#Then disable the [[systemd]] service that is causing the problem.
 
  +
extra/libusb-compat 0.1.5-1
#Change to the multi-user mode systemd [[Systemd#Targets|target]].
 
  +
usr/lib/libusb-0.1.so.4
#Then try to track down the issue by running the service manually.
 
  +
}}
  +
  +
上記の場合、{{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'
90行目: 199行目:
 
@==> 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}} に加えられた変更に問題があります。以下の手順で解決できます:
=== 解決方法 ===
 
  +
#Arch Linux のライブ CD / インストールメディアを起動。
 
  +
#ルートパーティション ({{ic|'''/'''}}) を {{ic|/mnt}} にマウントして [[Change Root#arch-chroot を使う|arch-chroot]] を使ってシステムに [[chroot]]。
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.
 
  +
{{Note|[[Change Root#arch-chroot を使う|arch-chroot]] では {{ic|/boot}} パーティションのマウントはユーザーが行う必要があります。}}
#Boot into the Arch Linux Live CD / Installation Media.
 
  +
#{{ic|/etc/ld.so.conf}} を編集して問題のある行を削除する。
#Mount your root ({{ic|'''/'''}}) partition to {{ic|/mnt}} and using [[Change root#Change_root|arch-chroot]], [[Change root|chroot]] into your system.
 
  +
#{{ic|/etc/ld.so.conf.d/}} ディレクトリ内のファイルを確認して問題のあるファイルを削除する。
{{Note|[[Change root#Change_root|arch-chroot]] leaves mounting the {{ic|/boot}} partition up to the user.}}
 
  +
#[[initramfs]] を再生成:
#Examine {{ic|/etc/ld.so.conf}} and remove any invalid lines found.
 
#Examine the files located inside the directory {{ic|/etc/ld.so.conf.d/}} and remove all invalid files.
 
#Rebuild the [[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>
   
 
== 参照 ==
 
== 参照 ==
  +
  +
;一般
   
 
*[http://www.maximumpc.com/article/features/linux_troubleshooting_guide_fix_most_common_problems Fix the Most Common Problems]
 
*[http://www.maximumpc.com/article/features/linux_troubleshooting_guide_fix_most_common_problems Fix the Most Common Problems]
  +
*[https://www.reddit.com/r/archlinux/comments/tjjwr/archlinux_a_howto_in_troubleshooting_for_newcomers/ A how-to in troubleshooting for newcomers]
  +
  +
;起動の問題
  +
  +
* [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]] のページ
  +
* [https://fedoraproject.org/wiki/QA/Sysrq QA/Sysrq] - sysrq の使用方法
  +
* systemd のドキュメント: [https://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]

2019年11月21日 (木) 18:50時点における版

関連記事

この記事では一般的なトラブルシューティングの方法を説明しています。特定のアプリケーションの問題については、そのプログラムの 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+PageUpShift+PageDown のキーの組み合わせでバッファを上下にスクロールできます。

上限までスクロールしても情報が十分得られない場合、スクロールバックバッファを拡張して、保存できる出力の量を増やす必要があります。fbcon=scrollback:Nk カーネルパラメータでカーネルのフレームバッファコンソール (fbcon) を設定することで拡張できます。N を使用したいバッファサイズ (キロバイト) に置き換えてください。デフォルトのサイズは 32k です。

上記の設定が反映されない場合、フレームバッファコンソールが正しく有効になっていません。Framebuffer Console ドキュメント をみて他のパラメータを設定したり、あるいはフレームバッファドライバーを変更してください。

デバッグ出力

ほとんどのカーネルメッセージは起動時には表示されません。様々なカーネルパラメータを設定することでメッセージを表示させることができます:

  • debug はカーネルと systemd のデバッグメッセージを有効にします。
  • ignore_loglevel は強制的に全てのカーネルメッセージを表示します。

特定のケースでは、他のパラメータを使用する場合もあります:

  • earlyprintk=vga,keep はブートプロセスの初期段階でカーネルメッセージを表示します。出力が表示される前にカーネルがクラッシュしてしまう場合に使用してください。EFI 環境では vgaefi に変える必要があります。
  • log_buf_len=16M はカーネルのメッセージバッファを大きくすることで (16MB)、デバッグ出力が上書きされないようにします。

bootmem_debugsched_debug など、特定のサブシステムのデバッグを有効にするデバッグパラメータも複数存在します。詳しくは カーネルパラメータのドキュメント を見てください。

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

リカバリシェル

デーモンによるエラーや、fstab の記述が間違っている、またはディスプレイマネージャや Xorg に問題が発生していて、起動できない場合、シングルユーザーランレベルを使うことで問題を修正できることがあります。シングルユーザーモードでは起動後に root シェルだけを表示します。リカバリシェルを起動するカーネルパラメータは複数存在しますが、どれも exit で通常シェルに戻り、カーネルが元の状態に復帰します:

  • rescue は root ファイルシステムが読み書きできる状態で再マウントされたすぐ後にシェルを起動します。
  • emergency は更に早く、ファイルシステムがマウントされる前にシェルを起動します。
  • (何らかの理由で上記のパラメータが使えない場合) init=/bin/sh は init プログラムを root シェルに変えます。rescueemergency はどちらも 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 ポートなどのリソースを使ってプロセスを確認するためのコマンドラインユーティリティです。

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

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

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

まず、X の中に有効なローカルセッションがあることを確認してください:

$ loginctl show-session $XDG_SESSION_ID

このコマンドの出力に Remote=noActive=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

pacmanpkgfile を使って存在しないライブラリが入っているパッケージはどれか検索してください:

$ 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>

参照

一般
起動の問題