カーネル

提供: ArchWiki
（Linuxから転送）
ナビゲーションに移動 検索に移動

関連記事

Wikipedia によると:

Linux カーネルとは、モノリシックで Unix ライクなオープンソースのコンピュータオペレーティングシステムカーネルである。

Arch Linux は Linux カーネルをベースにしています。Arch Linux では最新の安定版カーネルに加え、様々な代替 Linux カーネルを利用することができます。この記事では、リポジトリで利用可能な選択肢のいくつかを、それぞれの簡単な説明とともにリストアップしています。また、システムのカーネルに適用できるパッチについての説明もあります。記事の最後には、カスタムカーネルのコンパイルについての概要と、様々な方法へのリンクがあります。

カーネルのパッケージは /usr/lib/modules/ にインストールされます。その後、パッケージは vmlinuz 実行可能イメージを生成するために使用され、生成されたイメージは /boot/ へ保存されます。[1] 異なるカーネルをインストールしたり、複数のカーネルを切り替えたりする場合は、変更を反映させるためにブートローダーを設定しなければなりません。

公式サポートカーネル

公式にサポートされているカーネルについては、フォーラムでのコミュニティサポートとバグレポートを利用できます。

  • Stable — いくつかのパッチを適用したバニラな Linux カーネル。
https://www.kernel.org/ || linux
  • Hardened — カーネルおよびユーザ空間の脆弱性を緩和するための一連の堅牢化パッチを適用した、セキュリティ特化の Linux カーネルです。また、linux よりも多くの上流のカーネル堅牢化機能を有効にします。
https://github.com/anthraxx/linux-hardened || linux-hardened
  • Longterm — サーバーでの使用を対象にしたコンフィグオプションが含まれている、長期サポート (LTS) Linux カーネルおよびモジュール。
https://www.kernel.org/ || linux-lts
  • リアルタイムカーネル — IngoMolnar が率いるコア開発者の小グループによって維持されています。このパッチを使用すると、コードのいくつかの非常に小さな領域（"raw_spinlock クリティカル領域"）を除いて、ほぼすべてのカーネルをプリエンプトできます。これは、ほとんどのカーネルスピンロックを優先度継承をサポートするミューテックスに置き換え、すべての割り込みとソフトウェア割り込みをカーネルスレッドに移動することによって行われます。
https://wiki.linuxfoundation.org/realtime/start || linux-rt, linux-rt-lts
ノート: リアルタイムカーネルサポートは Linux 6.12 にマージされました。
  • Zen Kernel — カーネルハッカーの共同作業により、日常的なシステムに最適な Linux カーネルです。より詳細な情報は FAQ と Detailed Feature List を参照してください。
https://github.com/zen-kernel/zen-kernel || linux-zen

コンパイル

次の方法を使って、独自のカーネルをコンパイルできます。

Arch Build System
既存の linux PKGBUILD の高い品質とパッケージ管理の利点を生かします。
伝統的な方法
手動でソースの tarball をダウンロードし、ホームディレクトリで通常のユーザーとしてコンパイルする必要があります。
警告:
  • カスタムカーネルを使用すると、データの損失など、あらゆる種類の安定性と信頼性の問題が発生する可能性があります。バックアップをとることを強くお勧めします。
  • Arch Linux は #公式サポートカーネルのみを公式にサポートしています。別のカーネルを使用する場合は、サポートリクエストにその旨を記載してください。
ヒント:
  • システムの速度を上げる最良の方法は、まず、カーネルの設定をアーキテクチャやプロセッサの種類に合わせることです。
  • 自分が持っていないもの、使っていないもののサポートを含まないようにすることで、カーネルのサイズ (つまりビルド時間) を小さくすることができます。例えば、Bluetooth、video4linux、1000Mbit イーサネットなどのサポートです。
Arch のカーネルパッケージ設定ファイルは Arch のパッケージのソースファイルに含まれています。例えば linux の場合 [2] にリンクがあります。今現在動かしているカーネルのコンフィグファイルはファイルシステムの /proc/config.gz に存在します (カーネルオプションの CONFIG_IKCONFIG_PROC が有効になっている場合。)

リストにあるパッケージの中には、非公式ユーザーリポジトリからバイナリパッケージを入手できるものもあります。

kernel.org カーネル

  • Git — Linus Torvalds の git リポジトリから得たソースを使ってビルドする Linux カーネルとモジュール。
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git || linux-gitAUR
  • Mainline — すべての新機能が導入されるカーネル、2〜3ヶ月ごとにリリースされます。
https://www.kernel.org/ || linux-mainlineAUR
  • Next — 次の Mainline リリースにマージされる予定の機能を持つ最先端のカーネル。
https://www.kernel.org/doc/man-pages/linux-next.html || linux-next-gitAUR
  • DRM — 最先端の GPU ドライバ付き Linux カーネル。
https://cgit.freedesktop.org/drm/ || linux-drm-tip-gitAUR, linux-drm-next-gitAUR
  • Longterm 4.19 — 長期サポート (LTS) Linux 4.19 カーネルとモジュール。
https://www.kernel.org/ || linux-lts419AUR
  • Longterm 5.4 — 長期サポート (LTS) Linux 5.4 カーネルとモジュール。
https://www.kernel.org/ || linux-lts54AUR
  • Longterm 5.10 — 長期サポート (LTS) Linux 5.10 カーネルとモジュール。
https://www.kernel.org/ || linux-lts510AUR
  • Longterm 5.15 — 長期サポート (LTS) Linux 5.15 カーネルとモジュール。
https://www.kernel.org/ || linux-lts515AUR
  • Longterm 6.1 — 長期サポート (LTS) Linux 6.1 カーネルとモジュール。
https://www.kernel.org/ || linux-lts61AUR

非公式カーネル

  • Ck — デスクトップに特に重点を置いてシステムの応答性を向上させるように設計された Con Kolivas (MuQSS scheduler を含む) によるパッチが含まれていますが、どのような使用目的でも問題なく使えます。
http://ck.kolivas.org/ || linux-ckAUR
  • Clear — Intel の Clear Linux プロジェクトからのパッチ、パフォーマンスとセキュリティの最適化を提供します。
https://github.com/clearlinux-pkgs/linux || linux-clearAUR
https://www.fsfla.org/ikiwiki/selibre/linux-libre/ || linux-libreAUR
  • Liquorix — Debian をターゲットとした設定と Zen カーネルソースを使用して構築されたカーネル代替品。デスクトップ、マルチメディア、ゲームなどのワークロード向けに設計されており、Debian Linux の性能代替カーネルとしてよく利用されます。Liquorix パッチセットのメンテナである Damentz は、同様に Zen パッチセットの開発者でもあります。
https://liquorix.net || linux-lqxAUR
  • pf-kernel — カーネルメインラインにマージされない、ほんの少しの素晴らしい機能を提供します。カーネルエンジニアによって管理されています。新しいカーネルのための含まれるパッチのポートが公式にリリースされていない場合、パッチセットは新しいカーネルへのパッチポートを提供し、サポートします。linux-pf の現在の最も代表的なパッチは、UKSM、DDCCI、v4l2loopback、そして BBRv3 です。
https://pfkernel.natalenko.name || パッケージ:
  • Project C — Alfred Chen 氏の Project C パッチセット (BMQ スケジューラと PDS スケジューラ) を当てたカーネル。
https://gitlab.com/alfredchen/projectc || linux-prjcAUR
  • Nitrous — Skylake 及びそれ以降に対して最適化された修正版 Linux カーネル。
https://gitlab.com/xdevs23/linux-nitrous || linux-nitrousAUR
  • tkg — デスクトップやゲームのパフォーマンスを向上させるためのパッチや調整を提供する、高度にカスタマイズ可能なカーネルビルドシステム。Etienne Juvigny によってメンテナンスされています。他のパッチの中で、様々な CPU スケージューラを提供しています: CFS、Project C PDS、Project C BMQ、MuQSS、CacULE。
https://github.com/Frogging-Family/linux-tkg || chaotic-aur リポジトリで利用可能
  • VFIO — Alex Williamson によって作成されたいくつかのパッチ（acs オーバーライドおよび i915）により、一部のマシンで KVM を使用して PCI パススルーを実行できるようになります。
https://lwn.net/Articles/499240/ || linux-vfioAUR, linux-vfio-ltsAUR
  • XanMod — 高性能ワークステーション、ゲーミングデスクトップ、メディアセンターなどで最大限に活用されることを目指し、より強固で応答性の高い、スムーズなデスクトップ体験を提供するために構築されています。このカーネルでは、BFQ I/O スケジューラ、TCP BBRv3 輻輳制御、x86_64 高度命令セットのサポート、部分的な Clear Linux パッチセットが使用されており、また一部のデフォルトも変更されています。
https://xanmod.org/ || linux-xanmodAUR, linux-xanmod-ltsAUR, linux-xanmod-rtAUR, linux-xanmod-boreAUR
  • linux-cachyos — Linux SCHED-EXT + BORE + CachyOS の Cachy Sauce Kernel に加え、その他のパッチや改善されたカーネルモジュールが含まれています。
https://github.com/CachyOS/linux-cachyos || linux-cachyosAUR

トラブルシューティング

カーネルパニック

Linux カーネルが回復不能な障害状態になると、カーネルパニックが発生します。この状態は通常、バグのあるハードウェアドライバーが原因で、マシンがデッドロックされ、応答しなくなり、再起動が必要になります。デッドロックの直前に、診断メッセージが生成されます。これは、障害が発生したときのマシンの状態、障害を検出したカーネルの関数までの 呼び出しトレース、および現在ロードされているモジュールのリストです。ありがたいことに、カーネルのメインラインバージョン (公式リポジトリで提供されているものなど) を使用してカーネルパニックが発生することはあまりありませんが、発生した場合に備えて対処方法を知る必要があります。

ノート: カーネルパニックは、oops またはカーネル oops と呼ばれることもあります。パニックと oops は両方とも障害状態の結果として発生するものですが、oops はより一般的なものであり、必ずしもマシンがデッドロックするわけではありません。問題のあるタスクを強制終了して実行を継続することで、カーネルが oops から回復できる場合があります。
ヒント: 回復可能な oops で代わりにパニックを発生させることを強制するには、カーネルパラメータ oops=panic を起動時に渡すか、/proc/sys/kernel/panic_on_oops に 1 を書き込んでください。oops リカバリによってシステムが不安定になり将来のエラーの診断が困難になることを懸念しているのであれば、これは推奨される方法です。

パニックメッセージの検証

カーネルパニックがブートプロセスの非常に早い段階で発生する場合、コンソール上に "Kernel panic - not syncing:" というメッセージが表示されることがありますが、Systemd が実行し始めると、通常カーネルメッセージはキャプチャされシステムのログに書き込まれます。しかし、パニックが発生した際には、カーネルによる診断メッセージ出力はほとんどの場合ディスク上のログファイルに書き込まれません。system-journald がメッセージを取得・記録する前にマシンがデッドロックしてしまうからです。なので、パニックメッセージを検証する唯一の手段は、(kdump crashkernel を設定することなく)パニックの発生時にメッセージをコンソール上で見ることです。以下のカーネルパラメータを渡して起動し、tty1 でパニックの再現を試みてください: 

systemd.journald.forward_to_console=1 console=tty1
ヒント: パニックメッセージが速くスクロールしすぎて検証できない場合、起動時にカーネルパラメータ pause_on_oops=秒数 を渡してみてください。
例: 不良モジュール

診断メッセージの情報を使って、何のサブシステムやモジュールがパニックを引き起こしているかを推測できます。この例では、とある架空のマシンで起動中にパニックが発生してしまいました。太字で強調した行に注目してください。 

kernel: BUG: unable to handle kernel NULL pointer dereference at (null) 1
kernel: IP: fw_core_init+0x18/0x1000 [firewire_core] 2
kernel: PGD 718d00067
kernel: P4D 718d00067
kernel: PUD 7b3611067
kernel: PMD 0
kernel:
kernel: Oops: 0002 [#1] PREEMPT SMP
kernel: Modules linked in: firewire_core(+) crc_itu_t cfg80211 rfkill ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_ipv4 ... 3
kernel: CPU: 6 PID: 1438 Comm: modprobe Tainted: P           O    4.13.3-1-ARCH #1
kernel: Hardware name: Gigabyte Technology Co., Ltd. H97-D3H/H97-D3H-CF, BIOS F5 06/26/2014
kernel: task: ffff9c667abd9e00 task.stack: ffffb53b8db34000
kernel: RIP: 0010:fw_core_init+0x18/0x1000 [firewire_core]
kernel: RSP: 0018:ffffb53b8db37c68 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
kernel: RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffffc16d3af4
kernel: RBP: ffffb53b8db37c70 R08: 0000000000000000 R09: ffffffffae113e95
kernel: R10: ffffe93edfdb9680 R11: 0000000000000000 R12: ffffffffc16d9000
kernel: R13: ffff9c6729bf8f60 R14: ffffffffc16d5710 R15: ffff9c6736e55840
kernel: FS:  00007f301fc80b80(0000) GS:ffff9c675dd80000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000000 CR3: 00000007c6456000 CR4: 00000000001406e0
kernel: Call Trace:
kernel:  do_one_initcall+0x50/0x190 4
kernel:  ? do_init_module+0x27/0x1f2
kernel:  do_init_module+0x5f/0x1f2
kernel:  load_module+0x23f3/0x2be0
kernel:  SYSC_init_module+0x16b/0x1a0
kernel:  ? SYSC_init_module+0x16b/0x1a0
kernel:  SyS_init_module+0xe/0x10
kernel:  entry_SYSCALL_64_fastpath+0x1a/0xa5
kernel: RIP: 0033:0x7f301f3a2a0a
kernel: RSP: 002b:00007ffcabbd1998 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
kernel: RAX: ffffffffffffffda RBX: 0000000000c85a48 RCX: 00007f301f3a2a0a
kernel: RDX: 000000000041aada RSI: 000000000001a738 RDI: 00007f301e7eb010
kernel: RBP: 0000000000c8a520 R08: 0000000000000001 R09: 0000000000000085
kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000c79208
kernel: R13: 0000000000c8b4d8 R14: 00007f301e7fffff R15: 0000000000000030
kernel: Code: <c7> 04 25 00 00 00 00 01 00 00 00 bb f4 ff ff ff e8 73 43 9c ec 48
kernel: RIP: fw_core_init+0x18/0x1000 [firewire_core] RSP: ffffb53b8db37c68
kernel: CR2: 0000000000000000
kernel: ---[ end trace 71f4306ea1238f17 ]---
kernel: Kernel panic - not syncing: Fatal exception 5
kernel: Kernel Offset: 0x80000000 from 0xffffffff810000000 (relocation range: 0xffffffff800000000-0xfffffffffbffffffff
kernel: ---[ end Kernel panic - not syncing: Fatal exception
  1. パニックを引き起こしたエラーの種類を示しています。この場合、プログラマのバグです。
  2. モジュール firewire_core 内の fw_core_init という関数でパニックが発生したことを示しています。
  3. firewire_core は最後にロードされたモジュールであることを示しています。
  4. fw_core_init 関数を呼んだ関数は do_one_initcall であったことを示しています。
  5. この oops メッセージが実際にカーネルパニックであり、システムがデッドロックしていることを示しています。

以上のメッセージにより、firewire_core モジュールがロードされたときの初期ルーチン中にパニックが発生したということを推測できます。(マシンのファームウェアハードウェアは、プログラマのエラーによりこのバージョンのファームウェアドライバモジュールと互換性が無いかもしれないことが推測でき、新しいリリースを待つ必要があることになります。) その間、マシンを再び走らせる最も簡単な方法は、モジュールがロードされないようにすることです。以下の方法のうち1つを取ってください:

  • モジュールが initramfs の実行中にロードされる場合、カーネルパラメータ rd.blacklist=firewire_core を設定して再起動してください。
  • それ以外の場合、カーネルパラメータ module_blacklist=firewire_core を設定して再起動してください。

再起動して root シェルに入り問題を修正する

この記事またはセクションは情報が古くなっています。
理由: initramfs の root アカウントはロックされているため、rd.rescue と rd.emergency は動作しません。 (Discuss)
この記事またはセクションの正確性には問題があります。
理由: rd.emergency ではキーボードは動作しないため、使用できません。 (議論: トーク:カーネル#)

システムに変更を加えてパニックが起こらないようにするには、root シェルが必要です。パニックが起動時に発生する場合、マシンがデッドロックする前に root シェルに入るための戦略が複数あります:

  • カーネルパラメータ emergency か rd.emergency か -b を設定して再起動する。これで、root ファイルシステムがマウントされて systemd が起動した直後にログインプロンプトが表示されます。
ノート: この時点では、root ファイルシステムは読み取り専用でマウントされます。ファイルシステムに変更を加えるには、mount -o remount,rw / を root ユーザとして実行してください。
  • カーネルパラメータ rescue、rd.rescue、single、s、S、1 のどれか設定して再起動する。これで、ローカルのファイルシステムがマウントされた直後にログインプロンプトが表示されます。
  • カーネルパラメータ systemd.debug_shell を設定して再起動する。これで、非常に初期の root シェルが tty9 で表示されます。Ctrl+Alt+F9 を押してそのシェルに切り替えてください。
  • パニックを引き起こしているカーネルの機能を無効化するために、異なるカーネルパラメータの組で再起動して実験する。"定番" の acpi=off と nolapic を試してみてください。
ヒント: すべてのカーネルパラメータは kernel-parameters.html を参照して下さい。
  • 最後の手段として、Arch Linux インストールメディアを起動し、ルートファイルシステムを /mnt にマウントし、arch-chroot /mnt を root ユーザとして実行する。
  • パニックを引き起こしているサービスやプログラムを無効化する。不具合のあるアップデートをロールバックする。設定の問題を修正する。
ヒント: 初期 RAM ディスクイメージが破損している場合、新しいイメージを生成する必要があるかもしれません。イメージの破損は、カーネルアップデートが中断された場合に起こる可能性があります。新しいイメージを作成する方法は、mkinitcpio#イメージ作成とアクティベーション を参照してください。

リグレッションをデバッグする

一般的なトラブルシューティング#リグレッションをデバッグする を参照してください。

linux-mainlineAUR を試して、その問題が既に上流で修正されているかどうかを確認してください。ピン留めされたコメントは既にビルドされたカーネルを含むリポジトリにも言及しているので、時間がかかる手動でのビルドは必要ないかもしれません。

最近発生しなかった問題をデバッグするために LTS カーネル (linux-lts) を試してみることも検討する価値があるかもしれません。LTS カーネルの古いバージョンは Arch Linux Archive で見つけることができます。

それでも問題が解決しないときは、linux-gitAUR を bisect してください。そして、kernel bugzilla でバグを報告してください。パッチと関係ないことを確認するために、パッチなしの "バニラ"バージョンを試すことが重要です。もしパッチが問題を引き起こすなら、そのパッチの作者に報告してください。

ノート: カーネルの bisect は何度も作り直さなければならないので、かなりの時間がかかるかもしれません。

より小さなカーネルを構築する

modprobed-db か make localmodconfig を使って、ローカルシステムに必要なモジュールだけをビルドしたり、によってカーネルビルド時間を短縮したりできます。もちろん、ネットワークの問題をデバッグするために、サウンドドライバなど、無関係なドライバを完全に削除することも可能です。

参照

翻訳ステータス: このページは en:Kernel の翻訳バージョンです。最後の翻訳日は 2024-10-10 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。
「https://wiki.archlinux.jp/index.php?title=カーネル&oldid=39163」から取得