トラブルシューティング

This page is a translated version of the page Troubleshooting and the translation is 87% complete.

Other languages:

このページでは、トラブルを解消したり Gentoo のセットアップの際の支障を解決したりするための技術やツールに関する情報を提供しています。

この記事では、Gentoo ハンドブックを読み Gentoo を扱ううえでの基礎的な理解があることを前提にしています。

ヒント
トラブルシュートしても解決策が見つからない場合は、助けを求めるために support の記事を参照してください。

トラブルシューティングに役立つパッケージ

これは、トラブルシューティングに役立てることができる、非常に推奨されているツールのコレクションです。

ヒント
wgetpaste は、オンラインで問題のトラブルシューティングを議論するときに、スニペット、ファイル、コマンドの出力等を共有するための便利なツールです。

パッケージ管理

パッケージ	説明
gentoolkit	Gentoo とやり取りするためのツール群。利用価値の高いequery、eclean、euse 等を含みます。
eix	portage にパッケージを問い合わせるツール。
Portage File List	どのパッケージが与えられたファイルを含むかを問い合わせるツールである e-file を提供します。オンライン検索を使用するので、インストールされていないパッケージに対しても動作します。
genlop	emerge ログを解析するツール。特定のパッケージがいつインストールまたはアップデートされたかを知るために、そしてそれらがコンパイルにどれだけかかったかを確認するのに便利です。
elogv	emerge ログを閲覧するための ncurses ベースのインターフェース。

ハードウェア

パッケージ	説明
pciutils	PCI デバイスに関する情報を収集するツール。
usbutils	USB デバイスに関する情報を収集するツール。

監視

パッケージ	説明
htop	プロセスを監視するためのツールで、top と似ていますが、より先進的です。
iotop	プロセス毎の IO アクティビティを監視するための top 風ツール。
net-analyzer/nettop	プロトコル、ポート、プロセス毎のネットワークトラフィックを調査するための top 風ツール。

問題を特定する

問題を解決策に作り変えるためには、まず問題を正しく特定するべきです。問題の正確な理解は、より良い解決策をもたらすための助けになるでしょう。これは簡単なことのように見えるかもしれませんが、これ無しではトラブルシューティングは困難なものになるでしょう。

いくつかのことをメモしてください:

この問題はハードウェアに関するものですか、それともソフトウェアに関するものですか？
この問題の原因となるかもしれない何かをしたり、または最近変更したりしましたか？
この問題に関係する追加の情報を収集することはできますか？

情報、ログ、似た問題に直面した他の人の報告等を収集することは、問題についてのよい概観を得るために有益です。

ハードウェア関連

ドライバ

ハードウェアのドライバ問題は IRC でもっともよく報告される問題のひとつです。

最初に、そして第一に、問題を起こしているハードウェアがどれか識別することです。lspci と lsusb はこの目的にとても向いているツールです。以下は、不具合のあるデバイスとしてイーサネットカードを例に取ります:

適切なドライバの特定

まず、lspci を見てデバイスの情報を探しましょう:

root #lspci

 03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8071 PCI-E Gigabit Ethernet Controller (rev 16)

-n オプションを使うと、よりインターネットで検索しやすい簡易表記を得ることもできます:

root #lspci -n

 03:00.0 0200: 11ab:436b (rev 16)

モデル名 (0200) とベンダー/モデル (11ab:436b) は、WikiDevi や Debian HCL といった場所でデバイスを特定し、Linux で使用する適切なドライバを探すために利用できます。

ドライバが読み込まれているか確認する

ドライバを取得するところまでくれば、半ば解決したも同然です。ドライバ絡みのトラブルの解決の大部分は、それらが正しく読み込まれ、動作しているか確かめることです。

再び lspci に頼りましょう、以下を実行します:

root #lspci -k

 03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8071 PCI-E Gigabit Ethernet Controller (rev 16)
 	Subsystem: Acer Incorporated [ALI] Device 014e
 	Kernel driver in use: sky2

ここでは、使用中のドライバの識別子が表示されていることに注目してください。そうなっていない場合、このハードウェアに責任を持つドライバがありません。ドライバがビルトインではなくモジュールとしてビルドされているのであれば、modprobe <モジュール名> で適切なモジュールのロードを試してみてください。ドライバがビルトインであれば、モジュールにすることを検討してください。なぜなら、モジュールは modprobe でロード、modprobe -r でアンロードでき、問題をデバッグする間に再起動する回数を減らせるためです。

ドライバをトラブルシュートする

ドライバをモジュールとしてコンパイルし、モジュールがロードされたときの出力を取得してください。先に、そのドライバに依存するすべてのモジュールを取り除いておいてください (loading kernel modules を参照してください)。

次のコマンドは、モジュール (この例では r8169) を取り除いた後再びそのモジュールを追加して dmesg の出力を比較し、追加されたメッセージ (+ で始まる行) を効果的に表示します。

root #diff -u <(modprobe -r r8169; dmesg) <(sleep 1; modprobe r8169; dmesg) | grep ^+

最もよくある問題は、ファームウェアが存在しないことです。ファームウェアの欠如について管理者に通知するメッセージが現れる場合は、sys-kernel/linux-firmware または特化したファームウェアパッケージのいずれかを、Portage からインストールしてください。ファームウェアをインストールしたら、そのカーネルモジュールを再びアンロード・ロードして、問題が解決したか確認してください。

ソフトウェア関連

Portage 関連

依存関係グラフのスロットコンフリクト

パッケージを emerge しようとしたときに、次のようなメッセージを発する場合があります:

コード 依存関係グラフのエラー

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

これが一般的に意味するところは、列挙されたパッケージは、依存関係グラフ内で複数のバージョンをリクエストされているということです。そして幸運にも、常にではありませんがほとんどの場合、リクエストされたバージョンのうち最新のものに手動でアップグレードすることによって、これを解決することができます。では今は、次のメッセージを受け取ったと仮定します:

コード 依存関係グラフのエラーの例

app-emulation/emul-linux-x86-xlibs:0 
(app-emulation/emul-linux-x86-xlibs-20120127::gentoo, installed) pulled in by 
~app-emulation/emul-linux-x86-xlibs-20120127 required by (app-emulation/emul-linux-x86-medialibs-20120127::gentoo, installed) 
(and 2 more with the same problem) 
 
(app-emulation/emul-linux-x86-xlibs-20120520::gentoo, ebuild scheduled for merge) pulled in by 
>=app-emulation/emul-linux-x86-xlibs-20120520 required by (net-im/skype-2.2.0.35-r99::gentoo, ebuild scheduled for merge) 
~app-emulation/emul-linux-x86-xlibs-20120520 required by (app-emulation/emul-linux-x86-medialibs-20120520::gentoo, ebuild scheduled for merge)

欲しい最新のバージョンは 20120520 なので:

root #emerge --ask --oneshot =app-emulation/emul-linux-x86-xlibs-20120520

コンフリクトは互いに依存していることもあるので、ワンショット (--oneshot または -1) ですべてのコンフリクトを同時に解決すると良いことがよくあります。

次はまた別のブロックの例です:

コード ブロックコンフリクトの例

app-text/poppler:0
 
 (app-text/poppler-0.24.5::gentoo, installed) pulled in by
   app-text/poppler:0/44=[xpdf-headers(+)] required by (dev-tex/luatex-0.76.0::gentoo, installed)
   app-text/poppler:0/44=[cxx,jpeg,lcms,tiff,xpdf-headers(+)] required by (net-print/cups-filters-1.0.43::gentoo, installed)
 
 (app-text/poppler-0.24.3::gentoo, ebuild scheduled for merge) pulled in by
   >=app-text/poppler-0.12.3-r3:0/43= required by (app-text/texlive-core-2013-r1::gentoo, installed)
   poppler:0/43

poppler のバージョンを変更しても問題はないはずです。app-text/texlive-core は poppler の特定のバージョンを要求しませんが、どのバージョンが使用されても、それとともに再ビルドする必要があるということに注意してください:

root #emerge --ask --oneshot =app-text/poppler-0.24.5 app-text/texlive-core

次はブロックされることがある、さらに別の例です:

root #emerge --ask --verbose --update --newuse --deep @world

コード コンフリクトを更新する例

sys-power/cpupower:0
 
These are the packages that would be merged, in order:
 
Calculating dependencies... done!
 
Total: 0 packages, Size of downloads: 0 KiB
 
WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:
 
sys-power/cpupower:0
 
  (sys-power/cpupower-4.9.0-r1:0/0::gentoo, ebuild scheduled for merge) conflicts with
    <sys-power/cpupower-4.7 required by (mate-base/mate-applets-1.12.1-r4:0/0::gentoo, installed)
    ^                   ^^^
 
Nothing to merge; quitting.

Portage は実行できない更新について警告しますが、この更新はパッケージによって必要とされていないため、問題はありません。より正確には、mate-base/mate-applets-1.12.1-r4 は sys-power/cpupower パッケージの 4.7 より前のバージョンを必要とすることから、この更新はスキップしなくてはなりません。

System limitations prevent a proper build

System limitation insufficient RAM

When compiling with n jobs parallel the requirement of RAM grows approximately by a factor n. Unfortunately we can not predict the exact amount of RAM needed nor we can predict how much RAM will be consumed by other programs.

バイナリをデバッグする

強力なツールを使ってデバッグすることにより、コンパイルされたバイナリをトラブルシュートしてください。

追加の情報を収集する

助けを求めるときには、コマンドの出力などの追加の情報を求められることが多くあるでしょう。これらの中には、数十行から数百行のテキストを出力するものがあります - Gentoo IRC サポートチャネルなどのチャットルームに貼り付けるのには適さない量です。

Wgetpaste を使用すると、長い出力を含む web サイトへの短縮リンクを投稿することができます。

/etc/conf.d/net の内容を示すためには:

user $wgetpaste /etc/conf.d/net

lspci コマンドの詳細な出力が必要な場合は:

root #wgetpaste -c 'lspci -nnk'

エラーメッセージもペーストできるように、stderr を stdout にリダイレクトする必要があることがあります:

root #wgetpaste -c 'emerge -pv <package>'

ハードウェアまたはカーネルの問題の場合:

user $wgetpaste /usr/src/linux/.config

portage の問題の場合:

root #emerge --verbose --info | wgetpaste

パッケージインストール失敗の場合:

root #wgetpaste /var/tmp/portage/<category>/<package>-<version>/temp/build.log

Xorg の問題の場合:

user $wgetpaste /var/log/Xorg.0.log

システムにインストールされたすべてのパッケージ情報を提供する必要がある場合:

root #eix-update && eix-installed all

情報をまとめる

以下は、助けたいユーザや開発者に単一の URL だけで提供できるように、複数のコマンドを実行し、それらの出力を単一の wgetpaste コマンドによって処理させるために使用することができるシェル関数です:

root #

wgetpaste -i -c "lspci -nnk" -c "lsusb" -c "cat /usr/src/*$(uname -r)/.config" -c "cat /var/log/Xorg.0.log" -c "dmesg" -c "eix-update" -c "eix-installed all"

gentoo-user メーリングリスト上では pastebin サービスを使用しないでください

多くの pastebin サービスは古い内容を定期的に無効化する (pastebin サービスはほとんど収益化できず、いつダウンしてもおかしくないことは言うまでもありません) 一方で、メーリングリストのメッセージは複数の場所にアーカイブされ、何年にもわたって参照されます。問題の出力が短い場合や、削減できる場合は、e メールの本文内にコピペしてください - より長い出力はテキストファイルにリダイレクトして、プレーンテキストとして追加することができます。

Forming a solution

With a good description of the problem, a complete history of actions and all sorts of debugging data (problem details, hardware / software information, logs, backtraces and more) a good set of useful data is available to look for a solution.

In general, repeat the following steps to come to a solution:

Get an idea where the problem might be, think about possible causes.
If there are no obvious areas to look into, become more acquainted with the related areas or ask an expert more about it.
Sometimes it is necessary to make assumptions to proceed. When assumptions are made, put it to the test: false assumptions should not make users and developers blind of other causes.
Obtain additional debugging information in the area of a problem, or perform tests.

Often this will lead to multiple possible causes. It is important to test them (to verify it is the actual cause or not) and therefore test them individually; this is also known as "divide and conquer".

Let's say a problem like "my browser sometimes displays white pages when I boot" comes up and a lot of details are already known about it, then there may be number of possible causes:

Is this because the browser was improperly closed when the system rebooted?

Verify this by killing the process and pulling the plug several times, each time checking if the pages are white after booting again. If this is a cause, is it the actual cause or are there other causes?

Is this the result of a specific browser version being broken?

Try older or newer versions for a few days or reboots and see if they are broken as well.

And so on...

With the additional information, dare to think about more specific causes:

Does a certain pinned tab X that loads plugin Y break the system?

Unpin the tab so it doesn't open on launch anymore or disable the plugin, see if this keeps the problem away.

Graphical issues were reported as well, might this maybe mean this is caused by the video drivers?

Try a different version for those drivers, or alternative drivers if available.

As each possible cause is investigated, the actual cause of the problem might come closer and closer.

And in the end, if the cause is still not found, see the support article.