[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 次のページ ]
報告者は問題のあるカーネルバージョンの環境下で reportbug
か、それ以外の bug
スクリプトを実行するツールを使用することを求められます。この情報のない報告に対する回答として
reportbug
を使用するよう、フォローアップリクエストが行われます。リクエストがあってから 1
ヶ月以内に必要な情報を私たちが受け取らなかった場合、バグは閉じられる場合があります。
例外:
If the kernel does not boot or is very unstable, instead of the usual system
information we need the console messages via netconsole
,
serial
console
, or a photograph.
If the report is relaying information about a bug acknowledged upstream, we do
not need system information but we do need specific references (bugzilla.kernel.org
or
git
commit id).
バグが明らかにハードウェア依存でなければ (例えばパッケージングのエラーなど)システムに関する情報は必要ありません。
特定のモデルに対するバグを報告する場合は、デバイスを列挙しなくてもよい場合があります。
多くの報告者が深刻度合いを間違えてバグ報告をします。私たちは次のように基準を解釈し、必要に応じて深刻度を調整しています。
特定のハードウェア上で、またはあるフレーバがサポートしているはずのシステム上で、カーネルが起動不可能な状態になったり、あるいは不安定な状態になるようなバグです。「関係の無いソフトウェア」 は存在しません。なぜなら全てカーネルに依存しているからです。
カーネルが使用不能な状態であれば、この基準を満たしています。
クラッシュすることでメモリ内のデータが失われる場合を除きます。ストレージ内のデータ破損や、通信中のデータ損失、またはデータ書き込み時のサイレント障害のみがあてはまります。
一般的に利用可能であるべきハードウェアがサポートされていない場合などがあてはまります。
私たちはユーザタグを使用しません。バグのトリアージ (選別、優先割り当て) を支援するために、私たちは BTS で定義された標準のタグと、forwarded フィールドを使用するべきです。具体的には:
提出者からの返答を待っている場合 moreinfo タグを追加し、そうでない時は削除する
ハードウェア依存のバグには unreproducible タグを追加しない
ほとんどの場合、よく似たハードウェアを所有していない限りバグの再現はあまり期待できません。以下の点を考慮してください:
Searching bugzilla.kernel.org
(including
closed bugs) or other relevant bug tracker
カーネルのメーリングリストを検索する
Of the many archives, news.gmane.org
seems to suck least
メーリングリストに投稿されたパッチは patchwork.kernel.org
にアーカイブされています
関連するソースファイルの git コミットログを参照する
リグレッションが発生した場合は、問題の無いバージョンから問題が発生したバージョンまでを調べましょう
それ以外の場合は、バグが修正されている場合があるため、問題が発生したバージョンから最新のバージョンを調べましょう
kerneloops.org の類似した 「oops」 を調べる
'oops' に対してソースのマシーンコードとレジスタ値を比較し、どのように逸脱状態が発生したのかを調べる (この方法がうまくいくことは稀ですが、うまくいった時は天才になった気分を味わえます ;-)
報告者の技術的な洗練度と、疑いのあるシステムに要求されるサービスの度合い (例えばそれが製品のサーバである等) によって、私たちは次のいずれかのリクエストをすることができます。
受け身でさらに多くの情報を集める (例えば、さらにログを取ったり procfs や sysfs の中身の報告を求めるなど)
最新の stable/stable-proposed-updates/stable-security に同様の不具合に対する修正があった場合、最新のバージョンへのアップグレードを要求する
カーネルのコマンドラインやモジュールパラメータにデバッグやフォールバックオプションの追加を要求する
unstable か backports バージョンの一時的な利用を要求する
特定のパッチを適用したカーネルのリビルドを要求する
(debian/bin/test-patches
スクリプトで簡単にできます)
git bisect
でバグの原因となった特定のアップストリームの変更を探すよう要求する
When a bug occurs in what upstream considers the current or previous stable
release, and we cannot fix it, we ask the submitter to report it upstream at
bugzilla.kernel.org
under
a specific Product and Component, and to tell us the upstream bug number. We
do not report bugs directly because follow-up questions from upstream need to
go to the submitter, not to us. Given the upstream bug number, we mark the bug
as forwarded. bts-link
then updates its status.
多くのバグ報告者が特徴的なエラーメッセージを探し出し、これを特定のバグであるかのように扱います。これは多くの 「ぶら下がり報告」 の原因になっています。例えば、ドライバのバグを示すメッセージに対して、他のドライバを使用している報告者がこれにぶら下がり報告をするケースなどです。
報告が複数の異なるバグに関する情報で溢れないように、
そのような返信に素早く対応し、別のバグ報告を送るようにお願いしなければなりません
バグの説明を向上させるために、BTS summary コマンドを使用することができます
最後の手段として、報告者毎に関連する情報とともに新たなバグ報告を作成し、オリジナルのバグ報告をクローズする必要があるかもしれません
オリジナルのバグ報告が 複数のバグについて説明している場合は('...and other thing...')、報告をクローンしてそれぞれ個別に対応すべきです。
パッチは通常であれば、適用される前に (古いバージョンのカーネルに対して必要な調整については別にして) 関係している上流のメンテナによってレビューされ、受け入れられます。
We should always be polite to submitters. Not only is this implied by the
Social
Contract
, but it is likely to lead to a faster resolution of the
bug. If a submitter overrated the severity, quietly downgrade it. If a
submitter has done something stupid, request that they undo that and report
back. 'Sorry' and 'please' make a big difference in tone.
We will maintain general advice to submitters at http://wiki.debian.org/DebianKernelReportingBugs
.
Debian kernel team keeps track of the kernel package bugs in the Debian Bug
Tracking System (BTS). For information on how to use the system see http://bugs.debian.org
. You can also
submit the bugs by using the reportbug command from the package
with the same name. Please note that kernel bugs found in distributions
derived from Debian (such as Knoppix, Mepis, Progeny, Ubuntu, Xandros, etc.)
should not be reported to the Debian BTS (unless they can be also
reproduced on a Debian system using official Debian kernel packages). Derived
distributions have their own policies and procedures regarding kernel
packaging, so the bugs found in them should be reported directly to their bug
tracking systems or mailing lists.
この章の内容は、あなたが Debian カーネルパッケージに対してバグ報告を行うことをためらわせることを意図したものではありません。しかし Debian カーネルチームのリソースが限られていることは覚えておいてください。バグに効率的に反応できるかどうかは、バグ報告の情報の品質に左右されています。カーネルパッケージに対してバグ報告する場合は次のガイドラインを参考にして、私たちがより良い作業ができるよう手助けしてください。
Do the research. Before filing the bug search the web for the
particular error message or symptom you are getting. As it is highly unlikely
that you are the only person experiencing a particular problem, there is always
a chance that it has been discussed elsewhere, and a possible solution, patch,
or workaround has been proposed. If such information exists, always include
the references to it in your report. Check the current
bug list
to see whether something similar has been reported already.
情報を収集する:
バグレポートには充分な情報を提供してください。レポートには最低限でも、バグに遭遇した
Debian
公式カーネルパッケージの正確なバージョンと、再現方法を記載してください。あなたが報告するバグの性質によっては、dmesg
の出力 (または、その一部) と lspci -vn
の出力も報告してください。reportbug
は、これを自動で行います。あてはまる場合には、知りうる限りバグが発生しない最新のカーネルバージョンと動作しているカーネルに対する上記のコマンド出力も報告してください。常識的に考えて問題の解決の手助けになると思う情報があればそれを付加してください。
Try to reproduce the problem with "vanilla" kernel. If you
have a chance, try to reproduce the problem by building the binary kernel image
from the "vanilla" kernel source, available from http://www.kernel.org
or its mirrors,
using the same configuration as the Debian stock kernels. For more information
on how to do this, look at Debian
カーネルソースからカスタムカーネルをビルドする, 第 4.5 節. If there is
convincing evidence that the buggy behavior is caused by the Debian-specific
changes to the kernel, the bug will usually be assigned higher priority by the
kernel team. If the bug is not specific for Debian, check out the upstream
kernel bug database
to
see if it has been reported there. If you are sure that it is an upstream
problem, you can also report your bug there (but submit it to Debian BTS
anyway, so that we can track it properly).
正しいパッケージに対してバグ報告をする:
バグ報告は、問題が発生したカーネルのバージョン番号を持つパッケージ (例えば
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
上記のコマンドで vanilla カーネルを取得します。Debian カーネルソースからカスタムカーネルをビルドする, 第 4.5 節で説明したバイナリパッケージの設定、ビルド、テストを行います:
$ 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 パッケージをインストールした状態で使用することで、ステップ間で何が起きたかを見ることができます。
See Christian Couder's article "Fighting regressions with git bisect"
from kernel.org
or the
git-doc package
for details.
[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 次のページ ]
Debian Linux カーネルハンドブック
version 1.0.16, Fri 14 Aug 12:53:11 CEST 2015