目次
報告者は問題のあるカーネルバージョンの環境下で reportbug か、それ以外の bug
スクリプトを実行するツールを使用することを期待されます。この情報のない報告に対する回答は、reportbug
を使用したフォローアップの要求でなくてはなりません。要求があってから 1
ヶ月以内にこれらの情報を私達が受け取らなかった場合、バグは閉じられる場合がります。
例外:
カーネルが起動しなかったりとても不安定な場合は通常のシステム情報ではなく netconsole、 serial console、 または写真でコンソールメッセージを提出してください。
もし報告がアップストリームの認識しているバグに関するものであればシステムに関する情報は必要ありませんが、参照先を明確にしてください。(bugzilla.kernel.org や git のコミット ID など。)
バグが明らかにハードウェア依存でなければ (例えばパッケージングのエラーなど)システムに関する情報は必要ありません。
特定のモデルに対するバグを報告する場合は、デバイスを列挙しなくてもよい場合があります。
多くの報告者がバグの深刻度合いを間違えてバグ報告をします。私たちは次のように基準を解釈し、必要に応じて深刻度を調整しています。
特定のハードウェア上で、またはあるフレーバがサポートしているはずのシステム上で、カーネルが起動不可能な状態になったり、あるいは不安定な状態になるようなバグです。「関係の無いソフトウェア」 は存在しません。なぜなら全てカーネルに依存しているからです。
カーネルが使用不能な状態であれば、この基準を満たしています。
クラッシュすることでメモリ内のデータが失われる場合を除きます。ストレージ内や、通信中のデータロス、またはデータ書き込み時のサイレント障害があてはまります。
一般的に利用可能であるべきハードウェアがサポートされていない場合などがあてはまります。
私達はユーザタグを使用しません。バグのトリアージを支援するために、私達は BTS
で定義された標準のタグと、forwarded
フィールドを使用するべきです。とりわけ:
提出者からの返答を待っている場合 moreinfo
タグを追加し、そうでない時は削除する
ハードウェア依存のバグには unreproducible
タグを追加しない
一般的には、よく似たハードウェアを所有していない限りバグの再現はあまり期待できません。次のことを考慮すべきです:
bugzilla.kernel.org などの関係しそうな他のバグトラッカーを探す (クローズされているバグも含めて)
カーネルのメーリングリストを検索する
多くのアーカイブの中で、news.gmane.org が最もましなようです
メーリングリストに投稿されたパッチは patchwork.kernel.org にアーカイブされています
関連するソースファイルの git コミットログを参照する
リグレッションが発生した場合は、問題の無いバージョンから問題が発生したバージョンまでを調べましょう
それ以外の場合は、バグが修正されている場合があるため、問題が発生したバージョンから最新のバージョンを調べましょう
kerneloops.org の類似した 「oops」 を調べる
'oops' に対してソースのマシーンコードとレジスタ値を比較し、どのように逸脱状態が発生したのかを調べる (この方法がうまくいくことは稀ですが、うまくいった時は天才になった気分を味わえます ;-)
報告者の技術的な洗練度と、疑いのあるシステムに要求されるサービスの度合い (例えばそれが製品のサーバである等) によって、私たちは次のいずれかのリクエストをすることができます。
受け身でさらに多くの情報を集める (例えば、さらにログを取ったり procfs や sysfs の中身の報告を求めるなど)
最新の stable/stable-proposed-updates/stable-security に同様の不具合に対する修正があった場合、最新のバージョンへのアップグレードを要求する
カーネルのコマンドラインやモジュールパラメータにデバッグやフォールバックオプションの追加を要求する
unstable か backports バージョンの一時的な利用を要求する
特定のパッチを適用したカーネルのリビルドを要求する (debian/bin/test-patches スクリプトで簡単にできます)
git bisect でバグの原因となった特定のアップストリームの変更を探すよう要求する
特定の製品やコンポーネントで、アップストリームにとっての現行または以前の stable リリースでバグが発生し、わたしたちには修正できない場合は、報告者にbugzilla.kernel.orgでアップストリームにバグを報告し、わたしたちにアップストリームのバグ番号を報告するようお願いします。わたしたちがバグを直接報告することはありません。アップストリームからのフォローアップの質問はわたしたちではなく、報告者に行くべきだからです。アップストリームのバグ番号の報告をもって、わたしたちはバグを forwarded としてマークします。bts-link とそのステータスの更新
多くのバグ報告者が特徴的なエラーメッセージを探し出し、これを特定のバグであるかのように扱います。これは多くの 'me too' follow-ups の原因になっています。例えば、ドライバのバグを示すメッセージがある場合、2番目の報告者が別のドライバを使用しているようなケースです。
報告が複数の異なるバグに関する情報で溢れないように、
そのような返信に素早く対応し、別のバグ報告を送るようにお願いしなければなりません
バグの説明を向上させるために、BTS summary
コマンドを使用することができます
最後の手段として、報告者毎に関連する情報とともに新たなバグ報告を作成し、オリジナルのバグ報告をクローズする必要があるかもしれません
オリジナルのバグ報告に 1 つよりも多くのバグについて説明されている場合は('...and other thing...' )、クローンしてそれぞれ個別に対応すべきです。
報告者に対しては常に丁寧に対応すべきです。これは、社会契約で示唆されているだけではなく、バグを迅速に解決することにも繋がる場合があります。報告者が深刻度を過剰にしてしまった場合は、静かにダウングレードしましょう。報告者が何か愚かなことをしてしまった場合は、それを取り消して報告し直すよう要求しましょう。'Sorry' と 'please' を付けるだけで、印象が大きく変わります。
報告者への一般的なアドバイスは https://wiki.debian.org/DebianKernelReportingBugs でメンテされています。
Debian kernel チームはカーネルパッケージのバグを Debian Bug Tracking System (BTS) で管理しています。このシステムの利用方法については、 http://bugs.debian.org を参照してください。バグは、reportbugというパッケージと同名のコマンドを使用して送信することができます。Debian から派生したディストリビューション (Knoppix、Mepis、Progeny、Ubuntu、Xandros など) に関するバグは Debian BTS に報告しないで下さい。(公式の Debian カーネルパッケージを利用して、Debian システム上で再現可能である場合を除きます。)派生ディストリビューションにはカーネルのパッケージングに関して独自のポリシーと手順があります。そこで発見されたバグは、彼らのバグ追跡システムやメーリングリストに直接報告されるべきです。
この章の内容は、あなたが Debian カーネルパッケージに対してバグ報告を行うことを避けることを意図したものではありません。しかし、Debian カーネルチームのリソースが限られていることは覚えておいてください。 バグに効率的に反応できるかどうかは、バグレポートの情報の品質に左右されています。カーネルパッケージに対してバグ報告する場合は次のガイドラインを参考にして、私たちがより良い作業ができるよう手助けしてください。
調査する バグ報告を行う前に特定のエラーメッセージや症状に関して web 上で検索を行いましょうあなただけがある問題に遭遇しているというのは極めて稀なケースです。常に、すでにどこかで議論されており、解決策や回避策やパッチが既に提示されている可能性が高いと考えるべきです。もし、そのような情報が存在する場合は、常にバグレポート内に参照先を示すようにしましょう。すでに同様の報告がされているかどうかについては、current bug list を確認してください。
情報を収集する バグレポートには充分な情報を提供してください。レポートには最低限でも、バグに遭遇したDebian 公式カーネルパッケージのバージョンと、再現方法を記載してください。あなたが報告するバグの性質によっては、dmesg の出力(または、その一部) と lspci -vn の出力も報告してください。reportbug は、これを自動で行います。あてはまる場合には、知りうる限りバグが発生しない最新のカーネルバージョンと、動作しているカーネルに対する上記のコマンド出力も報告してください。common sense を使って、あなたが問題の解決の手助けになると思う情報を付加してください。
"vanilla" カーネルで再現させる 機会があれば、"vanilla" カーネルからビルドした バイナリカーネルイメージで再現できるか試してみてください。vanilla カーネルのソースは https://www.kernel.org か、そのミラーから入手することができます。Debian の stock カーネルと同じ設定を使用してください。このやり方についての詳しい情報は、「Debian カーネルソースからカスタムカーネルをビルドする」 を参照して下さい。もしバグがカーネルに対して行なわれた Debian 特有の変更が原因であるという説得力のある証拠があれば、バグはカーネルチームによってより高い優先度をつけられます。もしバグが Debian 特有のものでない場合は、すでにアップストリームで報告済みでないか kernel bug databaseを確認してください。 アップストリームの問題であることが明確な場合は、そちらにもバグ報告をすることができます。(いずれにせよ、その問題を追跡できるように Debian BTS には報告してください。)
正しいパッケージに対してバグ報告をする: バグ報告は、問題が発生したカーネルのバージョン番号を持つパッケージ
(例えば linux-image-3.2.0-2-686-pae
)
に対して行いメタパッケージ (例えば linux-image-686-pae
) には報告しないでください。
tainted カーネルに関連するバグ カーネルがクラッシュした場合、通常はデバッグ情報を出力します。これには、動作中だったカーネルが taint (汚染) されたかも含まれています。クラッシュ時にサードパーティ製のバイナリモジュールがロードされていたカーネルは tainted (汚染された) と表現されます。カーネル開発者がソースコードを見ることができないので、そのようなモジュールが絡んだ問題はデバッグが非常に困難になります。そのような事情から、(例えばバイナリモジュールをロードしないようにするなどして) untainted (汚染されていない) カーネルで再現できるか試してみることを強くおすすめします。問題がそのようなモジュールの内部に起因するものであれば、カーネルコミュニティができることはあまりありませんので、直接モジュールの作成者に報告すると良いでしょう。
ローカル環境でバグが簡単に再現できても、開発者が再現できない場合 (このような場合の多くはワークフローかハードウェアに依存したバグです)、いくつかのバージョンでコンパイルとテストを行い、どの変更がリグレションの原因になったのかを絞り込むと役に立ちます。
まずは vanilla カーネルで問題を再現させましょう:
#
apt-get install git build-essential
$
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$
cd linux
上記のコマンドで vanilla カーネルを取得します。「Debian カーネルソースからカスタムカーネルをビルドする」で説明されている、バイナリパッケージの設定、ビルド、テストを行います:
$
make localmodconfig
#最低限の設定$
scripts/config --disable DEBUG_INFO
#ビルドサイズを適度なサイズにおさえる$
make deb-pkg
#
dpkg -i ../linux-image-3.5.0_3.5.0-1_i386.deb
#パッケージ名は適当なもに置き換える#
reboot
もしバグが再現できない場合は、/boot 内の公式な設定ファイルで試してみましょう。(それでも再現できない場合は勝利宣言をし祝杯を挙げましょう。)
bisection (二分探索) を開始するにはまず、どのバージョンが動作してどのバージョンが動作しなかったかを宣言します:
$
cd linux
$
git bisect start
$
git bisect good v3.0
#問題ないことがわかっているバージョン (good)$
git bisect bad
#現在のバージョンは問題がある (bad)
git が中間バージョンをテストするためにチェックアウトします。準備しておいた設定を再利用し、ビルドしましょう。
$
make silentoldconfig
$
make deb-pkg
パッケージをインストールし、再起動させ、テストします。
$
git bisect good
#このバージョンではバグが無い$
git bisect bad
#バグが存在する$
git bisect skip
#他のバグがあるためテストが難しい
そして次のイテレーションに移ります:
$
make silentoldconfig
$
make deb-pkg
プロセスの最後に、"first bad commit" の名前が出力されます。これはバグを追うのに役立ちます。特定には至らなくても、何度かプロセスを繰り返しリグレッションの範囲を絞り込むことは有用です。その場合、git bisect log コマンドを実行し、ログを出力します。 もし可視化したければ、git bisect visualize を gitk パッケージをインストールした状態で使用することで、ステップ間で何が起きたかを見ることができます。
Christian Couder の文章、「git bisect でリグレッションと戦う」 に詳細な説明があります。kernel.org から入手することができます。または、git-doc package を参照してください。