[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 次のページ ]


Debian Linux カーネルハンドブック
第 9 章 - バグの報告と対処


9.1 カーネルチームのバグ対処ポリシー


9.1.1 要求される情報

報告者は問題のあるカーネルバージョンの環境下で reportbug か、それ以外の bug スクリプトを実行するツールを使用することを求められます。この情報のない報告に対する回答として reportbug を使用するよう、フォローアップリクエストが行われます。リクエストがあってから 1 ヶ月以内に必要な情報を私たちが受け取らなかった場合、バグは閉じられる場合があります。

例外:


9.1.2 深刻度

多くの報告者が深刻度合いを間違えてバグ報告をします。私たちは次のように基準を解釈し、必要に応じて深刻度を調整しています。

critical: システム上の無関係のソフトウェア (またはシステム全体) を破壊する

特定のハードウェア上で、またはあるフレーバがサポートしているはずのシステム上で、カーネルが起動不可能な状態になったり、あるいは不安定な状態になるようなバグです。「関係の無いソフトウェア」 は存在しません。なぜなら全てカーネルに依存しているからです。

grave: 疑いのあるパッケージが使用不能、またはほとんどの場合使用不能になる

カーネルが使用不能な状態であれば、この基準を満たしています。

grave: ...またはデータ損失を引き起こす...

クラッシュすることでメモリ内のデータが失われる場合を除きます。ストレージ内のデータ破損や、通信中のデータ損失、またはデータ書き込み時のサイレント障害のみがあてはまります。

important

一般的に利用可能であるべきハードウェアがサポートされていない場合などがあてはまります。


9.1.3 タグ付け

私たちはユーザタグを使用しません。バグのトリアージ (選別、優先割り当て) を支援するために、私たちは BTS で定義された標準のタグと、forwarded フィールドを使用するべきです。具体的には:


9.1.4 メンテナによる解析

ほとんどの場合、よく似たハードウェアを所有していない限りバグの再現はあまり期待できません。以下の点を考慮してください:


9.1.5 報告者による検証

報告者の技術的な洗練度と、疑いのあるシステムに要求されるサービスの度合い (例えばそれが製品のサーバである等) によって、私たちは次のいずれかのリクエストをすることができます。

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.


9.1.6 バグを切り分ける

多くのバグ報告者が特徴的なエラーメッセージを探し出し、これを特定のバグであるかのように扱います。これは多くの 「ぶら下がり報告」 の原因になっています。例えば、ドライバのバグを示すメッセージに対して、他のドライバを使用している報告者がこれにぶら下がり報告をするケースなどです。

報告が複数の異なるバグに関する情報で溢れないように、

オリジナルのバグ報告が 複数のバグについて説明している場合は('...and other thing...')、報告をクローンしてそれぞれ個別に対応すべきです。


9.1.7 パッチの適用

パッチは通常であれば、適用される前に (古いバージョンのカーネルに対して必要な調整については別にして) 関係している上流のメンテナによってレビューされ、受け入れられます。


9.1.8 報告者との対話

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.


9.2 カーネルパッケージに対してバグ報告を行う

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 カーネルチームのリソースが限られていることは覚えておいてください。バグに効率的に反応できるかどうかは、バグ報告の情報の品質に左右されています。カーネルパッケージに対してバグ報告する場合は次のガイドラインを参考にして、私たちがより良い作業ができるよう手助けしてください。


9.2.1 二分探索 (バグを作り込んだアップストリームのバージョンを特定する)

ローカル環境でバグが簡単に再現できても、開発者が再現できない場合 (このような場合の多くはワークフローかハードウェアに依存したバグです)、いくつかのバージョンでコンパイルとテストを行い、どの変更がリグレションの原因になったのかを絞り込むと役に立ちます。

まずは 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 visualizegitk パッケージをインストールした状態で使用することで、ステップ間で何が起きたかを見ることができます。

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

The Debian Kernel Handbook Project