Linux kernel release 4.x http://kernel.org/
これらは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）（GNUコンパイラコレクションGCCの一部）の移植があれば、ほとんどの汎用32ビットまたは64ビットアーキテクチャに容易に移植できます。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.2パッチを逆適用（つまりpatch -R）して_から_4.0.3パッチを適用する必要があります。これに関する詳細は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を含む）の代替場所を指定できます。 例：
カーネルソースコード：/usr/src/linux-4.X
ビルドディレクトリ：/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のすべての呼び出しで使用する必要があります。
カーネルの設定：
マイナーバージョンだけをアップグレードする場合でも、この手順をスキップしないでください。新しい設定オプションは各リリースで追加され、設定ファイルが期待どおりに設定されていないと、奇妙な問題が発生します。既存の設定を最小限の作業で新しいバージョンに引き継ぐには、"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では動作しないカーネルになります。カーネルは起動時にこれを検出して停止します。
数値演算エミュレーションをコンパイルしたカーネルでも、コプロセッサが存在する場合はそれを使用します。その場合、数値演算エミュレーションは決して使用されません。カーネルは少し大きくなりますが、数値演算コプロセッサの有無にかかわらず、さまざまなマシンで動作します。
"kernel hacking"設定の詳細は、通常、カーネルが大きくなったり遅くなったり（あるいはその両方）し、一部のルーチンを設定して不良コードを積極的に壊そうとしてカーネルの問題を見つける（kmalloc()）ことにより、カーネルの安定性を損なう可能性もあります。したがって、"development"、"experimental"、または"debugging"機能の質問には 'n' と答えるべきです。
カーネルのコンパイル：
少なくともgcc 3.2が利用可能であることを確認してください。 詳細については、Documentation/Changesを参照してください。
このカーネルでは、a.outユーザープログラムも引き続き実行できることに注意してください。
"make"を実行して、圧縮されたカーネルイメージを作成します。liloがカーネルmakefileに適合するようにインストールされている場合は、"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を使用しており、/etc/lilo.confファイルで指定されたカーネルイメージを使用します。カーネルイメージファイルは通常、/vmlinuz、/boot/vmlinuz、/bzImageまたは/boot/bzImageです。新しいカーネルを使用するには、古いイメージのコピーを保存し、新しいイメージを古いイメージに上書きコピーします。次に、ロードマップを更新するためにLILOを再実行する必要があります！！そうしないと、新しいカーネルイメージを起動できません。
LILOの再インストールは、通常/sbin/liloを実行するだけです。新しいカーネルが動作しない場合に備えて、古いカーネルイメージ（例：/vmlinux.old）のエントリを/etc/lilo.confに指定することをお勧めします。詳細については、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が（誤って）カーネルがコンパイルされる開始オフセットを無視するためです。