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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(校正（でき・出来）)
 
(9人の利用者による、間の27版が非表示)
3行目: 3行目:
 
[[en:General troubleshooting]]
  
[[en:General troubleshooting]]
 
[[es:General troubleshooting]]
  
[[es:General troubleshooting]]
  +
[[fr:General troubleshooting]]
  +
[[pt:General troubleshooting]]
  +
[[ru:General troubleshooting]]
  +
[[zh-hans:General troubleshooting]]
 
{{Related articles start}}
  
{{Related articles start}}
 
{{Related|バグ報告ガイドライン}}
  
{{Related|バグ報告ガイドライン}}
 
{{Related|ステップバイステップデバッグガイド}}
  
{{Related|ステップバイステップデバッグガイド}}
 
{{Related|デバッグ - トレースを取得}}
  
{{Related|デバッグ - トレースを取得}}
−
{{Related|ブートデバッグ}}
 +
{{Related|IRC 共同デバッグ}}
−
{{Related3|IRC Collaborative Debugging|IRC 共同デバッグ}}
  
 
{{Related articles end}}
  
{{Related articles end}}
   
 
この記事では一般的なトラブルシューティングの方法を説明しています。特定のアプリケーションの問題については、そのプログラムの 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.
  
   
  +
システムが機能しないときは以下の質問を考えてみてください。各質問の下には、なぜ質問に答えなければならないのか、詳しいデータを入手したりログやジャーナルを確認するにはどのツールを使えばいいのかを載せています。
−
# 何が問題ですか？
  
  +
−
#: Be ''as precise as possible''. This will help you not get confused and/or side-tracked when looking up specific information.
  
  +
# 何が問題ですか?
−
# エラーメッセージは存在しますか？
  
  +
#: できる限り正確に把握してください。特定の情報を確認するときに、混乱したり横道にそれるのを防ぐためです。
−
#: 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''}}
−
# 問題を再現できますか？
 +
# 問題を再現できますか?
  +
#: 正確に、かつ手順毎に、再現に必要な操作やコマンドを抽出してください。
−
#: 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}} 内のテキストが上書きされないようにしています。}}
   
−
== 問題の特定 ==
 +
=== 問題の特定 ===
   
 
問題を解決しようとするとき、以下のようなアプローチを取ってはいけません:
  
問題を解決しようとするとき、以下のようなアプローチを取ってはいけません:
43行目: 48行目:
 
''A または B の状態のときにアプリケーション X を使って作業 Y を行うと Z というエラーが発生する。''
  
''A または B の状態のときにアプリケーション X を使って作業 Y を行うと Z というエラーが発生する。''
   
−
== 他者のサポート ==
 +
=== 他者のサポート ===
   
  +
全ての情報はあなたの目の前にあります。あなたのシステムで何が起きてるのか一番良く知ってるのはあなたのはずです。適切な修正を試みて下さい。
−
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 で得ることができるでしょう。
   
  +
助けを求めるときは、あなたが大事だと考えた部分だけでなく、ログや出力などの情報を全て投稿してください。以下のような情報が対象です:
−
== セッションのパーミッション ==
  
   
  +
* コマンドの完全な出力。
−
{{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/] を参照)。}}
  
  +
* 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 を使うと良いでしょう。{{AUR|pbpst}} または {{pkg|gist}} パッケージを[[インストール]]することで情報を自動的にアップロードできます。例えば、systemd のジャーナルをアップロードするには:
−
まず、X の中に有効なローカルセッションがあることを確認してください:
  
   
  +
# journalctl -xb | pbpst -S
−
$ loginctl show-session $XDG_SESSION_ID
  
   
  +
リンクが出力されるのでフォーラムや IRC に貼り付けてください。
−
このコマンドの出力に {{ic|1=Remote=no}} と {{ic|1=Active=yes}} が含まれていなければなりません。含まれていない場合は、X がログインを行った tty と同一の tty で動作していることを確認してください。logind セッションを維持するために tty が同一である必要があります。このことはデフォルトの {{ic|/etc/X11/xinit/xserverrc}} によって管理されています。
  
   
  +
質問を投稿する前に、[http://www.ranvis.com/articles/smart-questions.ja.html 賢い質問のしかた] や[[行動規範]]も読んでください。
−
D-Bus セッションも X と一緒に起動する必要があります。詳しくは [[D-Bus#ユーザーセッションの起動]] を見て下さい。
  
   
  +
== 起動時の問題 ==
−
基本的な [[polkit]] のアクションはそれ以上の設定を必要としませんが、ローカルセッションだけでなく他の認証を必要とする polkit アクションも存在します。認証するには polkit 認証エージェントを実行する必要があります。詳しくは [[polkit#認証エージェント]] を見て下さい。
  
   
  +
[[ブートプロセス]]の問題を調べるときは[[カーネルパラメータ]]を変更して、システムを再起動します。
−
== シングルユーザーモード ==
  
   
  +
システムが起動できない場合、[https://www.archlinux.jp/download/ ライブイメージ] から起動して既存の環境に [[Change Root]] してください。
−
デーモンによるエラーや、fstab の記述が間違っている、またはディスプレイマネージャや Xorg に問題が発生していて、起動できない場合、シングルユーザー[[systemd#ターゲット|ランレベル]]を使うことで問題を修正できることがあります。シングルユーザーモードでは起動後に root シェルだけを表示します。Arch は systemd を使っているため、カーネルパラメータに {{ic|1=systemd.unit=rescue.target}} を追加することでシングルユーザーモードにできます。何らかの理由でこのパラメータが使えない場合 (例: rescue ターゲットが他の問題があるターゲットに依存している)、カーネルパラメータに {{ic|1=init=/bin/sh}} を追加することで root シェルを起動できます。
  
   
  +
=== コンソールメッセージ ===
−
== file: could not find any magic files! ==
  
   
  +
ブートプロセスが完了すると、画面の表示は一度消去されてログインプロンプトが表示されます。ユーザーは init の出力やエラーメッセージを読むことができません。以下のセクションに書かれている方法を使うことでエラーが読めるようになります。
−
''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!
  
−
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
  
−
==> 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'
  
   
  +
どのオプションを使用した場合でも、起動後に {{ic|dmesg}} を使用したり {{ic|journalctl -b}} を実行することで起動時からのカーネルメッセージを表示することは可能です。
−
=== 解決方法 ===
  
   
  +
==== フロー制御 ====
−
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.
  
  +
仮想コンソール (vc) を含む、ほとんど全てのターミナルエミュレータに適用される基本的な制御です:
−
#Mount your root ({{ic|'''/'''}}) partition to {{ic|/mnt}} and using [[Change Root#Change_root|arch-chroot]], [[Change Root|chroot]] into your system.
  
  +
* {{ic|Ctrl+S}} を押して出力を停止
−
{{Note|[[Change Root#Change_root|arch-chroot]] leaves mounting the {{ic|/boot}} partition up to the user.}}
  
  +
* {{ic|Ctrl+Q}} で復帰
−
#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.
  
  +
{{ic|write()}} のコールがブロックされるため、出力が停止されるだけでなく、ターミナルに出力しようとしているプログラムも停止されます。''init'' がフリーズしているように見える場合、システムコンソールが停止していないか確認してください。
−
#Rebuild the [[initramfs]].
  
  +
−
# mkinitcpio -p linux
  
  +
既に表示されているエラーメッセージを見る方法は [[Getty#tty1 にブートメッセージを残す]]を参照。
−
#Reboot back to your installed system.
  
  +
−
#Once booted, reinstall the package that was responsible for leaving your system inoperable using:
  
  +
==== スクロールバック ====
−
# pacman -S <package>
  
  +
  +
ビデオアダプタと表示端末の間に、スクロールバックバッファと呼ばれるバッファが作成されることで、テキストコンソールの画面から出てしまったテキストを遡って表示するスクロールバックが可能になっています。デフォルトでは、{{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|見たいところまでブート時の出力をスクロールバックできない場合、[[#スクロールバック|スクロールバックバッファ]]のサイズを大きくしてください。}}
  +
==== netconsole ====
  +
  +
[https://docs.kernel.org/networking/netconsole.html netconsole] は、カーネルモジュールで、すべてのカーネルログメッセージ(つまり、dmesg)をユーザースペース(例えば、syslogd)を介さずに別のコンピューターにネットワーク経由で送信します。"netconsole" という名前は誤称で、実際には "コンソール" ではなく、リモートログサービスのようなものです。
  +
  +
これは、組み込みまたはモジュールとして使用できます。組み込みの ''netconsole'' は、NICカードの直後に初期化し、指定したインターフェースをできるだけ早く起動します。このモジュールは主に、ヘッドレスマシンからのカーネルパニック出力をキャプチャするため、またはユーザースペースが機能しなくなった他の状況で使用されます。
  +
  +
=== リカバリシェル ===
  +
  +
デーモンによるエラーや、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 のビデオカードで画面が表示されない ===
  +
  +
おそらく [[カーネルモード設定]]の問題が原因です。[[カーネルモード設定#モード設定を無効にする|モード設定を無効にする]]か[[Intel Graphics#KMS Issue: コンソールの画面が狭い|ビデオポートを変更]]してみてください。
  +
  +
=== カーネルのロード中に止まってしまう ===
  +
  +
{{ic|1=acpi=off}} [[カーネルパラメータ]]を追加して ACPI を無効化してみてください。
  +
  +
=== カーネルモジュールのデバッグ ===
  +
  +
[[カーネルモジュール#情報を取得]]を見てください。
  +
  +
=== ハードウェアのデバッグ ===
  +
  +
[[udev#デバッグ出力]]を見てください。
  +
  +
== フリーズをデバッグする ==
  +
  +
残念なことに、通常、フリーズはデバッグが難しく、場合によっては再現に多くの時間を要します。フリーズにはデバッグが比較的容易なものがあります:
  +
  +
* 音は流れ続けていますか? もしそうであれば、ディスプレイがフリーズしているだけかもしれません。これは、ビデオドライバの問題である場合があります。
  +
* マシンはまだ応答していますか? 他の [[Tty|TTY]] に切り替えることができない場合は、[[SSH]] を試してください。
  +
* (もしあれば) ディスクのアクティビティ LED は、ディスクに大量に書き込んでいることを示していますか? 大量のスワップはシステムを一時的にフリーズさせる場合があります。大量に書き込みを行った際のフリーズに関する情報は[https://unix.stackexchange.com/a/340567 この StackExchange の回答]を参照してください。
  +
  +
どれもうまく行かない場合、'''クリーン'''シャットダウンを試してください。電源ボタンを'''一回'''おすとシステムのフリーズが治り、停止中のユニットが出力されるいつもの "シャットダウン画面" が表示されるかもしれません。あるいは、マジック [[SysRq]] キーでもクリーンシャットダウンを行うことができるかもしれません。[[Journal]] にはマシンのフリーズした理由のヒントが含まれている可能性があるので、クリーンシャットダウンが非常に重要なのです。クリーンでないシャットダウンでは、journal がディスクに書き込まれない場合があります。マシン全体が応答しなくなるハードフリーズは、ログを時間内にディスクに書き込めないので、デバッグがより難しくなります。
  +
  +
フリーズによってディスクに何も書き込めない場合は、リモートログインが役立つかもしれません。リモートログインの方法 (他のデバイスから行う必要があります) は、基本的なデバッグに利用できます:
  +
  +
$ ssh ''フリーズしているホスト'' journalctl -f
  +
  +
システム全体が応答しなくなり強制シャットダウンが必要になる深刻なフリーズの多くは、バグのあるファームウェアやドライバ、ハードウェアが関連しているかもしれません。別のカーネル ([[カーネル#リグレッション デバッグ]] を参照) や別の Linux ディストリビューションや OS を試したり、ファームウェアのアップデートやハードウェアの診断を行うと問題を見つけられるかもしれません。
  +
  +
{{Tip|デバイスのファームウェアをアップデートしてみることをお勧めします。そのようなアップデートは奇妙な問題を解決してくれることがあるからです。}}
  +
  +
フリーズのせいでデバッグに必要なあらゆる種類のログや情報を集められない場合、live 環境でフリーズを再現してみてください。フリーズを再現するためにグラフィカル環境が必要な場合や、archiso でフリーズを再現できる場合は、別のディストリビューションの live 環境を使ってください (フリーズがカーネルのバージョンやパッチに関係している可能性を排除するために、Arch ベースでない Linux を使うことが好ましいです)。live 環境でもフリーズが発生する場合、ハードウェア関連である''かも''しれません。フリーズが起こらなくなった場合、両システム間の違いを確認しておく必要があります。異なる構成 (設定)、バージョンやカーネルパラメータの違い、その他の似たような変更により、フリーズが修正されたのかもしれません。
  +
  +
ただし、caps lock の LED が点灯している場合は、[[カーネルパニック]]が起こっていることを示している可能性があります。環境によっては、カーネルパニックが発生したときに TTY が表示されない場合があります。これは混乱を招き、他の種類のフリーズと勘違いしてしまうかもしれません。
  +
  +
== リグレッションをデバッグする ==
  +
  +
{{Warning|これは [[インストールガイド#インストールメディアの準備|部分アップグレード]] を引き起こす傾向があり、この特定のケースでは必要悪となります。このシナリオによって正常な起動ができなくなる場合に備えて、慎重に作業を進め、[[インストールガイド#インストールメディアの準備|システムを回復する方法]] を用意してください}}
  +
  +
アップデートが問題を引き起こし、特定のパッケージを [[ダウングレード]] すると解決する場合、それはおそらく [https://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%81%AE%E5%BE%8C%E6%88%BB%E3%82%8A regression] でしょう。リグレッションのデバッグで最も重要なのは、問題がすでに修正されているかどうかを確認することです。これを行うには、まずアプリケーションが完全にアップデートされていることを確認します(例えば、アプリケーションが[[公式リポジトリ]]にあるのと同じバージョンであることを確認します)。もし既にアップデートされていたり、アップデートしても問題が解決しない場合は、実際の最新版を使ってみてください、通常は [[Arch User Repository#What is the difference between foo and foo-git packages?|-git]] バージョンで、既に [[AUR]] にパッケージされていることがあります。もしこれで問題が解決し、修正されたバージョンがまだ公式リポジトリにない場合は、新しいバージョンが公式リポジトリに届くまで待ち、それに戻してください。
  +
  +
それでも問題が解決しない場合、問題をデバッグするかアプリケーションを [https://wiki.archlinux.org/title/Bisecting_bugs_with_Git bisect] して、バグが修正されるようにアップストリームのバグトラッカーに報告してください。
  +
  +
{{Note|カーネルはリグレッションをデバッグするときに [[カーネル#リグレッションをデバッグする|違うアプローチ]] を必要とします。}}
  +
  +
== カーネルのアップグレード後に一部の周辺機器が使用できない ==
  +
  +
この現象は、一般的に以下のように現れます (しかし、これだけではないでしょう):
  +
  +
* 新たに挿入した USB デバイスが ''dmesg'' に現れるが、{{ic|/dev/}} には現れない。
  +
* カーネルアップデート前に使用したことのないファイルシステムをマウントできない。
  +
* ノート PC で、カーネルアップデート前に有線/無線接続を使用したことのない場合、有線/無線接続を使用できない。
  +
* ''modprobe'' を使って、カーネルパッケージのアップデート前に使用したことのないモジュールをロードしようとすると、{{ic|FATAL: Module ''module'' not found in directory /lib/module/''kernelversion''}}。
  +
  +
[[システムメンテナンス#アップグレード後に再起動]] で部分的に説明されている通り、カーネルのパッケージをアップデートしたとしても、再起動しない限り、カーネル自体はアップデートされません。一方、{{ic|/usr/lib/modules/''kernelversion''/}} 内のカーネルモジュールは、新しいカーネルがインストールされた際に pacman によって削除されます。{{Bug|16702}} で説明されている通り、この方法により、パッケージマネージャによって管理されないファイルをシステム上に残留させてしまうことを防ぐことができますが、先に挙げたような症状を引き起こしてしまいます。この問題を解決するには、カーネルのアップデート後に計画的に再起動してください。将来的には (まだ、実装されていませんが)、バージョン管理されたカーネルパッケージを使用することになるでしょう: 主な障害は、もはや必要とされなくなった以前のカーネルバージョンの削除をどう処理するかにあります。
  +
  +
もう一つの解決策は、{{Pkg|kernel-modules-hook}} を使うことです。2つの pacman フックが含まれており、rsync を使ってカーネルアップデート後にカーネルモジュールをファイルシステム上に保持し、[[有効化]]されてから4週間後に削除すべき古いモジュールをマークする {{ic|linux-modules-cleanup.service}} を使用します。
  +
  +
== パッケージ管理 ==
  +
  +
一般的な問題については [[Pacman#トラブルシューティング]]を、PGP 鍵に関する問題は [[pacman-key#トラブルシューティング]]を見てください。
  +
  +
=== 壊れたシステムを修復する ===
  +
  +
[[部分アップグレード]] が実行された場合は、システム全体をアップデートしてみてください。再起動が必要になる場合があります。
  +
  +
# pacman -Syu
  +
  +
GUI で起動していて、それが失敗する場合は、{{ic|Ctrl+Alt+F1}} から {{ic|Ctrl+Alt+F6}} を押して、動作中の tty にアクセスして ''pacman'' を実行できます。
  +
  +
システムが壊れて ''pacman'' を実行できない場合は、[[インストールガイド#インストールの準備|Arch ISO を USB フラッシュドライブ、光ディスク、または PXE を使用したネットワークから起動します。]] (インストールガイドの残りの部分には従わないでください。)
  +
  +
root ファイルシステムをマウントします:
  +
  +
[ISO] # mount /dev/''rootFileSystemDevice'' /mnt
  +
  +
個別に作成した他のパーティションをマウントし、すべてのパーティションにプレフィックス {{ic|/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 ==
100行目: 234行目:
 
''fuser'' はファイルやファイルシステム、TCP/UDP ポートなどのリソースを使ってプロセスを確認するためのコマンドラインユーティリティです。
  
''fuser'' はファイルやファイルシステム、TCP/UDP ポートなどのリソースを使ってプロセスを確認するためのコマンドラインユーティリティです。
 
 
−
''fuser'' は {{Pkg|psmisc}} パッケージに入っており、このパッケージは {{Grp|base}} グループの一部として既にインストールされているはずです。
 +
''fuser'' は {{Pkg|psmisc}} パッケージに入っており、このパッケージは {{Pkg|base}} [[メタパッケージ]]の依存関係として既にインストールされているはずです。
   
−
== NTFS パーティションに書き込みできない ==
 +
== セッションのパーミッション ==
−
標準では、NTFS ファイルシステムの読み込みしか出来ないようになっています。書き込みを行いたい場合は、{{Pkg|ntfs-3g}} パッケージをインストールしてください。
  
   
  +
{{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/] を参照)。}}
−
== Spellcheck を実行するとテキストが全部ミス判定されてしまう ==
  
−
{{Pkg|aspell}} 辞書はインストールされていますか? {{ic|pacman -Ss aspell}} を実行して、入手可能な辞書を確認してください。
  
   
  +
まず、X の中に有効なローカルセッションがあることを確認してください:
−
インストールされている辞書は {{ic|aspell dicts}} で確認できます:
  
−
{{hc|$ aspell dicts|
  
−
en
  
−
en_GB
  
−
...etc}}
  
   
  +
$ loginctl show-session $XDG_SESSION_ID
−
aspell および辞書がインストールされていても問題が解決しない場合、{{ic|enchant}} が原因かもしれません。{{ic|/usr/share/enchant/enchant.ordering}} を確認し、目的の言語が期待した設定になっているか確認してください。
  
  +
  +
このコマンドの出力に {{ic|1=Remote=no}} と {{ic|1=Active=yes}} が含まれていなければなりません。含まれていない場合は、X がログインを行った tty と同一の tty で動作していることを確認してください。logind セッションを維持するために tty が同一である必要があります。このことはデフォルトの {{ic|/etc/X11/xinit/xserverrc}} によって管理されています。
  +
  +
D-Bus セッションも X と一緒に起動する必要があります。詳しくは [[D-Bus#ユーザーセッションの起動]]を見てください。
  +
  +
基本的な [[polkit]] のアクションはそれ以上の設定を必要としませんが、ローカルセッションだけでなく他の認証を必要とする polkit アクションも存在します。認証するには polkit 認証エージェントを実行する必要があります。詳しくは [[polkit#認証エージェント]]を見て下さい。
  +
  +
== "error while loading shared libraries" というメッセージ ==
  +
  +
プログラムを使用しようとすると、以下のようなエラーが出力される場合:
  +
  +
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 のウェブサイトからメンテナに報告してください。
   
 
== 参照 ==
  
== 参照 ==
  +
  +
;一般
   
 
*[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]

2024年7月10日 (水) 21: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 を使うと良いでしょう。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 メタパッケージの依存関係として既にインストールされているはずです。

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

ノート: ローカルセッションを動作させるには 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" というメッセージ

プログラムを使用しようとすると、以下のようなエラーが出力される場合: 

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

参照

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