「カーネル」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(Pkg/AUR テンプレートの更新)
(→‎公式サポートカーネル: テンプレートエラーを修正)
 
(9人の利用者による、間の97版が非表示)
1行目: 1行目:
 
[[Category:カーネル]]
 
[[Category:カーネル]]
  +
[[Category:ソフトウェア一覧]]
[[cs:Kernel Compilation]]
 
[[en:Kernels]]
+
[[bs:Kernel]]
[[es:Kernels]]
+
[[en:Kernel]]
[[it:Kernels]]
+
[[fr:Kernel]]
[[ru:Kernels]]
+
[[pt:Kernel]]
[[zh-hans:Kernels]]
+
[[ru:Kernel]]
  +
[[zh-hans:Kernel]]
 
{{Related articles start}}
 
{{Related articles start}}
 
{{Related|カーネルモジュール}}
 
{{Related|カーネルモジュール}}
 
{{Related|カーネルモジュールのコンパイル}}
 
{{Related|カーネルモジュールのコンパイル}}
{{Related|カーネルパニック}}
 
{{Related|Linux-ck}}
 
 
{{Related|sysctl}}
 
{{Related|sysctl}}
 
{{Related articles end}}
 
{{Related articles end}}
   
[[Wikipedia:ja:カーネル|Wikipedia]]:
+
Wikipedia ると:
  +
:[[Wikipedia:ja:Linuxカーネル|Linux カーネル]]とは、モノリシックで Unix ライクなオープンソースのコンピュータ[[Wikipedia:ja:カーネル|オペレーティングシステムカーネル]]である。
:''カーネルは、階層型に設計されたオペレーティングシステム (OS) の中核となる部分である。アプリケーションとハードウェアレベルでの実際のデータ処理との間の架け橋である。システムのリソースを管理し、ハードウェアとソフトウェアコンポーネントのやりとりを管理する。''
 
   
メインラインの [[Wikipedia:ja:Linuxカーネル|Linux カーネル]]加えArch Linux では様々なカーネルを使うことができます。リポジトリから利用できるカーネル一部と、それぞれの簡単な説明をこのページでリストアップしています。また、システムのカーネルに適用することができるパッチの説明も記述します。記事の最後にはカスタムカーネルのコンパイルの概要とリンクが付してあります。
+
[[Arch Linux]] は Linux カーネルをベースいます。Arch Linux では最新の安定版カーネルに加え、様々な代替 Linux カーネルを利用することができます。この記事では、リポジトリ利用可能な選択肢いくつかを、それぞれの簡単な説明とともにリストアップしています。また、システムのカーネルに適用できるパッチについての説明もあります。記事の最後にはカスタムカーネルのコンパイルについての概要と、様々な方法へのリンクがあります。
   
  +
カーネルのパッケージは {{ic|/usr/lib/modules/}} に[[インストール]]されます。その後、パッケージは [[Wikipedia:ja:vmlinuz|vmlinuz]] 実行可能イメージを生成するために使用され、生成されたイメージは {{ic|/boot/}} へ保存されます。[https://archlinux.org/news/new-kernel-packages-and-mkinitcpio-hooks/] 異なるカーネルをインストールしたり、複数のカーネルを切り替えたりする場合は、変更を反映させるために[[ブートローダー]]を設定しなければなりません。
==公式パッケージ==
 
;{{Pkg|linux}}
 
:[core] リポジトリにある Linux カーネルとモジュール。バニラカーネル(素のカーネル)に[https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux 多少のパッチが適用されています]。
 
   
  +
== 公式サポートカーネル ==
;{{Pkg|linux-hardened}}
 
:カーネルやユーザースペースに対する脆弱性攻撃から防護する [https://github.com/thestinger/linux-hardened ハードニングパッチセット] が適用されたセキュリティ指向 Linux カーネル。ユーザー名前空間 (非特権による使用はパッチで無効化済み) や audit、あるいは [[SELinux]] など標準の {{Pkg|linux}} には含まれていないカーネルの堅牢化機能も有効になっています。
 
   
  +
公式にサポートされているカーネルについては、[https://bbs.archlinux.org/viewforum.php?id=22 フォーラム]でのコミュニティサポートと[[バグ報告ガイドライン|バグレポート]]を利用できます。
;{{Pkg|linux-lts}}
 
:[core] リポジトリにある長期サポート版 (Long term support, LTS) の Linux カーネルとモジュール。
 
   
  +
* {{App|Stable|いくつかのパッチを適用したバニラな Linux カーネル。|https://www.kernel.org/|{{Pkg|linux}}}}
;{{Pkg|linux-zen}}
 
  +
* {{App|Hardened|カーネルおよびユーザ空間の脆弱性を緩和するための一連の堅牢化パッチを適用した、セキュリティ特化の Linux カーネルです。また、{{Pkg|linux}} よりも多くの上流のカーネル堅牢化機能を有効にします。|https://github.com/anthraxx/linux-hardened|{{Pkg|linux-hardened}}}}
:[https://github.com/zen-kernel/zen-kernel ZEN Kernel] はカーネルハッカーたちの知恵の結晶です。日常的な利用にうってつけの最高の Linux カーネルになります。
 
  +
* {{App|Longterm|サーバーでの使用を対象にしたコンフィグオプションが含まれている、長期サポート (LTS) Linux カーネルおよびモジュール。|https://www.kernel.org/|{{Pkg|linux-lts}}}}
  +
* {{App|[[リアルタイムカーネル]]|IngoMolnar が率いるコア開発者の小グループによって維持されています。このパッチを使用すると、コードのいくつかの非常に小さな領域("raw_spinlock クリティカル領域")を除いて、ほぼすべてのカーネルをプリエンプトできます。これは、ほとんどのカーネルスピンロックを優先度継承をサポートするミューテックスに置き換え、すべての割り込みとソフトウェア割り込みをカーネルスレッドに移動することによって行われます。|https://wiki.linuxfoundation.org/realtime/start|{{Pkg|linux-rt}}, {{Pkg|linux-rt-lts}}}}
  +
: {{Note|1=リアルタイムカーネルサポートは [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=baeb9a7d8b60b021d907127509c44507539c15e5 Linux 6.12] にマージされました。}}
  +
* {{App|Zen Kernel|カーネルハッカーの共同作業により、日常的なシステムに最適な Linux カーネルです。より詳細な情報は [https://github.com/zen-kernel/zen-kernel/wiki/FAQ FAQ] と [https://github.com/zen-kernel/zen-kernel/wiki/Detailed-Feature-List Detailed Feature List] を参照してください。|https://github.com/zen-kernel/zen-kernel|{{Pkg|linux-zen}}}}
   
==AURッケージ==
+
== コンイル ==
;{{AUR|linux-aufs_friendly}}
 
:aufs 対応の linux カーネルとモジュール。[[Docker]] を使用する際に有用。
 
   
  +
次の方法を使って、独自のカーネルをコンパイルできます。
;{{AUR|linux-ck}}
 
:Con Kolivas の ck1 パッチセットを適用した Linux カーネル。
 
:[[PKGBUILD]] 内で次の追加オプションを切り替えることができます: BFQ スケジューラ, nconfig, localmodconfig, 動作中のカーネル設定の利用。
 
:これらのパッチはシステムのレスポンスを改善するように作られており、特にデスクトップに向きますが、どのような使用目的でも問題なく使えます。ck パッチには BFS が含まれています。
 
:詳しい情報とインストールの方法については [[linux-ck]] を読んで下さい。
 
   
  +
; [[カーネル/Arch build system|Arch Build System]]: 既存の {{Pkg|linux}} [[PKGBUILD]] の高い品質と[[Wikipedia:Package management system|パッケージ管理]]の利点を生かします。
;{{AUR|linux-git}}
 
  +
; [[カーネル/伝統的なコンパイル方法|伝統的な方法]]: 手動でソースの tarball をダウンロードし、ホームディレクトリで通常のユーザーとしてコンパイルする必要があります。
:[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git Linus Torvalds の git リポジトリ] から得たソースを使ってビルドする Linux カーネルとモジュール。
 
   
  +
{{Warning|
;{{AUR|linux-kpatch}}{{Broken package link|パッケージが存在しません}}
 
  +
* カスタムカーネルを使用すると、データの損失など、あらゆる種類の安定性と信頼性の問題が発生する可能性があります。[[バックアップ]]をとることを強くお勧めします。
:[[カーネルライブパッチ]]をサポートする Linux カーネル。
 
  +
* Arch Linux は [[#公式サポートカーネル]]のみを公式にサポートしています。別のカーネルを使用する場合は、サポートリクエストにその旨を記載してください。}}
   
  +
{{Tip|
;{{AUR|linux-libre}}
 
  +
* システムの速度を上げる最良の方法は、まず、カーネルの設定をアーキテクチャやプロセッサの種類に合わせることです。
:"バイナリブロブ"が取り除かれた Linux カーネル。
 
  +
* 自分が持っていないもの、使っていないもののサポートを含まないようにすることで、カーネルのサイズ (つまりビルド時間) を小さくすることができます。例えば、Bluetooth、video4linux、1000Mbit イーサネットなどのサポートです。
   
  +
Arch のカーネルパッケージ設定ファイルは Arch のパッケージのソースファイルに含まれています。例えば {{Pkg|linux}} の場合 [https://gitlab.archlinux.org/archlinux/packaging/packages/linux] にリンクがあります。今現在動かしているカーネルのコンフィグファイルはファイルシステムの {{ic|/proc/config.gz}} に存在します (カーネルオプションの {{ic|CONFIG_IKCONFIG_PROC}} が有効になっている場合。)}}
;{{AUR|linux-lqx}}
 
:[http://liquorix.net Liquorix] はデスクトップ・マルチメディア・ゲーム用途に Debian 用の設定と ZEN カーネルソースを使ってビルドされたディストロカーネル代替です。Debian Linux ではパフォーマンス向上カーネルとしてよく使われています。Liquorix パッチセットのメンテナである Damentz は ZEN パッチセットの開発者でもあります。
 
   
  +
リストにあるパッケージの中には、[[非公式ユーザーリポジトリ]]からバイナリパッケージを入手できるものもあります。
;{{AUR|linux-lts310}}{{Broken package link|パッケージが存在しません}}
 
:Linux 3.10 長期サポート版カーネルとモジュール。
 
   
  +
=== kernel.org カーネル ===
;{{AUR|linux-lts316}}
 
:Linux 3.16 長期サポート版カーネルとモジュール。
 
   
  +
* {{App|Git|Linus Torvalds の git リポジトリから得たソースを使ってビルドする Linux カーネルとモジュール。|https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git|{{AUR|linux-git}}}}
;{{AUR|linux-mainline}}
 
  +
* {{App|Mainline|すべての新機能が導入されるカーネル、2〜3ヶ月ごとにリリースされます。|https://www.kernel.org/|{{AUR|linux-mainline}}}}
:メインラインの Linux カーネルとモジュール。
 
  +
*{{App|Next|次の Mainline リリースにマージされる予定の機能を持つ最先端のカーネル。|https://www.kernel.org/doc/man-pages/linux-next.html|{{AUR|linux-next-git}}}}
  +
* {{App|DRM|最先端の GPU ドライバ付き Linux カーネル。|https://cgit.freedesktop.org/drm/|{{AUR|linux-drm-tip-git}}, {{AUR|linux-drm-next-git}}}}
  +
* {{App|Longterm 4.19|長期サポート (LTS) Linux 4.19 カーネルとモジュール。|https://www.kernel.org/|{{AUR|linux-lts419}}}}
  +
* {{App|Longterm 5.4|長期サポート (LTS) Linux 5.4 カーネルとモジュール。|https://www.kernel.org/|{{AUR|linux-lts54}}}}
  +
* {{App|Longterm 5.10|長期サポート (LTS) Linux 5.10 カーネルとモジュール。|https://www.kernel.org/|{{AUR|linux-lts510}}}}
  +
* {{App|Longterm 5.15|長期サポート (LTS) Linux 5.15 カーネルとモジュール。|https://www.kernel.org/|{{AUR|linux-lts515}}}}
  +
* {{App|Longterm 6.1|長期サポート (LTS) Linux 6.1 カーネルとモジュール。|https://www.kernel.org/|{{AUR|linux-lts61}}}}
   
  +
=== 非公式カーネル ===
;{{AUR|linux-mptcp}}
 
:[http://multipath-tcp.org/ Multipath TCP] に対応する Linux カーネルとモジュール。
 
   
  +
* {{App|[[Linux-ck|Ck]]|デスクトップに特に重点を置いてシステムの応答性を向上させるように設計された Con Kolivas (MuQSS scheduler を含む) によるパッチが含まれていますが、どのような使用目的でも問題なく使えます。|http://ck.kolivas.org/|{{AUR|linux-ck}}}}
;{{AUR|linux-pf}}
 
  +
* {{App|Clear|Intel の Clear Linux プロジェクトからのパッチ、パフォーマンスとセキュリティの最適化を提供します。|https://github.com/clearlinux-pkgs/linux|{{AUR|linux-clear}}}}
:pf-kernel パッチ [-ck パッチセット (BFS 含む), TuxOnIce, BFQ] と aufs3 が含まれた Linux カーネルとモジュール。
 
  +
* {{App|[[Wikipedia:Linux-libre|Libre]]|[[Wikipedia:ja:難読化 (ソフトウェア)|難読化された]]デバイスドライバや[[Wikipedia:ja:バイナリ・ブロブ|プロプライエタリ]]のデバイスドライバーを使用しません。|https://www.fsfla.org/ikiwiki/selibre/linux-libre/|{{AUR|linux-libre}}}}
  +
* {{App|Liquorix|Debian をターゲットとした設定と Zen カーネルソースを使用して構築されたカーネル代替品。デスクトップ、マルチメディア、ゲームなどのワークロード向けに設計されており、Debian Linux の性能代替カーネルとしてよく利用されます。Liquorix パッチセットのメンテナである Damentz は、同様に Zen パッチセットの開発者でもあります。|https://liquorix.net|{{AUR|linux-lqx}}}}
  +
* {{App|pf-kernel|カーネルメインラインにマージされない、ほんの少しの素晴らしい機能を提供します。カーネルエンジニアによって管理されています。新しいカーネルのための含まれるパッチのポートが公式にリリースされていない場合、パッチセットは新しいカーネルへのパッチポートを提供し、サポートします。linux-pf の現在の最も代表的なパッチは、UKSM、DDCCI、v4l2loopback、そして BBRv3 です。|https://pfkernel.natalenko.name|パッケージ:}}
  +
:* [[非公式ユーザーリポジトリ#post-factum kernels|リポジトリ]]: pf-kernel の開発者 [https://aur.archlinux.org/account/post-factum post-factum] による {{AUR|linux-pf}}
  +
* {{App|Project C|Alfred Chen 氏の Project C パッチセット (BMQ スケジューラと PDS スケジューラ) を当てたカーネル。|https://gitlab.com/alfredchen/projectc|{{AUR|linux-prjc}}}}
  +
* {{App|Nitrous|Skylake 及びそれ以降に対して最適化された修正版 Linux カーネル。|https://gitlab.com/xdevs23/linux-nitrous|{{AUR|linux-nitrous}}}}
  +
* {{App|tkg|デスクトップやゲームのパフォーマンスを向上させるためのパッチや調整を提供する、高度にカスタマイズ可能なカーネルビルドシステム。Etienne Juvigny によってメンテナンスされています。他のパッチの中で、様々な CPU スケージューラを提供しています: CFS、Project C PDS、Project C BMQ、MuQSS、CacULE。|https://github.com/Frogging-Family/linux-tkg|[[非公式ユーザーリポジトリ#chaotic-aur|chaotic-aur]] リポジトリで利用可能}}
  +
* {{App|VFIO|Alex Williamson によって作成されたいくつかのパッチ(acs オーバーライドおよび i915)により、一部のマシンで KVM を使用して PCI パススルーを実行できるようになります。|https://lwn.net/Articles/499240/|{{AUR|linux-vfio}}, {{AUR|linux-vfio-lts}}}}
  +
* {{App|XanMod|高性能ワークステーション、ゲーミングデスクトップ、メディアセンターなどで最大限に活用されることを目指し、より強固で応答性の高い、スムーズなデスクトップ体験を提供するために構築されています。このカーネルでは、BFQ I/O スケジューラ、[https://github.com/google/bbr/tree/v3 TCP BBRv3] 輻輳制御、x86_64 高度命令セットのサポート、部分的な Clear Linux パッチセットが使用されており、また一部のデフォルトも変更されています。|https://xanmod.org/|{{AUR|linux-xanmod}}, {{AUR|linux-xanmod-lts}}, {{AUR|linux-xanmod-rt}}, {{AUR|linux-xanmod-bore}}}}
  +
* {{App|linux-cachyos|Linux SCHED-EXT + BORE + CachyOS の Cachy Sauce Kernel に加え、その他のパッチや改善されたカーネルモジュールが含まれています。|https://github.com/CachyOS/linux-cachyos|{{AUR|linux-cachyos}}}}
   
  +
== トラブルシューティング ==
;{{AUR|linux-rt}}
 
:リアルタイムパッチセットがあてられた Linux カーネル。遅延を減らしてハードリアルタイムが可能になります: https://rt.wiki.kernel.org/
 
   
  +
=== カーネルパニック ===
;{{AUR|linux-vfio}}/{{AUR|linux-vfio-lts}}
 
:Alex Williamson によって書かれた KVM で PCI パススルーを出来るようにするパッチが適用された Linux カーネル (acs override と i915)。
 
   
  +
Linux カーネルが回復不能な障害状態になると、''カーネルパニック''が発生します。この状態は通常、バグのあるハードウェアドライバーが原因で、マシンがデッドロックされ、応答しなくなり、再起動が必要になります。デッドロックの直前に、診断メッセージが生成されます。これは、障害が発生したときの''マシンの状態''、障害を検出したカーネルの関数までの ''呼び出しトレース''、および現在ロードされているモジュールのリストです。ありがたいことに、カーネルのメインラインバージョン (公式リポジトリで提供されているものなど) を使用してカーネルパニックが発生することはあまりありませんが、発生した場合に備えて対処方法を知る必要があります。
==パッチとパッチセット==
 
   
  +
{{Note|カーネルパニックは、''oops'' または''カーネル oops'' と呼ばれることもあります。パニックと oops は両方とも障害状態の結果として発生するものですが、oops はより一般的なものであり、必ずしもマシンがデッドロックするわけではありません。問題のあるタスクを強制終了して実行を継続することで、カーネルが oops から回復できる場合があります。}}
カーネルにパッチをあてる理由は様々です。パフォーマンスを向上させたり reiser4 ファイルシステムのサポートなどメインラインに含まれていない機能を使うため、というのが大多数の理由でしょう。他の理由としては、カーネルの改善がどうやってなされるのか知ってみたいという好奇心もあるかもしれません。
 
   
  +
{{Tip|回復可能な oops で代わりにパニックを発生させることを強制するには、カーネルパラメータ {{ic|1=oops=panic}} を起動時に渡すか、{{ic|/proc/sys/kernel/panic_on_oops}} に {{ic|1}} を書き込んでください。oops リカバリによってシステムが不安定になり将来のエラーの診断が困難になることを懸念しているのであれば、これは推奨される方法です。}}
しかしながら、システムのスピードアップにベストな方法はまずカーネルをあなたのシステム、特にアーキテクチャとプロセッサーのタイプに適合させることだと気づくのは重要なことです。速度をアップさせるために、カスタムカーネルの(一般的なアーキテクチャ用の設定を使って)パッケージ済みのバージョンを使うのは推奨されませんし、あまり価値はありません。他の利点は、あなたが持っていない・使っていない物のサポートを含めないことで、カーネルのサイズ(そしてビルド時間)を減らすことができるということです。例えば、新しいカーネルバージョンがリリースされた時、私はいつもカーネルのコンフィグを皮切りに bluetooth, video4linux, 1000Mbit イーサネットといったサポート(マシンに必要ない機能)を削除します。このページではカーネルコンフィグのカスタマイズについては触れませんが、最初のステップとしてカーネルのビルドを行い、それからパッチセットを使ってみるのが推奨です。
 
   
  +
==== パニックメッセージの検証 ====
Arch のカーネルパッケージのコンフィグファイルを手始めとして使うこともできます。コンフィグファイルは Arch のパッケージのソースファイルに含まれています。例えば {{Pkg|linux}} のは [https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux] にリンクがあります。今現在動かしているカーネルのコンフィグファイルはファイルシステムの {{ic|/proc/config.gz}} に存在します (カーネルオプションの {{ic|CONFIG_IKCONFIG_PROC}} が有効になっている場合)。
 
   
  +
カーネルパニックがブートプロセスの非常に早い段階で発生する場合、コンソール上に "Kernel panic - not syncing:" というメッセージが表示されることがありますが、[[Systemd]] が実行し始めると、通常カーネルメッセージはキャプチャされシステムのログに書き込まれます。しかし、パニックが発生した際には、カーネルによる診断メッセージ出力は''ほとんどの場合''ディスク上のログファイルに書き込まれません。{{ic|system-journald}} がメッセージを取得・記録する前にマシンがデッドロックしてしまうからです。なので、パニックメッセージを検証する唯一の手段は、(''kdump crashkernel'' を設定することなく)パニックの発生時にメッセージをコンソール上で見ることです。以下のカーネルパラメータを渡して起動し、tty1 でパニックの再現を試みてください:
===インストール方法===
 
   
  +
systemd.journald.forward_to_console=1 console=tty1
カスタムカーネルパッケージのインストールには Arch Build System (ABS) を使います。カスタムパッケージをビルドしたことがない場合は次の記事を読んで勉強できます: [[Arch Build System]], [[パッケージの作成]]。
 
   
  +
{{Tip|パニックメッセージが速くスクロールしすぎて検証できない場合、起動時にカーネルパラメータ {{ic|1=pause_on_oops=''秒数''}} を渡してみてください。}}
あなたがカーネルにパッチをあてたりカスタマイズをしたことがないとしても、インストールはそこまで難しいものではなく、また、それぞれのパッチセットの PKGBUILD がフォーラムにはたくさんあります。ただし、すぐ近くのバンドワゴンに飛びつくのではなく、それぞれのパッチセットの効能を調べるところから始めるのを推奨します。そのほうがいきなりカーネルを選ぶよりもやるべきことについて多く学ぶことができるでしょう。
 
   
  +
===== 例: 不良モジュール =====
[[#コンパイル]] を見て下さい。
 
   
  +
診断メッセージの情報を使って、何のサブシステムやモジュールがパニックを引き起こしているかを推測できます。この例では、とある架空のマシンで起動中にパニックが発生してしまいました。'''太字'''で強調した行に注目してください。
{{note|新しいカーネルを使うために、あなたのブートローダ (例: GRUB) のブートオプションを変更するのを忘れないで下さい。}}
 
   
  +
{{bc|'''kernel: BUG: unable to handle kernel NULL pointer dereference at (null)''' <sup>1</sup>
===主なパッチセット===
 
  +
'''kernel: IP: fw_core_init+0x18/0x1000 [firewire_core]''' <sup>2</sup>
  +
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 ...''' <sup>3</sup>
  +
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''' <sup>4</sup>
  +
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''' <sup>5</sup>
  +
kernel: Kernel Offset: 0x80000000 from 0xffffffff810000000 (relocation range: 0xffffffff800000000-0xfffffffffbffffffff
  +
kernel: ---[ end Kernel panic - not syncing: Fatal exception}}
   
  +
# パニックを引き起こしたエラーの種類を示しています。この場合、プログラマのバグです。
まず初めにパッチセットは様々な人によって開発されていることに注意してください。人々の中には linux カーネルの開発に深く関わっている人もいるでしょうし、そうでないひともいるでしょう。開発者のカーネルの理解度はパッチセットの信頼性と安定性に反映されます。
 
  +
# モジュール ''firewire_core'' 内の ''fw_core_init'' という関数でパニックが発生したことを示しています。
  +
# ''firewire_core'' は最後にロードされたモジュールであることを示しています。
  +
# ''fw_core_init'' 関数を呼んだ関数は ''do_one_initcall'' であったことを示しています。
  +
# この ''oops'' メッセージが実際にカーネルパニックであり、システムがデッドロックしていることを示しています。
   
  +
以上のメッセージにより、''firewire_core'' モジュールがロードされたときの初期ルーチン中にパニックが発生したということを推測できます。(マシンのファームウェアハードウェアは、プログラマのエラーによりこのバージョンのファームウェアドライバモジュールと互換性が無いかもしれないことが推測でき、新しいリリースを待つ必要があることになります。) その間、マシンを再び走らせる最も簡単な方法は、モジュールがロードされないようにすることです。以下の方法のうち1つを取ってください:
また、パッチセットによっては他のパッチセットとあわせて使うと効果がないものもあります (パッチの名前にそれが示されているかもしれません)。パッチセット(とカーネルアップデート)は'''非常に'''短い間隔でリリースされ、ほとんどの場合それを完全に追いつづける価値はありません。あまり夢中にならないようにしましょう、それを趣味にするなら話は別ですが。
 
   
  +
* モジュールが ''initramfs'' の実行中にロードされる場合、[[カーネルパラメータ]] {{ic|1=rd.blacklist=firewire_core}} を設定して再起動してください。
ググればもっと多くのパッチセットがあります - そのときはクォーテーションを使うのを覚えておいて下さい (例: {{ic|"-nitro"}})。そうしないと google はあなたが望む検索結果を'''表示しません'''。
 
  +
* それ以外の場合、カーネルパラメータ {{ic|1=module_blacklist=firewire_core}} を設定して再起動してください。
   
  +
==== 再起動して root シェルに入り問題を修正する ====
{{note|このセクションに書かれていることに保証はありません。安定性や信頼性は担保されていないので注意してください。}}
 
   
  +
{{Out of date|[https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/commit/292cdf8a2f7dd7c6c7d91d2b59617391935c837c initramfs の root アカウントはロックされているため]、{{ic|rd.rescue}} と {{ic|rd.emergency}} は動作しません。}}
==== -ck ====
 
   
  +
{{Accuracy|{{ic|rd.emergency}} ではキーボードは動作しないため、使用できません。}}
[[linux-ck]] にはシステムのレスポンスを良くするためのパッチが含まれています。デスクトップ用途に重点が置かれていますが他の環境でも使えます。このパッチは Con Kolivas によって作成・メンテナンスされており、彼のサイトは http://users.on.net/~ckolivas/kernel/ にあります。Con はフルセットを管理していますがパッチを分けて提供もしており、使いたいものだけを追加することが可能です。
 
   
  +
システムに変更を加えてパニックが起こらないようにするには、root シェルが必要です。パニックが起動時に発生する場合、マシンがデッドロックする前に root シェルに入るための戦略が複数あります:
-ck パッチは http://users.tpg.com.au/ckolivas/kernel/ から入手できます
 
   
  +
* カーネルパラメータ {{ic|emergency}} か {{ic|rd.emergency}} か {{ic|-b}} を設定して再起動する。これで、root ファイルシステムがマウントされて {{ic|systemd}} が起動した直後にログインプロンプトが表示されます。
====-rt====
 
  +
: {{Note|この時点では、root ファイルシステムは'''読み取り専用'''でマウントされます。ファイルシステムに変更を加えるには、{{ic|mount -o remount,rw /}} を root ユーザとして実行してください。}}
  +
* カーネルパラメータ {{ic|rescue}}、{{ic|rd.rescue}}、{{ic|single}}、{{ic|s}}、{{ic|S}}、{{ic|1}} のどれか設定して再起動する。これで、ローカルのファイルシステムがマウントされた直後にログインプロンプトが表示されます。
  +
* カーネルパラメータ {{ic|1=systemd.debug_shell}} を設定して再起動する。これで、非常に初期の root シェルが tty9 で表示されます。{{ic|Ctrl+Alt+F9}} を押してそのシェルに切り替えてください。
  +
* パニックを引き起こしているカーネルの機能を無効化するために、異なるカーネルパラメータの組で再起動して実験する。"定番" の {{ic|1=acpi=off}} と {{ic|nolapic}} を試してみてください。
  +
: {{Tip|すべてのカーネルパラメータは [https://docs.kernel.org/admin-guide/kernel-parameters.html kernel-parameters.html] を参照して下さい。}}
  +
* 最後の手段として、[[インストールガイド#インストールメディアの準備|Arch Linux インストールメディア]]を起動し、ルートファイルシステムを {{ic|/mnt}} にマウントし、{{ic|arch-chroot /mnt}} を root ユーザとして実行する。
  +
* パニックを引き起こしているサービスやプログラムを無効化する。不具合のあるアップデートをロールバックする。設定の問題を修正する。
   
  +
{{Tip|[[Wikipedia:Initial ramdisk|初期 RAM ディスク]]イメージが破損している場合、新しいイメージを生成する必要があるかもしれません。イメージの破損は、カーネルアップデートが中断された場合に起こる可能性があります。新しいイメージを作成する方法は、[[mkinitcpio#イメージ作成とアクティベーション]] を参照してください。}}
このパッチセットは Ingo Molnar 率いるコアデベロッパのグループによってメンテナンスされています。このパッチを使うことでカーネルのほとんど全てをリアルタイム実行できるようになります、ただしコードの非常に小さい領域 ("raw_spinlock critical regions") は除きます。カーネルのスピンロックのほとんどを優先度継承をサポートするミューテックスに置き換え、全ての割り込みとソフトウェア割り込みをカーネルスレッドに移動することでこれを実現しています。詳しくは[[リアルタイムカーネル]]を参照してください。
 
   
  +
=== リグレッションをデバッグする ===
さらに高精度タイマーも組み入れられています - パッチセットは別々にメンテナンスされています。
 
   
  +
[[一般的なトラブルシューティング#リグレッションをデバッグする]] を参照してください。
[ソース: [https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch Real-Time Linux Wiki]]
 
   
  +
{{AUR|linux-mainline}} を試して、その問題が既に上流で修正されているかどうかを確認してください。ピン留めされたコメントは既にビルドされたカーネルを含むリポジトリにも言及しているので、時間がかかる手動でのビルドは必要ないかもしれません。
パッチは https://www.kernel.org/pub/linux/kernel/projects/rt/ にあります。
 
   
  +
最近発生しなかった問題をデバッグするために LTS カーネル ({{Pkg|linux-lts}}) を試してみることも検討する価値があるかもしれません。LTS カーネルの古いバージョンは [[Arch Linux Archive]] で見つけることができます。
====-bld====
 
{{Warning|このパッチは開発中です。}}
 
BLD は O(1) の CPU 利用技術とされます。ランキューの負担にあわせて CPU ランキューの順番を変えます。つまり、スケジューラが負担の変化に対応することで、適当な順番でランキューを動作させることが可能です。この技術はスケジューラのチェックに依存しません。この技術では最も単純な方法が取られています: 負担を追跡してランキューの順番を変更する。どちらも同じような操作です。負担の追跡はシステム上で負担の変化が起こった時に行われ、負担が変化したランキューの順番が変えられます。一番負担が低いランキューから一番負担が高いランキューまでの順番が付けられたら、一番下の (一番忙しい) ランキューを選択するのは簡単です。スケジューラはランキューにタスクを割り振るときに何も計算や比較を行うことなく一番下のランキューを選択します。そして sched_exec や sched_fork で負担を分散させるのに一番良いのは一番下の一番忙しいランキューを優先することです。これで、ロードバランシングを行わなくてもシステムのバランスが取られます。try_to_wake_up するときアイドル状態のランキューが一番優先されるようになりますが、ドメインごとに実行されるため CPU のキャッシュを正しく利用します。キャッシュの利用には更なる注意が必要になります。
 
   
  +
それでも問題が解決しないときは、{{AUR|linux-git}} を [[bisect]] してください。そして、[https://bugzilla.kernel.org/ kernel bugzilla] でバグを報告してください。パッチと関係ないことを確認するために、パッチなしの "バニラ"バージョンを試すことが重要です。もしパッチが問題を引き起こすなら、そのパッチの作者に報告してください。
Github ウェブページ: https://github.com/rmullick/bld-patches
 
   
  +
{{Note|カーネルの bisect は何度も作り直さなければならないので、かなりの時間がかかるかもしれません。}}
====Tiny-Patches====
 
[https://elinux.org/Linux_Tiny Linux Tiny] の目標はメモリやディスクの使用量を減らし、小さなシステムで動作するのを助ける機能を追加することです。組み込みシステムの開発者や 386 など小さい・古いマシンのユーザーを対象にしています。
 
   
  +
==== より小さなカーネルを構築する ====
メインストリームの Linux カーネルに対するパッチリリースは止まっています。開発者達は少数のパッチに力を注ぎメインラインカーネルにパッチをマージさせることに時間を割くことを選んだようです。
 
   
  +
[[modprobed-db]] か {{ic|make localmodconfig}} を使って、ローカルシステムに必要なモジュールだけをビルドしたり、によってカーネルビルド時間を短縮したりできます。もちろん、ネットワークの問題をデバッグするために、サウンドドライバなど、無関係なドライバを完全に削除することも可能です。
====-pf====
 
{{AUR|linux-pf}} は非公式の Linux カーネルのフォークで、メインラインにマージされていないひと握りの素敵な機能を提供します。既存の Linux フォークやパッチセットには基づいていませんが、必要なパッチが公式にリリースされていない場合に非公式のポートが使われることもあります。
 
linux-pf の特徴的なパッチとして TuxOnIce, CK パッチセット (特に BFS), AUFS3, LinuxIMQ, l7 フィルタ, BFQ があります。
 
   
  +
== 参照 ==
詳しくは [[linux-pf]] を見て下さい。
 
   
  +
* [http://www.kroah.com/lkn/ O'Reilly - Linux Kernel in a Nutshell] (フリーの電子書籍)
===個々のパッチ===
 
  +
* [http://kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/ What stable kernel should I use?] by Greg Kroah-Hartman
  +
* [https://docs.kernel.org/index.html Linux カーネルのドキュメント]
   
  +
{{TranslationStatus|Kernel|2024-10-10|818024}}
以下のパッチはバニラカーネルのビルドに含めたり、他のパッチセットに組み入れることができます:
 
 
*[[Reiser4]]
 
*[[fbsplash]]
 
 
== コンパイル ==
 
Arch Linux ではカーネルコンパイルに複数の方法があります。
 
 
=== Arch Build System を使う ===
 
[[Arch Build System]] の利用には既存の {{Pkg|linux}} の [[PKGBUILD]] と[[Wikipedia:ja:パッケージ管理システム|パッケージ管理システム]]を使えるというアドバンテージがあります。PKGBUILD があるので、ソースがダウンロードされた後、ビルドを止めてカーネルを設定することができます。
 
 
[[カーネル/コンパイル/Arch Build System]] を見て下さい。
 
 
=== 伝統的な方法 ===
 
手動でソース tarball をダウンロードし、標準ユーザーとして home ディレクトリでビルドを行います。設定を行った後、コンパイル・インストールする方法は2つあります; 伝統的に手動で行うか [[makepkg]] + [[pacman]] を使うかです。
 
 
伝統的な方法のメリットは、他の Linux ディストリビューションでもカーネルを動作させることができることです。
 
 
[[カーネル/コンパイル/伝統的な方法]]を見て下さい。
 
 
===プロプライエタリの NVIDIA ドライバ===
 
カスタムカーネルと一緒にプロプライエタリの NVIDIA ドライバを使う方法は [[NVIDIA#カスタムカーネル]]を見て下さい。
 
 
== 参照 ==
 
*[http://www.kroah.com/lkn/ O'Reilly - Linux Kernel in a Nutshell] (フリーの電子書籍)
 

2024年10月15日 (火) 17:42時点における最新版

関連記事

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 カーネルです。より詳細な情報は FAQDetailed 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_oops1 を書き込んでください。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.rescuerd.emergency は動作しません。 (Discuss)
この記事またはセクションの正確性には問題があります。
理由: rd.emergency ではキーボードは動作しないため、使用できません。 (議論: トーク:カーネル#)

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

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

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

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

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

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

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

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

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

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

参照

翻訳ステータス: このページは en:Kernel の翻訳バージョンです。最後の翻訳日は 2024-10-10 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。