八津尾です。
Debian Kernel Handbook 9 章の翻訳です。
titanpad は http://yyatsuo.titanpad.com/10 です。
査読をお願いします。
<chapt id="bugs">
<!--
<heading>Reporting and handling bugs</heading>
-->
<heading>バグの報告と対処</heading>
<!--<sect> Bug handling policy for the kernel team-->
<sect>カーネルチームのバグ対処ポリシー
<!--<sect1>Required information -->
<sect1>要求される情報
<!--
Submitters are expected to run <prgn>reportbug</prgn> or
other tool that runs our <package>bug</package> script
under the kernel version in question. The response to
reports without this information should be a request to
follow-up using <prgn>reportbug</prgn>. If we do not
receive this information within a month of the request,
the bug may be closed.
-->
<p>
報告者は問題のあるカーネルバージョンの環境下で <prgn>reportbug</prgn> か、それ以外の <package>bug</package> スクリプトを実行するツールを使用することを求められます。この情報のない報告に対する回答として <prgn>reportbug</prgn> を使用するよう、フォローアップリクエストが行われます。リクエストがあってから 1 ヶ月以内に必要な情報を私たちが受け取らなかった場合、バグは閉じられる場合がります。
</p>
<p>
<!-- Exceptions: -->
例外:
<list>
<!--
If the kernel does not boot or is very unstable, instead
of the usual system information we need the console
messages via
<url id="http://www.kernel.org/doc/Documentation/networking/netconsole.txt"; name="netconsole">,
<url id="http://www.kernel.org/doc/Documentation/serial-console.txt"; name="serial console">,
or a photograph.
-->
<item>
カーネルが起動しなかったりとても不安定な場合は通常のシステム情報ではなく
<url id="http://www.kernel.org/doc/Documentation/networking/netconsole.txt"; name="netconsole">、
<url id="http://www.kernel.org/doc/Documentation/serial-console.txt"; name="serial console">、
または写真でコンソールメッセージを提出してください。
</item>
<!--
If the report is relaying information about a bug
acknowledged upstream, we do not need system
information but we do need specific references
(<httpsite>bugzilla.kernel.org</httpsite>
or <prgn>git</prgn> commit id).
-->
<item>
もし報告がアップストリームの認識しているバグに関するものであればシステムに関する情報は必要ありませんが、参照先を明確にしてください。(<httpsite>bugzilla.kernel.org</httpsite> や <prgn>git</prgn> のコミット ID など。)
</item>
<!--
If the bug is clearly not hardware-specific
(e.g. packaging error), we do not need system
information.
-->
<item>
バグが明らかにハードウェア依存でなければ （例えばパッケージングのエラーなど）システムに関する情報は必要ありません。
</item>
<!--
If the bug is reported against a well-defined model, we
may not need device listings.
-->
<item>
特定のモデルに対するバグを報告する場合は、デバイスを列挙しなくてもよい場合があります。
</item>
</list>
</p>
</sect1>
<!-- Severities -->
<sect1>深刻度
<p>
<!--
Many submitters report bugs with the wrong severity. We
interpret the criteria as follows and will adjust severity
as appropriate:
-->
多くの報告者が深刻度合いを間違えてバグ報告をします。私たちは次のように基準を解釈し、必要に応じて深刻度を調整しています。
<taglist>
<!--
critical: makes unrelated software on the system (or the
whole system) break...
-->
<tag>critical: システム上の無関係のソフトウェア (またはシステム全体) を破壊する</tag>
<!--
The bug must make the kernel unbootable or unstable on
common hardware or all systems that a specific flavour
is supposed to support. There is no 'unrelated
software' since everything depends on the kernel.
-->
<item> 特定のハードウェア上で、またはあるフレーバがサポートしているはずのシステム上で、カーネルが起動不可能な状態になったり、あるいは不安定な状態になるようなバグです。「関係の無いソフトウェア」 は存在しません。なぜなら全てカーネルに依存しているからです。</item>
<!--
grave: makes the package in question unusable or mostly so...
-->
<tag> grave: 疑いのあるパッケージが使用不能、またはほとんどの場合使用不能になる</tag>
<!--
If the kernel is unusable, this already qualifies as critical.
-->
<item> カーネルが使用不能な状態であれば、この基準を満たしています。</item>
<!--
grave: ...or causes data loss...
-->
<tag> grave: ...またはデータ損失を引き起こす...</tag>
<!--
We exclude loss of data in memory due to a crash. Only
corruption of data in storage or communication, or
silent failure to write data, qualifies.
-->
<item> クラッシュすることでメモリ内のデータが失われる場合を除きます。ストレージ内のデータ破損や、通信中のデータ損失、またはデータ書き込み時のサイレント障害のみがあてはまります。</item>
<!-- important -->
<tag> important </tag>
<!--
We include lack of support for new hardware that is
generally available.
-->
<item> 一般的に利用可能であるべきハードウェアがサポートされていない場合などがあてはまります。</item>
</taglist>
</p>
</sect1>
<!-- Tagging -->
<sect1>タグ付け
<p>
<!--
We do not use user-tags. In order to aid bug triage we
should make use of the standard tags
and <tt>forwarded</tt> field defined by the BTS. In
particular:
-->
私たちはユーザタグを使用しません。バグのトリアージ (選別、優先割り当て) を支援するために、私たちは BTS で定義された標準のタグと、<tt>forwarded</tt> フィールドを使用するべきです。具体例:
<list>
<!--
Add <tt>moreinfo</tt> whenever we are waiting for a
response from the submitter and remove it when we are
not
-->
<item>提出者からの返答を待っている場合 <tt>moreinfo</tt> タグを追加し、そうでない時は削除する</item>
<!--
Do not add <tt>unreproducible</tt> to bugs that may be
hardware-dependent
-->
<item> ハードウェア依存のバグには <tt>unreproducible</tt> タグを追加しない</item>
</list>
</p>
</sect1>
<!-- Analysis by maintainers -->
<sect1>メンテナによる解析
<p>
<!--
Generally we should not expect to be able to reproduce
bugs without having similar hardware. We should consider:
-->
ほとんどの場合、よく似たハードウェアを所有していない限りバグの再現はあまり期待できません。以下の点を考慮してください:
<list>
<!--
Searching <url id="http://bugzilla.kernel.org"; name="bugzilla.kernel.org">
(including closed bugs) or other relevant bug tracker
-->
<item> <url id="http://bugzilla.kernel.org"; name="bugzilla.kernel.org"> などの関係しそうな他のバグトラッカーを探す (クローズされているバグも含めて) </item>
<!-- Searching kernel mailing lists -->
<item> カーネルのメーリングリストを検索する
<list>
<!--
Of the many
archives, <url id="http://news.gmane.org"; name="news.gmane.org"> seems
to suck least
-->
<item>多くのアーカイブの中で、<url id="http://news.gmane.org"; name="news.gmane.org"> が最もましなようです</item>
<!--
Patches submitted to some lists are archived at
<url id="http://patchwork.kernel.org"; name="patchwork.kernel.org">
-->
<item> メーリングリストに投稿されたパッチは <url id="http://patchwork.kernel.org"; name="patchwork.kernel.org"> にアーカイブされています</item>
</list>
</item>
<!-- Viewing git commit logs for relevant source files -->
<item> 関連するソースファイルの git コミットログを参照する
<list>
<!--
In case of a regression, from the known good to the bad version
-->
<item>リグレッションが発生した場合は、問題の無いバージョンから問題が発生したバージョンまでを調べましょう</item>
<!--
In other cases, from the bad version forwards, in
case the bug has been fixed since
-->
<item>それ以外の場合は、バグが修正されている場合があるため、問題が発生したバージョンから最新のバージョンを調べましょう</item>
</list>
</item>
<!-- Searching kerneloops.org for similar oopses -->
<item>kerneloops.org の似ているケースを調べる</item>
<!--
Matching the machine code and registers in an 'oops'
against the source and deducing how the impossible
happened (this doesn't work that often but when it does
you look like a genius ;-)
-->
<item>'oops' に対してソースのマシーンコードとレジスタ値を比較し、どのように逸脱状態が発生したのかを調べる (この方法がうまくいくことは稀ですが、うまくいった時は天才になった気分を味わえます ;-) </item>
</list>
</p>
</sect1>
<!-- Testing by submitter -->
<sect1>報告者によるテスト
<p>
<!--
Depending on the technical sophistication of the submitter
and the service requirements of the system in question
(e.g. whether it's a production server) we can request one
or more of the following:
-->
報告者の技術的な洗練度と、疑いのあるシステムに要求されるサービスの度合い (例えばそれが製品のサーバである等) によって、私たちは次のいずれかのリクエストをすることができます。
<list>
<!--
Gathering more information passively (e.g. further
logging, reporting contents of files in procfs or sysfs)
-->
<item> 受け身でさらに多くの情報を集める (例えば、さらにログを取ったり procfs や sysfs の中身の報告を求めるなど) </item>
<!--
Upgrading to the current
stable/stable-proposed-updates/stable-security version,
if it includes a fix for a similar bug
-->
<item>最新の stable/stable-proposed-updates/stable-security に同様の不具合に対する修正があった場合、最新のバージョンへのアップグレードを要求する</item>
<!--
Adding debug or fallback options to the kernel command
line or module parameters
-->
<item>カーネルのコマンドラインやモジュールパラメータにデバッグやフォールバックオプションの追加を要求する</item>
<!--
Installing the unstable or backports version temporarily
-->
<item>unstable か backports バージョンの一時的な利用を要求する</item>
<!--
Rebuilding and installing the kernel with a specific patch added (the
script <prgn>debian/bin/test-patches</prgn> should make this easy)
-->
<item>特定のパッチを適用したカーネルのリビルドを要求する (<prgn>debian/bin/test-patches</prgn> スクリプトで簡単にできます) </item>
<!--
Using <prgn>git bisect</prgn> to find a specific
upstream change that introduced the bug
-->
<item><prgn>git bisect</prgn> でバグの原因となった特定のアップストリームの変更を探すよう要求する</item>
</list>
</p>
<p>
<!--
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 <httpsite>bugzilla.kernel.org</httpsite> 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.
<prgn>bts-link</prgn> then updates its status.
-->
特定の製品やコンポーネントで、アップストリームにとっての現行または以前の stable リリースでバグが発生し、私たちには修正できない場合は、報告者に <httpsite>bugzilla.kernel.org</httpsite> でアップストリームにバグを報告し、私たちにアップストリームのバグ番号を報告するようお願いします。私たちがバグを直接報告することはありません。アップストリームからのフォローアップの質問は私たちではなく、報告者に対して行われるべきだからです。アップストリームのバグ番号の報告をもって、私たちはバグを forwarded としてマークします。そして <prgn>bts-link</prgn> がステータスを更新します。
</p>
</sect1>
<!-- Keeping bugs separate -->
<sect1>バグを切り分ける
<p>
<!--
Many submitters search for a characteristic error message
and treat this as indicating a specific bug. This can
lead to many 'me too' follow-ups where, for example, the
message indicates a driver bug and the second submitter is
using a different driver from the original submitter.
-->
多くのバグ報告者が特徴的なエラーメッセージを探し出し、これを特定のバグであるかのように扱います。これは多くの 'me too' 返信の原因になっています。例えば、ドライバのバグを示すメッセージに対して、他のドライバを使用している報告者がこれにぶら下がり報告をするケースなどです。
</p>
<p>
<!--
In order to avoid the report turning into a mess of
conflicting information about two or more different bugs:
-->
報告が複数の異なるバグに関する情報で溢れないように、
<list>
<!--
We should try to respond to such a follow-up quickly,
requesting a separate bug report
-->
<item>そのような返信に素早く対応し、別のバグ報告を送るようにお願いしなければなりません</item>
<!--
We can use the BTS <tt>summary</tt> command to improve
the description of the bug
-->
<item>バグの説明を向上させるために、BTS <tt>summary</tt> コマンドを使用することができます</item>
<!--
As a last resort, it may be necessary to open new bugs
with the relevant information, set their submitters
accordingly, and close the original report
-->
<item>最後の手段として、報告者毎に関連する情報とともに新たなバグ報告を作成し、オリジナルのバグ報告をクローズする必要があるかもしれません</item>
</list>
</p>
<p>
<!--
Where the original report describes more than one bug
('...and other thing...'), we should clone it and deal
with each separately.
-->
オリジナルのバグ報告が 複数のバグについて説明している場合は('...and other thing...')、報告をクローンしてそれぞれ個別に対応すべきです。
</p>
</sect1>
<!-- Applying patches -->
<sect1>パッチの適用
<p>
<!--
Patches should normally be reviewed and accepted by the
relevant upstream maintainer (aside from necessary
adjustments for an older kernel version) before being
applied.
-->
パッチは通常であれば、適用される前に (古いバージョンのカーネルに対して必要な調整については別にして) 関係している上流のメンテナによってレビューされ、受け入れられます。
</p>
</sect1>
<!-- Talking to submitters -->
<sect1>報告者との対話
<p>
<!--
We should always be polite to submitters. Not only is
this implied by the
<url id="http://www.debian.org/social_contract";
name="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.
-->
報告者に対しては常に丁寧に対応すべきです。これは、<url id="http://www.debian.org/social_contract"; name="社会契約"> で示唆されているだけではなく、バグを迅速に解決することにもつながる場合があります。報告者が深刻度を過剰にしてしまった場合は、静かにダウングレードしましょう。報告者が何か愚かなことをしてしまった場合は、それを取り消して報告し直すよう要求しましょう。「Sorry」 と 「please」 を付けるだけで与える印象が大きく変わります。
</p>
<p>
<!--
We will maintain general advice to submitters at
<url id="http://wiki.debian.org/DebianKernelReportingBugs";
name="http://wiki.debian.org/DebianKernelReportingBugs";>.
-->
報告者への一般的なアドバイスは <url id="http://wiki.debian.org/DebianKernelReportingBugs"; name="http://wiki.debian.org/DebianKernelReportingBugs";> でメンテされています。
</p>
</sect1>
</sect>
<!-- Filing a bug against a kernel package -->
<sect>カーネルパッケージに対してバグ報告を行う
<p>
<!--
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 <url id="http://bugs.debian.org";
name="http://bugs.debian.org";>. You can also submit the bugs
by using the <tt>reportbug</tt> 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 <em>not</em> 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 バグ追跡システム (BTS) で管理しています。このシステムの利用方法については、<url id="http://bugs.debian.org"; name="http://bugs.debian.org";> を参照してください。バグは、<tt>reportbug</tt> という名前の、パッケージと同名のコマンドを使用して送信することができます。Debian から派生したディストリビューション (Knoppix、Mepis、Progeny、Ubuntu、Xandros など) に関するバグは Debian BTS に報告し<em>ない</em>で下さい。(公式の Debian カーネルパッケージを利用して Debian システム上で再現可能である場合を除きます)。派生ディストリビューションにはカーネルのパッケージングに関して独自のポリシーと手順があります。そこで発見されたバグは、彼らのバグ追跡システムやメーリングリストに直接報告されるべきです。
</p>
<p>
<!--
Nothing in this chapter is intended to keep you from filing a
bug against one of the Debian kernel packages. However, you should
recognize that the resources of the Debian kernel team are
limited, and efficient reaction to a bug is largely determined
by the amount and quality of the information included in the
bug report. Please help us to do a better job by using the
following guidelines when preparing to file the bug against
kernel packages:
-->
この章の内容は、あなたが Debian カーネルパッケージに対してバグ報告を行うことをためらわせることを意図したものではありません。しかし Debian カーネルチームのリソースが限られていることは覚えておいてください。バグに効率的に反応できるかどうかは、バグ報告の情報の品質に左右されています。カーネルパッケージに対してバグ報告する場合は次のガイドラインを参考にして、私たちがより良い作業ができるよう手助けしてください。
<list>
<!--
<em>Do the research.</em> 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 <url id="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux&src=linux-2.6"; name="current bug list">
to see whether something similar has been reported already.
-->
<item> <em>調査を行う</em>:
バグ報告を行う前に特定のエラーメッセージや症状に関して web 上で検索を行いましょうあなただけがある問題に遭遇しているというのは極めて稀なケースです。常に、すでにどこかで議論されており、解決策や回避策やパッチが既に提示されている可能性が高いと考えるべきです。もしそのような情報が存在する場合は、常にバグレポート内に参照先を示すようにしましょう。すでに同様の報告がされているかどうかについては、<url id="http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux&src=linux-2.6"; name="現在のバグ一覧">を確認してください。</item>
<!--
<em>Collect the information.</em> Please provide enough
information with your report. At a minimum, it should
contain the exact version of the official Debian kernel
package, where the bug is encountered, and steps to
reproduce it. Depending on the nature of the bug you are
reporting, you might also want to include the output of
<tt>dmesg</tt> (or portions thereof), output of the
<tt>lspci -vn</tt>. <prgn>reportbug</prgn> will do this
automatically. If applicable,
include the information about the latest known kernel
version where the bug is not present, and output of the
above commands for the working kernel as well. Use
common sense and include other relevant information,
if you think that it might help in solving the problem.
-->
<item> <em>情報を収集する</em>:
バグレポートには充分な情報を提供してください。レポートには最低限でも、バグに遭遇した Debian 公式カーネルパッケージのバージョンと、再現方法を記載してください。あなたが報告するバグの性質によっては、<tt>dmesg</tt> の出力 (または、その一部) と <tt>lspci -vn</tt> の出力も報告してください。<prgn>reportbug</prgn> は、これを自動で行います。あてはまる場合には、知りうる限りバグが発生しない最新のカーネルバージョンと動作しているカーネルに対する上記のコマンド出力も報告してください。あなたの common sense を使い、あなたが問題の解決の手助けになると思う情報を付加してください。</item>
<!--
<em>Try to reproduce the problem with "vanilla" kernel.</em>
If you have a chance, try to reproduce the problem by
building the binary kernel image from the "vanilla" kernel
source, available from <url id="http://www.kernel.org";
name="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 <ref
id="common-building">. 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 <url
id="http://bugzilla.kernel.org"; name="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).
-->
<item> <em> "vanilla" カーネルで再現させる</em>:
機会があれば、"vanilla" カーネルからビルドした バイナリカーネルイメージで再現できるか試してみてください。vanilla カーネルのソースは<url id="http://www.kernel.org"; name="http://www.kernel.org";> か、そのミラーから入手することができます。Debian の stock カーネルと同じ設定を使用してください。これをどのように実施するか、さらに詳しい情報は、<ref id="common-building">を参照して下さい。もしバグがカーネルに対して行なわれた Debian 特有の変更が原因であるという説得力のある証拠があれば、バグはカーネルチームによってより高い優先度をつけられます。もしバグが Debian 特有のものでない場合は、すでにアップストリームで報告済みでないか<url id="http://bugzilla.kernel.org"; name="kernel bug database">を確認してください。 アップストリームの問題であることが明確な場合は、そちらにもバグ報告をすることができます。(いずれにせよ、その問題を追跡できるように Debian BTS には報告してください。)</item>
<!--
<em>Use the correct package to report the bug against.</em>
Please file bugs against the package containing the kernel
version where the problem occurs
(e.g. <package>linux-image-3.2.0-2-686-pae</package>), not
a metapackage (e.g. <package>linux-image-686-pae</package>).
-->
<item> <em>正しいパッケージに対してバグ報告をする</em>:
バグ報告は、問題が発生したカーネルのバージョン番号を持つパッケージに対して行いメタパッケージ (e.g. <package>linux-image-686-pae</package>) には報告しないでください。</item>
<!--
<em>Bugs involving tainted kernels.</em> If a kernel
crashes, it normally prints out some debugging
information, indicating, among other things, whether the
running kernel has been tainted. The kernel is referred to
as tainted if at the time of the crash it had some binary
third-party modules loaded. As kernel developers do not
have access to the source code for such modules, problems
involving them are notoriously difficult to debug. It is
therefore strongly recommended to try and reproduce the
problem with an untainted kernel (by preventing the loading
of binary modules, for example). If the problem is due to
the presence of such modules, there is not much the kernel
community can do about it and it should be reported directly
to their authors.
-->
<item> <em>tainted カーネルに関連するバグ</em>:
カーネルがクラッシュした場合、通常はデバッグ情報を出力します。これには、動作中だったカーネルが taint (汚染) だったかも含まれています。クラッシュ時にサードパーティ製のバイナリモジュールがロードされていたカーネルは tainted (汚染された) と表現されます。カーネル開発者がソースコードを見ることができないので、そのようなモジュールが絡んだ問題はデバッグが非常に困難になります。そのような事情から、(例えばバイナリモジュールをロードしないようにするなどして) untainted (汚染されていない) カーネルで再現できるか試してみることを強くおすすめします。問題がそのようなモジュールの内部に起因するものであれば、カーネルコミュニティができることはあまりありませんので、直接モジュールの作成者に報告すると良いでしょう。</item>
</list>
</p>
<!-- Bisecting (finding the upstream version that introduced a bug) -->
<sect1>二分探索 (バグを作り込んだアップストリームのバージョンを特定する)
<p>
<!--
When a bug is easy to reproduce locally but hard to get developers
to reproduce (as is often true of workflow- or hardware-dependent
bugs), it can be useful to compile and test a few versions to narrow
down what changes introduced the regression.
-->
ローカル環境でバグが簡単に再現できても、開発者が再現できない場合 (このような場合の多くはワークフローかハードウェアに依存したバグです)、いくつかのバージョンでコンパイルとテストを行い、どの変更がリグレションの原因になったのかを絞り込むと役に立ちます。
</p>
<!--
To start, recreate the problem with a vanilla kernel:
<example>
# apt-get install git build-essential
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
</example>
The above commands acquire a vanilla kernel.
Configure, build and test a binary package as explained in
<ref id="common-building">:
<example>
$ make localmodconfig; # minimal configuration
$ scripts/config disable DEBUG_INFO; # to keep the build reasonably small
$ make deb-pkg
# dpkg -i ../linux-image-3.5.0_3.5.0-1_i386.deb; # substitute package name from the previous command
# reboot
</example>
If the bug doesn't show up, try again with the official
configuration file from /boot. (If it still doesn't show up
after that, declare victory and celebrate.)
-->
<p>
まずは vanilla カーネルで問題を再現させましょう:
<example>
# apt-get install git build-essential
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
</example>
上記のコマンドで vanilla カーネルを取得します。<ref id="common-building">で説明したバイナリパッケージの設定、ビルド、テストを行うには:
<example>
$ make localmodconfig; # 最低限の設定
$ scripts/config --disable DEBUG_INFO; # ビルドサイズを適度なサイズにおさえる
$ make deb-pkg # dpkg -i ../linux-image-3.5.0_3.5.0-1_i386.deb; # パッケージ名は適当なもに置き換える
# reboot
</example>
もしバグが再現できない場合は、/boot 内の公式な設定ファイルで試してみましょう。(それでも再現できない場合は勝利宣言をし祝杯を挙げましょう。)
</p>
<!--
Initialize the bisection process by declaring which versions worked
and did not work:
<example>
$ cd linux
$ git bisect start
$ git bisect good v3.0; # or whichever was known to be good
$ git bisect bad; # current version is bad
</example>
Now git checks out a version half-way in between to test.
Build it, reusing the prepared configuration.
<example>
$ make silentoldconfig
$ make deb-pkg
</example>
</p>
-->
<p>
bisection (二分探索) を開始するにはまず、どのバージョンが動作してどのバージョンが動作しなかったかを宣言します:
<example>
$ cd linux
$ git bisect start
$ git bisect good v3.0; # 問題ない (good) ことがわかっているいずれかのバージョン
$ git bisect bad; # 現在のバージョンは問題がある (bad)
</example>
git が中間バージョンをテストするためにチェックアウトします。準備しておいた設定を再利用し、ビルドしましょう。
<example>
$ make silentoldconfig
$ make deb-pkg
</example>
</p>
<!--
Install the package, reboot, and test.
<example>
$ git bisect good; # if this version doesn't exhibit the bug
$ git bisect bad; # if it does
$ git bisect skip; # if some other bug makes it hard to test
</example>
And on to the next iteration:
<example>
$ make silentoldconfig
$ make deb-pkg
</example>
-->
<p>
パッケージをインストールし、再起動させ、テストします。
<example>
$ git bisect good; # このバージョンではバグが無い
$ git bisect bad; # バグが存在する
$ git bisect skip; # 他のバグがあるためテストが難しい
</example>
そして次のイテレーションに移ります:
<example>
$ make silentoldconfig
$ make deb-pkg
</example>
</p>
<!--
At the end of the process, the name of the "first bad commit" is
printed, which is very useful for tracking down the bug. Narrowing
down the regression range with a few rounds is useful even if you
don't get that far; in that case, run <tt>git bisect log</tt> to
produce a log. If you are the visual sort of person, <tt>git bisect
visualize</tt> with the <tt>gitk</tt> package installed can show
what is happening between steps.
-->
<p>
プロセスの最後に、「first bad commit (問題が発生した最初のコミット)」 の名前が出力されます。これはバグを追うのに役立ちます。特定には至らなくても、何度かプロセスを繰り返しリグレッションの範囲を絞り込むことは有用です。その場合次のコマンドを実行しログを出力します。 <tt>git bisect log</tt> もし可視化したければ <tt>git bisect visualize</tt> を <tt>gitk</tt> パッケージをインストールした状態で使用することで、ステップ間で何が起きたかを見ることができます。
</p>
<p>
詳細は <url id="http://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html"; name="kernel.org"> または <url id="file:///usr/share/doc/git-doc/git-bisect-lk2009.html" name="the git-doc package"> から入手可能な Christian Couder の文章、 「git bisect でリグレッションと戦う」 を参照して下さい。
</p>
</sect1>
</sect>
</chapt>
Attachment:
signature.asc
Description: Digital signature