これらは Linux バージョン 4 のリリースノートです。注意深くお読みください。これが一体何であるか、カーネルのインストール方法、そして問題が発生した場合の対処法が説明されています。
LINUX とは何か？
Linux は、Unix オペレーティングシステムのクローンであり、ネットワーク上に緩やかに結集したハッカーチームの支援を受けて Linus Torvalds によってゼロから書かれました。POSIX および Single UNIX Specification への準拠を目指しています。
本物のマルチタスク、仮想メモリ、共有ライブラリ、デマンドローディング、共有コピーオンライト実行ファイル、適切なメモリ管理、IPv4 および IPv6 を含むマルチスタックネットワーキングなど、現代の本格的な Unix に期待されるすべての機能を備えています。
GNU General Public License のもとで配布されています。詳細については、同梱の COPYING ファイルを参照してください。
どのようなハードウェアで動作するのか？
当初は 32 ビット x86 ベースの PC（386 以上）向けに最初に開発されましたが、現在では Linux は（少なくとも）Compaq Alpha AXP、Sun SPARC および UltraSPARC、Motorola 68000、PowerPC、PowerPC64、ARM、Hitachi SuperH、Cell、IBM S/390、MIPS、HP PA-RISC、Intel IA-64、DEC VAX、AMD x86-64、AXIS CRIS、Xtensa、Tilera TILE、AVR32、Renesas M32R の各アーキテクチャでも動作します。
Linux は、ページドメモリ管理ユニット（PMMU）と GNU C コンパイラ（gcc）（The GNU Compiler Collection、GCC の一部）の移植版があれば、ほとんどの汎用 32 ビットまたは 64 ビットアーキテクチャに容易に移植できます。Linux は PMMU を持たない多くのアーキテクチャにも移植されていますが、その場合機能は明らかにいくぶん制限されます。 Linux はそれ自体にも移植されています。現在ではカーネルをユーザースペースアプリケーションとして実行できます。これは UserMode Linux (UML) と呼ばれます。
ドキュメント：
インターネット上の電子形式と書籍の両方で、Linux 固有のものから一般的な UNIX の疑問に関するものまで、多くのドキュメントが入手可能です。LDP (Linux Documentation Project) の書籍については、任意の Linux FTP サイトのドキュメントサブディレクトリを参照することをお勧めします。この README はシステムのドキュメントを意図したものではありません。はるかに優れた情報源が利用可能です。
Documentation/ サブディレクトリにはさまざまな README ファイルがあります。これらには通常、たとえば一部のドライバに関するカーネル固有のインストールメモが含まれています。各ファイルに含まれる内容の一覧については、Documentation/00-INDEX を参照してください。Changes ファイルには、カーネルのアップグレードによって発生する可能性のある問題に関する情報が含まれているため、必ずお読みください。
Documentation/DocBook/ サブディレクトリには、カーネル開発者とユーザー向けのガイドがいくつか含まれています。これらのガイドは、PostScript (.ps)、PDF、HTML、man ページなど、さまざまな形式でレンダリングできます。インストール後、"make psdocs"、"make pdfdocs"、"make htmldocs"、または "make mandocs" を実行すると、要求された形式でドキュメントがレンダリングされます。
カーネルソースのインストール：
完全なソースをインストールする場合は、カーネルの tarball を権限のあるディレクトリ（例: ホームディレクトリ）に置き、解凍します：
xz -cd linux-4.X.tar.xz | tar xvf -
"X" は最新カーネルのバージョン番号に置き換えてください。
/usr/src/linux 領域を使用しないでください！この領域には、ライブラリのヘッダファイルによって使用される（通常は不完全な）カーネルヘッダのセットがあります。これらはライブラリと一致している必要があり、その時々のカーネルによって乱されてはなりません。
パッチを適用して 4.x リリース間でアップグレードすることもできます。パッチは xz 形式で配布されています。パッチによるインストールを行うには、新しいパッチファイルをすべて入手し、カーネルソースのトップレベルディレクトリ (linux-4.X) に入って、以下を実行します：
xz -cd ../patch-4.x.xz | patch -p1
現在のソースツリーのバージョン "X" より大きいすべてのバージョンについて、"x" を 順番に 置き換えれば、問題ないはずです。バックアップファイル (some-file-name~ または some-file-name.orig) を削除し、失敗したパッチ (some-file-name# または some-file-name.rej) がないことを確認することをお勧めします。もしあれば、あなたか私のどちらかが間違いを犯したということです。
4.x カーネル用のパッチとは異なり、4.x.y カーネル（-stable カーネルとも呼ばれます）用のパッチは増分的ではなく、ベースとなる 4.x カーネルに直接適用されます。たとえば、ベースカーネルが 4.0 で 4.0.3 パッチを適用したい場合、最初に 4.0.1 と 4.0.2 のパッチを適用してはなりません。同様に、カーネルバージョン 4.0.2 を実行していて 4.0.3 に移行したい場合は、4.0.3 パッチを適用する 前に 最初に 4.0.2 パッチを逆適用（つまり patch -R）する必要があります。これについては Documentation/applying-patches.txt で詳しく読むことができます。
あるいは、スクリプト patch-kernel を使用してこのプロセスを自動化することもできます。これは現在のカーネルバージョンを判別し、見つかったパッチを適用します。
linux/scripts/patch-kernel linux
上記のコマンドの最初の引数はカーネルソースの場所です。パッチは現在のディレクトリから適用されますが、代替ディレクトリを 2 番目の引数として指定できます。
古い .o ファイルや依存関係が残っていないことを確認してください：
cd linux make mrproper
これでソースが正しくインストールされたはずです。
ソフトウェア要件
4.x カーネルのコンパイルと実行には、さまざまなソフトウェアパッケージの最新バージョンが必要です。必要な最小バージョン番号とこれらのパッケージの更新方法については、Documentation/Changes を参照してください。これらのパッケージの古すぎるバージョンを使用すると、追跡が非常に困難な間接的なエラーが発生する可能性があるため、ビルド中や動作中に明らかな問題が発生したときにパッケージを更新するだけでよいとは考えないでください。
カーネルのビルドディレクトリ：
カーネルをコンパイルするとき、すべての出力ファイルはデフォルトでカーネルソースコードと一緒に保存されます。"make O=output/dir" オプションを使用すると、出力ファイル（.config を含む）の代替場所を指定できます。例：
kernel source code: /usr/src/linux-4.X
build directory: /home/name/build/kernel
カーネルを設定してビルドするには、次を使用します：
cd /usr/src/linux-4.X
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install
注意: 'O=output/dir' オプションを使用する場合、make のすべての呼び出しで使用する必要があります。
カーネルの設定：
マイナーバージョンを 1 つアップグレードするだけの場合でも、この手順を省略しないでください。各リリースで新しい設定オプションが追加され、設定ファイルが期待どおりにセットアップされていないと、奇妙な問題が発生します。既存の設定を最小限の作業で新しいバージョンに引き継ぎたい場合は、"make oldconfig" を使用してください。これにより、新しい質問への回答のみが求められます。
代替の設定コマンドは次のとおりです：
"make config" プレーンテキストインターフェース。
"make menuconfig" テキストベースのカラーメニュー、ラジオリスト、ダイアログ。
"make nconfig" 拡張されたテキストベースのカラーメニュー。
"make xconfig" X Windows (Qt) ベースの設定ツール。
"make gconfig" X Windows (Gtk) ベースの設定ツール。
"make oldconfig" 既存の ./.config ファイルの内容に基づいてすべての質問をデフォルトにし、 新しい設定シンボルについて質問します。
"make silentoldconfig" 上記と同様ですが、すでに回答済みの質問で画面を散らかすことを避けます。 さらに依存関係を更新します。
"make olddefconfig" 上記と同様ですが、プロンプトなしで新しいシンボルをデフォルト値に設定します。
"make defconfig" アーキテクチャに応じて、arch/$ARCH/defconfig または arch/$ARCH/configs/${PLATFORM}_defconfig のデフォルトシンボル値を 使用して ./.config ファイルを作成します。
"make ${PLATFORM}_defconfig" arch/$ARCH/configs/${PLATFORM}_defconfig のデフォルトシンボル値を 使用して ./.config ファイルを作成します。 "make help" を使用して、使用しているアーキテクチャで利用可能な すべてのプラットフォームの一覧を取得します。
"make allyesconfig" シンボル値を可能な限り 'y' に設定して ./.config ファイルを作成します。
"make allmodconfig" シンボル値を可能な限り 'm' に設定して ./.config ファイルを作成します。
"make allnoconfig" シンボル値を可能な限り 'n' に設定して ./.config ファイルを作成します。
"make randconfig" シンボル値をランダムな値に設定して ./.config ファイルを作成します。
"make localmodconfig" 現在の設定とロードされたモジュール (lsmod) に基づいて設定を作成します。 ロードされたモジュールに不要なモジュールオプションをすべて無効にします。
別のマシン用に localmodconfig を作成するには、そのマシンの lsmod を
ファイルに保存し、LSMOD パラメータとして渡します。
target$ lsmod > /tmp/mylsmod
target$ scp /tmp/mylsmod host:/tmp
host$ make LSMOD=/tmp/mylsmod localmodconfig
上記はクロスコンパイル時にも機能します。
"make localyesconfig" localmodconfig と同様ですが、すべてのモジュールオプションを 組み込み (=y) オプションに変換する点が異なります。
Linux カーネル設定ツールの使用方法の詳細については、Documentation/kbuild/kconfig.txt を参照してください。
"make config" に関する注意：
不要なドライバがあるとカーネルが大きくなり、状況によっては問題を引き起こす可能性があります。存在しないコントローラカードのプロービングが他のコントローラを混乱させる可能性があります。
"Processor type" を 386 より高く設定してカーネルをコンパイルすると、386 では動作しないカーネルになります。カーネルは起動時にこれを検出し、動作を停止します。
math-emulation を組み込んでコンパイルされたカーネルは、コプロセッサが存在する場合は引き続きそれを使用します。その場合、数学エミュレーションは単に使用されないだけです。カーネルは少し大きくなりますが、数学コプロセッサの有無に関係なく、さまざまなマシンで動作します。
"kernel hacking" 設定の詳細は、通常、カーネルを大きくしたり遅くしたり（またはその両方）し、カーネルの問題を見つけるために悪いコードを積極的に壊そうとするいくつかのルーチンを設定することで、カーネルをさらに不安定にする可能性もあります (kmalloc())。したがって、"development"、"experimental"、または "debugging" 機能に関する質問には 'n' と答えるべきでしょう。
カーネルのコンパイル：
少なくとも gcc 3.2 が利用可能であることを確認してください。 詳細については、Documentation/Changes を参照してください。
このカーネルでは a.out ユーザープログラムを引き続き実行できることに注意してください。
圧縮されたカーネルイメージを作成するには "make" を実行します。カーネルの makefile に適合する lilo がインストールされている場合は "make install" を実行することもできますが、最初に特定の lilo 設定を確認することをお勧めします。
実際のインストールを行うには root である必要がありますが、通常のビルドでは root 権限は必要ありません。root の名前をむやみに使わないでください。
カーネルの一部を `modules' として設定した場合は、"make modules_install" も実行する必要があります。
詳細なカーネルコンパイル/ビルド出力：
通常、カーネルビルドシステムはかなり静かなモード（ただし完全に無音ではない）で実行されます。ただし、あなたや他のカーネル開発者がコンパイル、リンク、その他のコマンドを実際に実行されたとおりに確認する必要がある場合があります。この場合は "verbose" ビルドモードを使用します。これは "make" コマンドに "V=1" を挿入することで行います。例：
make V=1 all
ビルドシステムに各ターゲットの再ビルドの理由も伝えさせるには、"V=2" を使用します。デフォルトは "V=0" です。
何か問題が発生した場合に備えて、バックアップカーネルを手元に置いてください。これは特に開発リリースに当てはまります。各新リリースにはデバッグされていない新しいコードが含まれているためです。そのカーネルに対応するモジュールのバックアップも必ず保持してください。現在動作しているカーネルと同じバージョン番号の新しいカーネルをインストールする場合は、"make modules_install" を実行する前にモジュールディレクトリのバックアップを作成してください。
あるいは、コンパイル前にカーネル設定オプション "LOCALVERSION" を使用して、通常のカーネルバージョンに一意のサフィックスを追加します。LOCALVERSION は "General Setup" メニューで設定できます。
新しいカーネルを起動するには、カーネルイメージ（例: コンパイル後の .../linux/arch/i386/boot/bzImage）を、通常の起動可能なカーネルがある場所にコピーする必要があります。
LILO などのブートローダの支援なしにフロッピーからカーネルを直接起動することは、もはやサポートされていません。
ハードドライブから Linux を起動する場合、おそらく LILO を使用しているでしょう。LILO は /etc/lilo.conf ファイルで指定されたカーネルイメージを使用します。カーネルイメージファイルは通常 /vmlinuz、/boot/vmlinuz、/bzImage、または /boot/bzImage です。新しいカーネルを使用するには、古いイメージのコピーを保存し、新しいイメージを古いイメージの上にコピーします。次に、ローディングマップを更新するために LILO を再実行する必要があります！！実行しないと、新しいカーネルイメージを起動できません。
LILO の再インストールは通常、/sbin/lilo を実行するだけです。新しいカーネルイメージが動作しない場合に備えて、/etc/lilo.conf を編集して古いカーネルイメージ（たとえば /vmlinux.old）のエントリを指定するとよいでしょう。詳細については LILO のドキュメントを参照してください。
LILO を再インストールしたら、準備は完了です。システムをシャットダウンして再起動し、お楽しみください！
カーネルイメージ内のデフォルトのルートデバイス、ビデオモード、ramdisk サイズなどを変更する必要がある場合は、'rdev' プログラムを使用してください（または、適切な場合は LILO ブートオプションを使用します）。これらのパラメータを変更するためにカーネルを再コンパイルする必要はありません。
新しいカーネルで再起動して、お楽しみください。
問題が発生した場合：
カーネルのバグが原因と思われる問題が発生した場合は、MAINTAINERS ファイルを確認して、問題が発生しているカーネルの部分に関連付けられている特定の人物がいるかどうかを確認してください。そこに誰も記載されていない場合は、次善の策として、私 ([email protected]) にメールを送り、可能であれば他の関連するメーリングリストやニュースグループにも送ってください。
すべてのバグレポートでは、必ず どのカーネルについて話しているのか、問題を再現する方法、そしてセットアップ内容を伝えてください（常識を働かせてください）。問題が新しいものであればその旨を伝え、古い問題であれば最初に気付いた時期を伝えるようにしてください。
バグが次のようなメッセージを引き起こす場合
unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:XXXXXXXX eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx
または、画面やシステムログに同様のカーネルデバッグ情報が表示される場合は、それを 正確に 複製してください。ダンプは理解できないように見えるかもしれませんが、問題のデバッグに役立つ情報が含まれています。ダンプの上のテキストも重要です。これはカーネルがコードをダンプした理由について何かを示しています（上記の例では、不正なカーネルポインタが原因です）。ダンプを理解する方法の詳細については、Documentation/oops-tracing.txt にあります。
CONFIG_KALLSYMS を有効にしてカーネルをコンパイルした場合は、ダンプをそのまま送信できます。それ以外の場合は、"ksymoops" プログラムを使用してダンプを理解する必要があります（ただし、CONFIG_KALLSYMS を有効にしてコンパイルすることが通常は推奨されます）。このユーティリティは ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ からダウンロードできます。あるいは、ダンプのルックアップを手動で行うこともできます：
上記のようなダンプのデバッグでは、EIP 値が何を意味するかを調べることができれば非常に役立ちます。16 進値自体は私や他の誰にとってもあまり役に立ちません。それは特定のカーネル設定に依存するためです。行うべきことは、EIP 行から 16 進値を取得し（"0010:" は無視）、カーネルのネームリストでそれを調べて、問題のアドレスを含むカーネル関数を特定することです。
カーネル関数名を見つけるには、症状を示したカーネルに関連付けられたシステムバイナリを見つける必要があります。これは 'linux/vmlinux' ファイルです。ネームリストを抽出し、カーネルクラッシュの EIP と照合するには、次を実行します：
nm vmlinux | sort | less
これにより、昇順に並べ替えられたカーネルアドレスの一覧が表示され、問題のアドレスを含む関数を簡単に見つけることができます。カーネルのデバッグメッセージによって示されるアドレスは、関数アドレスと正確に一致するとは限らないことに注意してください（実際、その可能性は非常に低いです）。そのため、単に一覧を 'grep' することはできません。ただし、一覧には各カーネル関数の開始点が示されているため、検索中のアドレスより低い開始アドレスを持ち、その後に続く関数がより高いアドレスを持つ関数を探すことで、目的の関数を見つけることができます。実際、問題レポートに少しの「コンテキスト」を含め、注目する行の周囲の数行を示すことをお勧めします。
何らかの理由で上記ができない場合（事前にコンパイルされたカーネルイメージなどを持っている場合）、セットアップについて可能な限り多くの情報を伝えることが役立ちます。詳細については REPORTING-BUGS ドキュメントをお読みください。
あるいは、実行中のカーネルに gdb を使用できます。（読み取り専用です。つまり、値を変更したりブレークポイントを設定したりすることはできません。）これを行うには、まず -g を付けてカーネルをコンパイルします。arch/i386/Makefile を適切に編集し、その後 "make clean" を実行します。また、CONFIG_PROC_FS を有効にする必要もあります（"make config" を使用）。
新しいカーネルで再起動したら、"gdb vmlinux /proc/kcore" を実行します。これで通常の gdb コマンドをすべて使用できます。システムがクラッシュしたポイントを調べるコマンドは "l *0xXXXXXXXX" です。（XXX を EIP 値に置き換えてください。）
実行されていないカーネルへの gdb の適用は、現在のところ失敗します。なぜなら gdb が（誤って）カーネルがコンパイルされた開始オフセットを無視するためです。