Linux カーネル リリース 4.x http://kernel.org/
これらは Linux バージョン 4 のリリースノートです。Linux が何であるか、 カーネルのインストール方法、問題が発生した場合の対処法が説明されているので、 注意深くお読みください。
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 領域は使用しないでください! この領域には、ライブラリのヘッダ ファイルが使用するカーネルヘッダのセット (通常は不完全) があります。これらは ライブラリと一致している必要があり、その時々のカーネルによって壊されてはいけま せん。
パッチを適用して 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 を含む) の場所を別の場所に指定できます。例:
カーネルソースコード: /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 のすべての呼び出しで 使用する必要があります。
カーネルの設定:
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 を組み込んでコンパイルされたカーネルは、コプロセッサが存在する 場合は引き続きそれを使用します。その場合、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 を再インストールしたら、準備は完了です。システムをシャットダウンして再起動 し、お楽しみください!
カーネルイメージ内のデフォルトのルートデバイス、ビデオモード、ラムディスクサイズ などを変更する必要がある場合は、'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' すること はできません。ただし、リストには各カーネル関数の開始点が示されているので、検索 対象のアドレスより低い開始アドレスを持ち、その後に続く関数がより高いアドレスを 持つ関数を探すことで、目的の関数が見つかります。実際、問題レポートに、関心のある 行の前後の数行を含む "context" を少し加えるとよいでしょう。
何らかの理由で上記を行うことができない場合 (事前にコンパイルされたカーネルイメー ジなどを使用している場合)、セットアップについて可能な限り詳しく伝えることが役立ち ます。詳細については 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 が (誤って) カーネルがコンパイルされた開始オフセットを無視するためです。