Linux カーネル リリース 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 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 領域を使用しないでください！ この領域には、ライブラリのヘッダーファイルで使用される（通常は不完全な）カーネルヘッダーのセットがあります。これらはライブラリと一致している必要があり、その時々のカーネル（kernel-du-jour）によって壊されるべきではありません。
パッチを適用して 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 Window (Qt) ベースの構成ツール。
"make gconfig" X Window (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" すべてのモジュールオプションを組み込み (=y) オプションに変換することを除いて、localmodconfig と同様です。
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 を起動する場合、/etc/lilo.conf ファイルで指定されたカーネルイメージを使用する LILO を使用している可能性が高いです。カーネルイメージファイルは通常 /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 が（誤って）カーネルがコンパイルされた開始オフセットを無視するため、失敗します。