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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(Pkg/AUR テンプレートの更新)
(校正（でき・出来）)
 
(3人の利用者による、間の16版が非表示)
3行目: 3行目:
 
[[en:General troubleshooting]]
  
[[en:General troubleshooting]]
 
[[es:General troubleshooting]]
  
[[es:General troubleshooting]]
  +
[[fr:General troubleshooting]]
  +
[[pt:General troubleshooting]]
 
[[ru:General troubleshooting]]
  
[[ru:General troubleshooting]]
 
[[zh-hans:General troubleshooting]]
  
[[zh-hans:General troubleshooting]]
18行目: 20行目:
 
=== 注意事項 ===
  
=== 注意事項 ===
   
−
抱えている問題を解決するには、問題のシステムがどう機能しているのかを根本的に理解することが不可欠です。どうやって動いているのか、またエラーを起こさずに動作させるには何が必要なのか？質問に答えるのが用意ではないという場合、問題が発生している機能に関する [[メインページ|Archwiki]] の記事を見ることを強く推奨します。問題のシステムを理解すれば、問題を突き止めるのが楽になるでしょう。
 +
抱えている問題を解決するには、問題のシステムがどう機能しているのかを根本的に理解することが不可欠です。どうやって動いているのか、またエラーを起こさずに動作させるには何が必要なのか?質問に答えるのが用意ではないという場合、問題が発生している機能に関する [[メインページ|Archwiki]] の記事を見ることを強く推奨します。問題のシステムを理解すれば、問題を突き止めるのが楽になるでしょう。
   
 
=== チェックリスト ===
  
=== チェックリスト ===
24行目: 26行目:
 
システムが機能しないときは以下の質問を考えてみてください。各質問の下には、なぜ質問に答えなければならないのか、詳しいデータを入手したりログやジャーナルを確認するにはどのツールを使えばいいのかを載せています。
  
システムが機能しないときは以下の質問を考えてみてください。各質問の下には、なぜ質問に答えなければならないのか、詳しいデータを入手したりログやジャーナルを確認するにはどのツールを使えばいいのかを載せています。
   
−
# 何が問題ですか？
 +
# 何が問題ですか?
−
#: 出来る限り正確に把握してください。特定の情報を確認するときに、混乱したり横道にそれるのを防ぐためです。
 +
#: できる限り正確に把握してください。特定の情報を確認するときに、混乱したり横道にそれるのを防ぐためです。
−
# エラーメッセージは存在しますか？
 +
# エラーメッセージは存在しますか?
 
#: 問題に関連するエラーメッセージを含んでいる出力を全て、{{ic|$HOME/issue.log}} などのファイルにコピーアンドペーストしてください。例えば、[[mkinitcpio]] コマンドの出力を {{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''}}
−
# 問題を再現できますか？
 +
# 問題を再現できますか?
 
#: 正確に、かつ手順毎に、再現に必要な操作やコマンドを抽出してください。
  
#: 正確に、かつ手順毎に、再現に必要な操作やコマンドを抽出してください。
−
# 問題が発生し始めたのはいつからで、問題がなかったときから何を変えましたか？
 +
# 問題が発生し始めたのはいつからで、問題がなかったときから何を変えましたか?
 
#:アップデートによって問題が発生したのであれば、アップデートしたパッケージを全て挙げてください。バージョン番号や、[[pacman]].log に出力されたテキスト ({{ic|/var/log/pacman.log}}) も重要です。また、[[systemd]] の systemctl ツールを使って問題のアプリケーションを使うのに必要なサービスの状態を確認してください。例えば、以下の [[Systemd#systemctl の基本的な使い方|systemd]] コマンドは {{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}}
87行目: 89行目:
 
==== フロー制御 ====
  
==== フロー制御 ====
   
−
仮想端末 (vc) を含む、ほとんど全てのターミナルエミュレータに適用される基本的な制御です:
 +
仮想コンソール (vc) を含む、ほとんど全てのターミナルエミュレータに適用される基本的な制御です:
 
* {{ic|Ctrl+S}} を押して出力を停止
  
* {{ic|Ctrl+S}} を押して出力を停止
 
* {{ic|Ctrl+Q}} で復帰
  
* {{ic|Ctrl+Q}} で復帰
117行目: 119行目:
   
 
{{Note|見たいところまでブート時の出力をスクロールバックできない場合、[[#スクロールバック|スクロールバックバッファ]]のサイズを大きくしてください。}}
  
{{Note|見たいところまでブート時の出力をスクロールバックできない場合、[[#スクロールバック|スクロールバックバッファ]]のサイズを大きくしてください。}}
  +
==== netconsole ====
  +
  +
[https://docs.kernel.org/networking/netconsole.html netconsole] は、カーネルモジュールで、すべてのカーネルログメッセージ(つまり、dmesg)をユーザースペース(例えば、syslogd)を介さずに別のコンピューターにネットワーク経由で送信します。"netconsole" という名前は誤称で、実際には "コンソール" ではなく、リモートログサービスのようなものです。
  +
  +
これは、組み込みまたはモジュールとして使用できます。組み込みの ''netconsole'' は、NICカードの直後に初期化し、指定したインターフェースをできるだけ早く起動します。このモジュールは主に、ヘッドレスマシンからのカーネルパニック出力をキャプチャするため、またはユーザースペースが機能しなくなった他の状況で使用されます。
   
 
=== リカバリシェル ===
  
=== リカバリシェル ===
129行目: 136行目:
 
=== Intel のビデオカードで画面が表示されない ===
  
=== Intel のビデオカードで画面が表示されない ===
   
−
おそらく [[Kernel Mode Setting]] の問題が原因です。[[Kernel Mode Setting#モードセッティングを無効にする|モードセッティングを無効にする]]か[[Intel Graphics#KMS Issue: コンソールの画面が狭い|ビデオポートを変更]]してみてください。
 +
おそらく [[カーネルモード設定]]の問題が原因です。[[カーネルモード設定#モード設定を無効にする|モード設定を無効にする]]か[[Intel Graphics#KMS Issue: コンソールの画面が狭い|ビデオポートを変更]]してみてください。
   
 
=== カーネルのロード中に止まってしまう ===
  
=== カーネルのロード中に止まってしまう ===
142行目: 149行目:
   
 
[[udev#デバッグ出力]]を見てください。
  
[[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#トラブルシューティング]]を、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 ==
151行目: 234行目:
 
''fuser'' はファイルやファイルシステム、TCP/UDP ポートなどのリソースを使ってプロセスを確認するためのコマンドラインユーティリティです。
  
''fuser'' はファイルやファイルシステム、TCP/UDP ポートなどのリソースを使ってプロセスを確認するためのコマンドラインユーティリティです。
 
 
−
''fuser'' は {{Pkg|psmisc}} パッケージに入っており、このパッケージは {{Pkg|base}} グループの一部として既にインストールされているはずです。
 +
''fuser'' は {{Pkg|psmisc}} パッケージに入っており、このパッケージは {{Pkg|base}} [[メタパッケージ]]の依存関係として既にインストールされているはずです。
   
 
== セッションのパーミッション ==
  
== セッションのパーミッション ==
167行目: 250行目:
 
基本的な [[polkit]] のアクションはそれ以上の設定を必要としませんが、ローカルセッションだけでなく他の認証を必要とする polkit アクションも存在します。認証するには polkit 認証エージェントを実行する必要があります。詳しくは [[polkit#認証エージェント]]を見て下さい。
  
基本的な [[polkit]] のアクションはそれ以上の設定を必要としませんが、ローカルセッションだけでなく他の認証を必要とする polkit アクションも存在します。認証するには polkit 認証エージェントを実行する必要があります。詳しくは [[polkit#認証エージェント]]を見て下さい。
   
  +
== "error while loading shared libraries" というメッセージ ==
−
== 共有ライブラリのロード時にエラーが発生する ==
  
   
 
プログラムを使用しようとすると、以下のようなエラーが出力される場合:
  
プログラムを使用しようとすると、以下のようなエラーが出力される場合:
183行目: 266行目:
   
 
インストールしたプログラムのパッケージの [[PKGBUILD]] に依存パッケージとしてライブラリが記載されていないという可能性もあります。公式パッケージの場合、[[バグ報告ガイドライン|バグとして報告]]してください。[[AUR]] のパッケージの場合、AUR のウェブサイトからメンテナに報告してください。
  
インストールしたプログラムのパッケージの [[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'
  
−  
−
大抵の場合、前にインストールしたアプリケーションによって {{ic|/etc/ld.so.conf.d/}} に作成された設定ファイルや {{ic|/etc/ld.so.conf}} に加えられた変更に問題があります。以下の手順で解決できます:
  
−
#Arch Linux のライブ CD / インストールメディアを起動。
  
−
#ルートパーティション ({{ic|'''/'''}}) を {{ic|/mnt}} にマウントして [[Change Root#arch-chroot を使う|arch-chroot]] を使ってシステムに [[chroot]]。
  
−
{{Note|[[Change Root#arch-chroot を使う|arch-chroot]] では {{ic|/boot}} パーティションのマウントはユーザーが行う必要があります。}}
  
−
#{{ic|/etc/ld.so.conf}} を編集して問題のある行を削除する。
  
−
#{{ic|/etc/ld.so.conf.d/}} ディレクトリ内のファイルを確認して問題のあるファイルを削除する。
  
−
#[[initramfs]] を再生成:
  
−
# mkinitcpio -p linux
  
−
#再起動する。
  
−
#起動したら、問題のあるパッケージを再インストール:
  
−
# pacman -S <package>
  
   
 
== 参照 ==
  
== 参照 ==

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」から取得