/usr/share/doc/debian-kernel-handbook-ja/kernel-handbook.ja.html/ch-bugs.html

<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>第9章 バグの報告と対処</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.1"><link rel="home" href="index.html" title="Debian Linux カーネルハンドブック"><link rel="up" href="index.html" title="Debian Linux カーネルハンドブック"><link rel="prev" href="ch-update-hooks.html" title="第8章 メンテナスクリプトとフック"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">第9章 バグの報告と対処</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch-update-hooks.html">戻る</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> </td></tr></table><hr></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="ch-bugs"></a>第9章 バグの報告と対処</h1></div></div></div><div class="toc"><p><b>目次</b></p><dl class="toc"><dt><span class="section"><a href="ch-bugs.html#s9.1">9.1. カーネルチームのバグ対処ポリシー</a></span></dt><dd><dl><dt><span class="section"><a href="ch-bugs.html#s9.1.1">9.1.1. 要求される情報</a></span></dt><dt><span class="section"><a href="ch-bugs.html#s9.1.2">9.1.2. 深刻度</a></span></dt><dt><span class="section"><a href="ch-bugs.html#s9.1.3">9.1.3. タグ付け</a></span></dt><dt><span class="section"><a href="ch-bugs.html#s9.1.4">9.1.4. メンテナによる解析</a></span></dt><dt><span class="section"><a href="ch-bugs.html#s9.1.5">9.1.5. 報告者によるテスト</a></span></dt><dt><span class="section"><a href="ch-bugs.html#s9.1.6">9.1.6. バグを切り分ける</a></span></dt><dt><span class="section"><a href="ch-bugs.html#s9.1.7">9.1.7. パッチの適用</a></span></dt><dt><span class="section"><a href="ch-bugs.html#s9.1.8">9.1.8. 報告者との対話</a></span></dt></dl></dd><dt><span class="section"><a href="ch-bugs.html#s9.2">9.2. カーネルパッケージに対してバグ報告を行う</a></span></dt><dd><dl><dt><span class="section"><a href="ch-bugs.html#s9.2.1">9.2.1. Bisecting (バグを作り込んだアップストリームのバージョンを特定する)</a></span></dt></dl></dd></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s9.1"></a>9.1. カーネルチームのバグ対処ポリシー</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="s9.1.1"></a>9.1.1. 要求される情報</h3></div></div></div><p>
報告者は問題のあるカーネルバージョンの環境下で <span class="command"><strong>reportbug</strong></span> か、それ以外の <code class="systemitem">bug</code>
スクリプトを実行するツールを使用することを期待されます。この情報のない報告に対する回答は、<span class="command"><strong>reportbug</strong></span>
を使用したフォローアップの要求でなくてはなりません。要求があってから 1
ヶ月以内にこれらの情報を私達が受け取らなかった場合、バグは閉じられる場合がります。
</p><p>
例外:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
カーネルが起動しなかったりとても不安定な場合は通常のシステム情報ではなく <a class="ulink" href="https://www.kernel.org/doc/Documentation/networking/netconsole.txt" target="_top">netconsole</a>、
<a class="ulink" href="https://www.kernel.org/doc/Documentation/serial-console.txt" target="_top">serial
console</a>、 または写真でコンソールメッセージを提出してください。
</p></li><li class="listitem"><p>
もし報告がアップストリームの認識しているバグに関するものであればシステムに関する情報は必要ありませんが、参照先を明確にしてください。(<a class="ulink" href="https://bugzilla.kernel.org" target="_top">bugzilla.kernel.org</a> や
<span class="command"><strong>git</strong></span> のコミット ID など。)
</p></li><li class="listitem"><p>
バグが明らかにハードウェア依存でなければ （例えばパッケージングのエラーなど）システムに関する情報は必要ありません。
</p></li><li class="listitem"><p>
特定のモデルに対するバグを報告する場合は、デバイスを列挙しなくてもよい場合があります。
</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="s9.1.2"></a>9.1.2. 深刻度</h3></div></div></div><p>
多くの報告者がバグの深刻度合いを間違えてバグ報告をします。私たちは次のように基準を解釈し、必要に応じて深刻度を調整しています。
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">critical: システム上の無関係のソフトウェア (またはシステム全体) を破壊する</span></dt><dd><p>
特定のハードウェア上で、またはあるフレーバがサポートしているはずのシステム上で、カーネルが起動不可能な状態になったり、あるいは不安定な状態になるようなバグです。「関係の無いソフトウェア」
は存在しません。なぜなら全てカーネルに依存しているからです。
</p></dd><dt><span class="term">grave: 疑いのあるパッケージが使用不能、またはほとんどの場合使用不能になる</span></dt><dd><p>
カーネルが使用不能な状態であれば、この基準を満たしています。
</p></dd><dt><span class="term">grave: ...またはデータ損失を引き起こす...</span></dt><dd><p>
クラッシュすることでメモリ内のデータが失われる場合を除きます。ストレージ内や、通信中のデータロス、またはデータ書き込み時のサイレント障害があてはまります。
</p></dd><dt><span class="term">important</span></dt><dd><p>
一般的に利用可能であるべきハードウェアがサポートされていない場合などがあてはまります。
</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="s9.1.3"></a>9.1.3. タグ付け</h3></div></div></div><p>
私達はユーザタグを使用しません。バグのトリアージを支援するために、私達は BTS
で定義された標準のタグと、<code class="literal">forwarded</code> フィールドを使用するべきです。とりわけ：
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
提出者からの返答を待っている場合 <code class="literal">moreinfo</code> タグを追加し、そうでない時は削除する
</p></li><li class="listitem"><p>
ハードウェア依存のバグには <code class="literal">unreproducible</code> タグを追加しない
</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="s9.1.4"></a>9.1.4. メンテナによる解析</h3></div></div></div><p>
一般的には、よく似たハードウェアを所有していない限りバグの再現はあまり期待できません。次のことを考慮すべきです：
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
<a class="ulink" href="https://bugzilla.kernel.org" target="_top">bugzilla.kernel.org</a>
などの関係しそうな他のバグトラッカーを探す (クローズされているバグも含めて)
</p></li><li class="listitem"><p>
カーネルのメーリングリストを検索する
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "><li class="listitem"><p>
多くのアーカイブの中で、<a class="ulink" href="http://news.gmane.org" target="_top">news.gmane.org</a>
が最もましなようです
</p></li><li class="listitem"><p>
メーリングリストに投稿されたパッチは <a class="ulink" href="https://patchwork.kernel.org" target="_top">patchwork.kernel.org</a> にアーカイブされています
</p></li></ul></div></li><li class="listitem"><p>
関連するソースファイルの git コミットログを参照する
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: circle; "><li class="listitem"><p>
リグレッションが発生した場合は、問題の無いバージョンから問題が発生したバージョンまでを調べましょう
</p></li><li class="listitem"><p>
それ以外の場合は、バグが修正されている場合があるため、問題が発生したバージョンから最新のバージョンを調べましょう
</p></li></ul></div></li><li class="listitem"><p>
kerneloops.org の類似した 「oops」 を調べる
</p></li><li class="listitem"><p>
'oops' に対してソースのマシーンコードとレジスタ値を比較し、どのように逸脱状態が発生したのかを調べる
(この方法がうまくいくことは稀ですが、うまくいった時は天才になった気分を味わえます ;-)
</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="s9.1.5"></a>9.1.5. 報告者によるテスト</h3></div></div></div><p>
報告者の技術的な洗練度と、疑いのあるシステムに要求されるサービスの度合い (例えばそれが製品のサーバである等)
によって、私たちは次のいずれかのリクエストをすることができます。
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
受け身でさらに多くの情報を集める (例えば、さらにログを取ったり procfs や sysfs の中身の報告を求めるなど)
</p></li><li class="listitem"><p>
最新の stable/stable-proposed-updates/stable-security
に同様の不具合に対する修正があった場合、最新のバージョンへのアップグレードを要求する
</p></li><li class="listitem"><p>
カーネルのコマンドラインやモジュールパラメータにデバッグやフォールバックオプションの追加を要求する
</p></li><li class="listitem"><p>
unstable か backports バージョンの一時的な利用を要求する
</p></li><li class="listitem"><p>
特定のパッチを適用したカーネルのリビルドを要求する (<span class="command"><strong>debian/bin/test-patches</strong></span>
スクリプトで簡単にできます)
</p></li><li class="listitem"><p>
<span class="command"><strong>git bisect</strong></span> でバグの原因となった特定のアップストリームの変更を探すよう要求する
</p></li></ul></div><p>
特定の製品やコンポーネントで、アップストリームにとっての現行または以前の stable
リリースでバグが発生し、わたしたちには修正できない場合は、報告者に<a class="ulink" href="https://bugzilla.kernel.org" target="_top">bugzilla.kernel.org</a>でアップストリームにバグを報告し、わたしたちにアップストリームのバグ番号を報告するようお願いします。わたしたちがバグを直接報告することはありません。アップストリームからのフォローアップの質問はわたしたちではなく、報告者に行くべきだからです。アップストリームのバグ番号の報告をもって、わたしたちはバグを
forwarded としてマークします。<span class="command"><strong>bts-link</strong></span> とそのステータスの更新
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="s9.1.6"></a>9.1.6. バグを切り分ける</h3></div></div></div><p>
多くのバグ報告者が特徴的なエラーメッセージを探し出し、これを特定のバグであるかのように扱います。これは多くの 'me too' follow-ups
の原因になっています。例えば、ドライバのバグを示すメッセージがある場合、2番目の報告者が別のドライバを使用しているようなケースです。
</p><p>
報告が複数の異なるバグに関する情報で溢れないように、
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
そのような返信に素早く対応し、別のバグ報告を送るようにお願いしなければなりません
</p></li><li class="listitem"><p>
バグの説明を向上させるために、BTS <code class="literal">summary</code> コマンドを使用することができます
</p></li><li class="listitem"><p>
最後の手段として、報告者毎に関連する情報とともに新たなバグ報告を作成し、オリジナルのバグ報告をクローズする必要があるかもしれません
</p></li></ul></div><p>
オリジナルのバグ報告に 1 つよりも多くのバグについて説明されている場合は('...and other thing...'
)、クローンしてそれぞれ個別に対応すべきです。
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="s9.1.7"></a>9.1.7. パッチの適用</h3></div></div></div><p>
パッチは通常であれば、適用される前に (古いバージョンのカーネルに対して必要な調整については別にして)
関係している上流のメンテナによってレビューされ、受け入れられます。
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="s9.1.8"></a>9.1.8. 報告者との対話</h3></div></div></div><p>
報告者に対しては常に丁寧に対応すべきです。これは、<a class="ulink" href="https://www.debian.org/social_contract" target="_top">社会契約</a>で示唆されているだけではなく、バグを迅速に解決することにも繋がる場合があります。報告者が深刻度を過剰にしてしまった場合は、静かにダウングレードしましょう。報告者が何か愚かなことをしてしまった場合は、それを取り消して報告し直すよう要求しましょう。'Sorry'
と 'please' を付けるだけで、印象が大きく変わります。
</p><p>
報告者への一般的なアドバイスは <a class="ulink" href="https://wiki.debian.org/DebianKernelReportingBugs" target="_top">https://wiki.debian.org/DebianKernelReportingBugs</a>
でメンテされています。
</p></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="s9.2"></a>9.2. カーネルパッケージに対してバグ報告を行う</h2></div></div></div><p>
Debian kernel チームはカーネルパッケージのバグを Debian Bug Tracking System (BTS)
で管理しています。このシステムの利用方法については、 <a class="ulink" href="https://bugs.debian.org" target="_top">
http://bugs.debian.org</a>
を参照してください。バグは、<span class="command"><strong>reportbug</strong></span>というパッケージと同名のコマンドを使用して送信することができます。Debian
から派生したディストリビューション (Knoppix、Mepis、Progeny、Ubuntu、Xandros など) に関するバグは Debian
BTS に報告し<span class="emphasis"><em>ない</em></span>で下さい。(公式の Debian カーネルパッケージを利用して、Debian
システム上で再現可能である場合を除きます。)派生ディストリビューションにはカーネルのパッケージングに関して独自のポリシーと手順があります。そこで発見されたバグは、彼らのバグ追跡システムやメーリングリストに直接報告されるべきです。
</p><p>
この章の内容は、あなたが Debian カーネルパッケージに対してバグ報告を行うことを避けることを意図したものではありません。しかし、Debian
カーネルチームのリソースが限られていることは覚えておいてください。
バグに効率的に反応できるかどうかは、バグレポートの情報の品質に左右されています。カーネルパッケージに対してバグ報告する場合は次のガイドラインを参考にして、私たちがより良い作業ができるよう手助けしてください。
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
<span class="emphasis"><em>調査する</em></span> バグ報告を行う前に特定のエラーメッセージや症状に関して web
上で検索を行いましょうあなただけがある問題に遭遇しているというのは極めて稀なケースです。常に、すでにどこかで議論されており、解決策や回避策やパッチが既に提示されている可能性が高いと考えるべきです。もし、そのような情報が存在する場合は、常にバグレポート内に参照先を示すようにしましょう。すでに同様の報告がされているかどうかについては、<a class="ulink" href="https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux" target="_top">current bug
list</a> を確認してください。
</p></li><li class="listitem"><p>
<span class="emphasis"><em>情報を収集する</em></span>
バグレポートには充分な情報を提供してください。レポートには最低限でも、バグに遭遇したDebian
公式カーネルパッケージのバージョンと、再現方法を記載してください。あなたが報告するバグの性質によっては、<span class="command"><strong>dmesg</strong></span>
の出力(または、その一部) と <span class="command"><strong>lspci -vn</strong></span>
の出力も報告してください。<span class="command"><strong>reportbug</strong></span>
は、これを自動で行います。あてはまる場合には、知りうる限りバグが発生しない最新のカーネルバージョンと、動作しているカーネルに対する上記のコマンド出力も報告してください。common
sense を使って、あなたが問題の解決の手助けになると思う情報を付加してください。
</p></li><li class="listitem"><p>
<span class="emphasis"><em> "vanilla" カーネルで再現させる</em></span> 機会があれば、"vanilla" カーネルからビルドした
バイナリカーネルイメージで再現できるか試してみてください。vanilla カーネルのソースは <a class="ulink" href="https://www.kernel.org" target="_top">https://www.kernel.org</a>
か、そのミラーから入手することができます。Debian の stock
カーネルと同じ設定を使用してください。このやり方についての詳しい情報は、<a class="xref" href="ch-common-tasks.html#s-common-building" title="4.5. Debian カーネルソースからカスタムカーネルをビルドする">「Debian カーネルソースからカスタムカーネルをビルドする」</a>
を参照して下さい。もしバグがカーネルに対して行なわれた Debian
特有の変更が原因であるという説得力のある証拠があれば、バグはカーネルチームによってより高い優先度をつけられます。もしバグが Debian
特有のものでない場合は、すでにアップストリームで報告済みでないか <a class="ulink" href="http://bugzilla.kernel.org" target="_top">kernel bug database</a>を確認してください。
アップストリームの問題であることが明確な場合は、そちらにもバグ報告をすることができます。(いずれにせよ、その問題を追跡できるように Debian BTS
には報告してください。)
</p></li><li class="listitem"><p>
<span class="emphasis"><em>正しいパッケージに対してバグ報告をする</em></span>: バグ報告は、問題が発生したカーネルのバージョン番号を持つパッケージ
(例えば <code class="systemitem">linux-image-3.2.0-2-686-pae</code>)
に対して行いメタパッケージ (例えば <code class="systemitem">linux-image-686-pae</code>) には報告しないでください。
</p></li><li class="listitem"><p>
<span class="emphasis"><em>tainted カーネルに関連するバグ</em></span>
カーネルがクラッシュした場合、通常はデバッグ情報を出力します。これには、動作中だったカーネルが taint (汚染)
されたかも含まれています。クラッシュ時にサードパーティ製のバイナリモジュールがロードされていたカーネルは tainted (汚染された)
と表現されます。カーネル開発者がソースコードを見ることができないので、そのようなモジュールが絡んだ問題はデバッグが非常に困難になります。そのような事情から、(例えばバイナリモジュールをロードしないようにするなどして)
untainted (汚染されていない)
カーネルで再現できるか試してみることを強くおすすめします。問題がそのようなモジュールの内部に起因するものであれば、カーネルコミュニティができることはあまりありませんので、直接モジュールの作成者に報告すると良いでしょう。
</p></li></ul></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="s9.2.1"></a>9.2.1. Bisecting (バグを作り込んだアップストリームのバージョンを特定する)</h3></div></div></div><p>
ローカル環境でバグが簡単に再現できても、開発者が再現できない場合
(このような場合の多くはワークフローかハードウェアに依存したバグです)、いくつかのバージョンでコンパイルとテストを行い、どの変更がリグレションの原因になったのかを絞り込むと役に立ちます。
</p><p>
まずは vanilla カーネルで問題を再現させましょう:
</p><pre class="screen">
<code class="prompt">#</code> <strong class="userinput"><code>apt-get install git build-essential</code></strong>
<code class="prompt">$</code> <strong class="userinput"><code>git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git</code></strong>
<code class="prompt">$</code> <strong class="userinput"><code>cd linux</code></strong>
</pre><p>
上記のコマンドで vanilla カーネルを取得します。<a class="xref" href="ch-common-tasks.html#s-common-building" title="4.5. Debian カーネルソースからカスタムカーネルをビルドする">「Debian カーネルソースからカスタムカーネルをビルドする」</a>で説明されている、バイナリパッケージの設定、ビルド、テストを行います:
</p><pre class="screen">
<code class="prompt">$</code> <strong class="userinput"><code>make localmodconfig</code></strong>  <em class="lineannotation"><span class="lineannotation">#最低限の設定</span></em>
<code class="prompt">$</code> <strong class="userinput"><code>scripts/config --disable DEBUG_INFO</code></strong>  <em class="lineannotation"><span class="lineannotation">#ビルドサイズを適度なサイズにおさえる</span></em>
<code class="prompt">$</code> <strong class="userinput"><code>make deb-pkg</code></strong>
<code class="prompt">#</code> <strong class="userinput"><code>dpkg -i ../linux-image-3.5.0_3.5.0-1_i386.deb</code></strong>  <em class="lineannotation"><span class="lineannotation">#パッケージ名は適当なもに置き換える</span></em>
<code class="prompt">#</code> <strong class="userinput"><code>reboot</code></strong>
</pre><p>
もしバグが再現できない場合は、/boot 内の公式な設定ファイルで試してみましょう。(それでも再現できない場合は勝利宣言をし祝杯を挙げましょう。)
</p><p>
bisection (二分探索) を開始するにはまず、どのバージョンが動作してどのバージョンが動作しなかったかを宣言します:
</p><pre class="screen">
<code class="prompt">$</code> <strong class="userinput"><code>cd linux</code></strong>
<code class="prompt">$</code> <strong class="userinput"><code>git bisect start</code></strong>
<code class="prompt">$</code> <strong class="userinput"><code>git bisect good v3.0</code></strong>  <em class="lineannotation"><span class="lineannotation">#問題ないことがわかっているバージョン (good)</span></em>
<code class="prompt">$</code> <strong class="userinput"><code>git bisect bad</code></strong>  <em class="lineannotation"><span class="lineannotation">#現在のバージョンは問題がある (bad)</span></em>
</pre><p>
git が中間バージョンをテストするためにチェックアウトします。準備しておいた設定を再利用し、ビルドしましょう。
</p><pre class="screen">
<code class="prompt">$</code> <strong class="userinput"><code>make silentoldconfig</code></strong>
<code class="prompt">$</code> <strong class="userinput"><code>make deb-pkg</code></strong>
</pre><p>
パッケージをインストールし、再起動させ、テストします。
</p><pre class="screen">
<code class="prompt">$</code> <strong class="userinput"><code>git bisect good</code></strong>  <em class="lineannotation"><span class="lineannotation">#このバージョンではバグが無い </span></em>
<code class="prompt">$</code> <strong class="userinput"><code>git bisect bad</code></strong>   <em class="lineannotation"><span class="lineannotation">#バグが存在する </span></em>
<code class="prompt">$</code> <strong class="userinput"><code>git bisect skip</code></strong>  <em class="lineannotation"><span class="lineannotation">#他のバグがあるためテストが難しい</span></em>
</pre><p>
そして次のイテレーションに移ります:
</p><pre class="screen">
<code class="prompt">$</code> <strong class="userinput"><code>make silentoldconfig</code></strong>
<code class="prompt">$</code> <strong class="userinput"><code>make deb-pkg</code></strong>
</pre><p>
プロセスの最後に、"first bad commit"
の名前が出力されます。これはバグを追うのに役立ちます。特定には至らなくても、何度かプロセスを繰り返しリグレッションの範囲を絞り込むことは有用です。その場合、<span class="command"><strong>git
bisect log</strong></span> コマンドを実行し、ログを出力します。 もし可視化したければ、<span class="command"><strong>git bisect
visualize</strong></span> を <span class="package">gitk</span>
パッケージをインストールした状態で使用することで、ステップ間で何が起きたかを見ることができます。
</p><p>
Christian Couder の文章、「git bisect でリグレッションと戦う」 に詳細な説明があります。<a class="ulink" href="https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html" target="_top">kernel.org</a>
から入手することができます。または、<a class="ulink" href="file:///usr/share/doc/git-doc/git-bisect-lk2009.html" target="_top">git-doc
package</a> を参照してください。
</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch-update-hooks.html">戻る</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">第8章 メンテナスクリプトとフック </td><td width="20%" align="center"><a accesskey="h" href="index.html">ホーム</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
debian-kernel-handbook-ja 1.0.18 / usr / share / doc / debian-kernel-handbook-ja / kernel-handbook.ja.html / ch-bugs.html
