カーネル
Wikipedia によると:
- Linux カーネルとは、モノリシックで Unix ライクなオープンソースのコンピュータオペレーティングシステムカーネルである。
Arch Linux は Linux カーネルをベースにしています。Arch Linux では最新の安定版カーネルに加え、様々な代替 Linux カーネルを利用することができます。この記事では、リポジトリで利用可能な選択肢のいくつかを、それぞれの簡単な説明とともにリストアップしています。また、システムのカーネルに適用できるパッチについての説明もあります。記事の最後には、カスタムカーネルのコンパイルについての概要と、様々な方法へのリンクがあります。
カーネルのパッケージは /usr/lib/modules/
にインストールされます。その後、パッケージは vmlinuz 実行可能イメージを生成するために使用され、生成されたイメージは /boot/
へ保存されます。[1] 異なるカーネルをインストールしたり、複数のカーネルを切り替えたりする場合は、変更を反映させるためにブートローダーを設定しなければなりません。
目次
公式サポートカーネル
公式にサポートされているカーネルについては、フォーラムでのコミュニティサポートとバグレポートを利用できます。
- Stable — kernel.orgのカーネルにいくつかのパッチを適用した、Arch独自のカーネル。バージョン4.17.11-1以降、Archのカーネルはもはやバニラカーネルではありません。
- Hardened — カーネルおよびユーザ空間の脆弱性を緩和するための一連の堅牢化パッチを適用した、セキュリティ特化の Linux カーネルです。また、linux よりも多くの上流のカーネル堅牢化機能を有効にします。
- Longterm — 長期サポート (LTS) Linux カーネルおよびモジュール
- リアルタイムカーネル — IngoMolnar が率いるコア開発者の小グループによって維持されています。このパッチを使用すると、コードのいくつかの非常に小さな領域("raw_spinlock クリティカル領域")を除いて、ほぼすべてのカーネルをプリエンプトできます。これは、ほとんどのカーネルスピンロックを優先度継承をサポートするミューテックスに置き換え、すべての割り込みとソフトウェア割り込みをカーネルスレッドに移動することによって行われます。
- Zen Kernel — カーネルハッカーの共同作業により、日常的なシステムに最適な Linux カーネルです。より詳細な情報は https://liquorix.net (Zen をベースにした Debian 用のカーネルバイナリを提供) で見ることができます。
コンパイル
次の方法を使って、独自のカーネルをコンパイルできます。
- Arch Build System
- 既存の linux PKGBUILD の高い品質とパッケージ管理の利点を生かします。
- 伝統的な方法
- 手動でソースの tarball をダウンロードし、ホームディレクトリで通常のユーザーとしてコンパイルする必要があります。
リストにあるパッケージの中には、非公式ユーザーリポジトリからバイナリパッケージを入手できるものもあります。
kernel.org カーネル
- Git — Linus Torvalds の git リポジトリから得たソースを使ってビルドする Linux カーネルとモジュール。
- Mainline — すべての新機能が導入されるカーネル、2〜3ヶ月ごとにリリースされます。
- Next — 次の Mainline リリースにマージされる予定の機能を持つ最先端のカーネル。
- DRM — 最先端の GPU ドライバ付き Linux カーネル。
- Longterm 4.14 — 長期サポート (LTS) Linux 4.14 カーネルとモジュール。
- Longterm 4.19 — 長期サポート (LTS) Linux 4.19 カーネルとモジュール。
- Longterm 5.4 — 長期サポート (LTS) Linux 5.4 カーネルとモジュール。
- Longterm 5.10 — 長期サポート (LTS) Linux 5.10 カーネルとモジュール。
- Longterm 5.15 — 長期サポート (LTS) Linux 5.15 カーネルとモジュール。
非公式カーネル
- Ck — デスクトップに特に重点を置いてシステムの応答性を向上させるように設計された Con Kolivas (MuQSS scheduler を含む) によるパッチが含まれていますが、どのような使用目的でも問題なく使えます。
- Clear — Intel の Clear Linux プロジェクトからのパッチ、パフォーマンスとセキュリティの最適化を提供します。
- GalliumOS — Chromebook 用の GalliumOS パッチを備えたモジュールと Linux カーネル。
- Liquorix — Debian をターゲットとした設定と Zen カーネルソースを使用して構築されたカーネル代替品。デスクトップ、マルチメディア、ゲームなどのワークロード向けに設計されており、Debian Linux の性能代替カーネルとしてよく利用されます。Liquorix パッチセットのメンテナである Damentz は、同様に Zen パッチセットの開発者でもあります。
- pf-kernel — カーネルメインラインにマージされない、ほんの少しの素晴らしい機能を提供します。カーネルエンジニアによって管理されています。新しいカーネルのための含まれるパッチのポートが公式にリリースされていない場合、パッチセットは新しいカーネルへのパッチポートを提供し、サポートします。linux-pf の現在の代表的なパッチは、PDS CPU スケジューラと UKSM です。
- https://pfkernel.natalenko.name || パッケージ:
- pf-kernel の開発者 post-factum によるリポジトリ
- pf-kernel のフォークの開発者 Thaodan によるリポジトリ、linux-pfAUR
- yurikoles による linux-pf-gitAUR と linux-pf-stable-gitAUR
- Project C — Alfred Chen 氏の Project C パッチセット (BMQ スケジューラと PDS スケジューラ) を当てたカーネル。
- Nitrous — Skylake 及びそれ以降に対して最適化された修正版 Linux カーネル。
- 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 パススルーを実行できるようになります。
- XanMod — 高性能ワークステーション、ゲーミングデスクトップ、メディアセンターなどで最大限に活用されることを目指し、より強固で応答性の高い、スムーズなデスクトップ体験を提供するために構築されています。このカーネルは、MuQSS またはタスクタイプスケジューラ、BFQ I/O スケジューラ、UKSM リアルタイムメモリーデータ重複排除、TCP BBR 輻輳制御、x86_64 高度命令セットサポート、および他のデフォルト値を変更しています。
- https://xanmod.org/ || linux-xanmodAUR, linux-xanmod-ltsAUR, linux-xanmod-rtAUR
トラブルシューティング
カーネルパニック
Linux カーネルが回復不能な障害状態になると、カーネルパニックが発生します。典型的にこの状態はバグのあるハードウェアドライバーが原因で、マシンがデッドロック状態になり、応答しなくなり、再起動が必要になります。デッドロックの直前に、診断メッセージが生成されます。これは、障害が発生したときのマシン状態、障害を検出したカーネルの関数までの 呼び出しトレース、および現在ロードされているモジュールのリストです。ありがたいことに、カーネルのメインラインバージョン (公式リポジトリで提供されているものなど) を使用してカーネルパニックが発生することはあまりありませんが、発生した場合に備えて対処方法を知る必要があります。
パニックメッセージの検証
カーネルパニックがブートプロセスの非常に早い段階で発生する場合、コンソール上に "Kernel panic - not syncing:" というメッセージが表示されることがありますが、Systemd が実行し始めると、通常カーネルメッセージはキャプチャされシステムのログに書き込まれます。しかし、パニックが発生した際には、カーネルによる診断メッセージ出力はほとんどの場合ディスク上のログファイルに書き込まれません。system-journald
がメッセージを取得・記録する前にマシンがデッドロックしてしまうからです。なので、パニックメッセージを検証する唯一の手段は、(kdump crashkernel を設定することなく)パニックの発生時にメッセージをコンソール上で見ることです。以下のカーネルパラメータを渡して起動し、tty1 でパニックの再現を試みてください:
systemd.journald.forward_to_console=1 console=tty1
例: 不良モジュール
診断メッセージの情報を使って、何のサブシステムやモジュールがパニックを引き起こしているかを推測できます。この例では、とある架空のマシンで起動中にパニックが発生してしまいました。太字で強調した行に注目してください。
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
- パニックを引き起こしたエラーの種類を示しています。この場合、プログラマのバグです。
- モジュール firewire_core 内の fw_core_init という関数でパニックが発生したことを示しています。
- firewire_core は最後にロードされたモジュールであることを示しています。
- fw_core_init 関数を呼んだ関数は do_one_initcall であったことを示しています。
- この oops メッセージが実際にカーネルパニックであり、システムがデッドロックしていることを示しています。
以上のメッセージにより、firewire_core モジュールがロードされたときの初期ルーチン中にパニックが発生したということを推測できます。(マシンのファームウェアハードウェアは、プログラマのエラーによりこのバージョンのファームウェアドライバモジュールと互換性が無いかもしれないことが推測でき、新しいリリースを待つ必要があることになります。) その間、マシンを再び走らせる最も簡単な方法は、モジュールがロードされないようにすることです。以下の方法のうち1つを取ってください:
- モジュールが initramfs の実行中にロードされる場合、カーネルパラメータ
rd.blacklist=firewire_core
を設定して再起動してください。 - それ以外の場合、カーネルパラメータ
module_blacklist=firewire_core
を設定して再起動してください。
再起動して root シェルに入り問題を修正する
システムに変更を加えてパニックが起こらないようにするには、root シェルが必要です。パニックが起動時に発生する場合、マシンがデッドロックする前に root シェルに入るための戦略が複数あります:
- カーネルパラメータ
emergency
かrd.emergency
か-b
を設定して再起動する。これで、root ファイルシステムがマウントされてsystemd
が起動した直後にログインプロンプトが表示されます。
- カーネルパラメータ
rescue
、rd.rescue
、single
、s
、S
、1
のどれか設定して再起動する。これで、ローカルのファイルシステムがマウントされた直後にログインプロンプトが表示されます。 - カーネルパラメータ
systemd.debug_shell
を設定して再起動する。これで、非常に初期の root シェルが tty9 で表示されます。Ctrl+Alt+F9
を押してそのシェルに切り替えてください。 - パニックを引き起こしているカーネルの機能を無効化するために、異なるカーネルパラメータの組で再起動して実験する。「定番」の
acpi=off
とnolapic
を試してみてください。
- 最後の手段として、Arch Linux インストールメディアを起動し、ルートファイルシステムを
/mnt
にマウントし、arch-chroot /mnt
を root ユーザとして実行する。 - パニックを引き起こしているサービスやプログラムを無効化する。不具合のあるアップデートをロールバックする。設定の問題を修正する。
リグレッションをデバッグする
一般的なトラブルシューティング#リグレッションをデバッグする を参照してください。
linux-mainlineAUR を試して、その問題が既に上流で修正されているかどうかを確認してください。ピン留めされたコメントは既にビルドされたカーネルを含むリポジトリにも言及しているので、時間がかかる手動でのビルドは必要ないかもしれません。
最近発生しなかった問題をデバッグするために LTS カーネル (linux-lts) を試してみることも検討する価値があるかもしれません。LTS カーネルの古いバージョンは Arch Linux Archive で見つけることができます。
それでも問題が解決しないときは、linux-gitAUR を bisect してください。そして、kernel bugzilla でバグを報告してください。パッチと関係ないことを確認するために、パッチなしの「バニラ」バージョンを試すことが重要です。もしパッチが問題を引き起こすなら、そのパッチの作者に報告してください。
参照
- O'Reilly - Linux Kernel in a Nutshell (フリーの電子書籍)
- What stable kernel should I use? by Greg Kroah-Hartman
- Linux カーネルのドキュメント