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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(ページの作成:「Category:カーネル cs:Kernel Compilation en:Kernels es:Kernel Compilation it:Kernels zh-CN:Kernels {{Related articles start (日本語)}} {{Rel...」)
 
 
(9人の利用者による、間の110版が非表示)
1行目: 1行目:
 
[[Category:カーネル]]
  
[[Category:カーネル]]
  +
[[Category:ソフトウェア一覧]]
−
[[cs:Kernel Compilation]]
  
−
[[en:Kernels]]
 +
[[bs:Kernel]]
−
[[es:Kernel Compilation]]
 +
[[en:Kernel]]
−
[[it:Kernels]]
 +
[[fr:Kernel]]
−
[[zh-CN:Kernels]]
 +
[[pt:Kernel]]
  +
[[ru:Kernel]]
−
{{Related articles start (日本語)}}
  
  +
[[zh-hans:Kernel]]
  +
{{Related articles start}}
 
{{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) の中核となる部分である。アプリケーションとハードウェアレベルでの実際のデータ処理との間の架け橋である。システムのリソースを管理し、ハードウェアとソフトウェアコンポーネントのやりとりを管理する。''
  
   
−
メインラインの 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-lts}}
  
−
:[core] リポジトリにある長期サポート版 (Long term support, LTS) の Linux カーネルとモジュール。
  
   
  +
公式にサポートされているカーネルについては、[https://bbs.archlinux.org/viewforum.php?id=22 フォーラム]でのコミュニティサポートと[[バグ報告ガイドライン|バグレポート]]を利用できます。
−
;{{Pkg|linux-grsec}}
  
−
:セキュリティを高めるための [[Grsecurity (日本語)|Grsecurity パッチセット]]と PaX パッチがあてられた Linux カーネルとモジュール。
  
   
  +
* {{App|Stable|いくつかのパッチを適用したバニラな Linux カーネル。|https://www.kernel.org/|{{Pkg|linux}}}}
−
===AUR パッケージ===
  
  +
* {{App|Hardened|カーネルおよびユーザ空間の脆弱性を緩和するための一連の堅牢化パッチを適用した、セキュリティ特化の Linux カーネルです。また、{{Pkg|linux}} よりも多くの上流のカーネル堅牢化機能を有効にします。|https://github.com/anthraxx/linux-hardened|{{Pkg|linux-hardened}}}}
−
;{{AUR|linux-aufs_friendly}}
  
−
:aufs 対応の linux カーネルとモジュール。[[Docker (日本語)|Docker]] を使用する際に有用。
 +
* {{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}}}}
  +
* {{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|linux-bfs}}
  
−
:[[Wikipedia:ja:Brain Fuck Scheduler|Brain Fuck Scheduler]] (BFS) が含まれた Linux カーネルとモジュール - BFS は Con Kolivas によって作成された、4096コア以下のデスクトップコンピュータ向けのタスクスケジューラ。任意で使える BFQ I/O スケジューラも付属。
  
   
  +
次の方法を使って、独自のカーネルをコンパイルできます。
−
;{{AUR|linux-ck}}
  
−
:Con Kolivas の ck1 パッチセットを適用した Linux カーネル。
  
−
:[[PKGBUILD (日本語)|PKGBUILD]] 内で次の追加オプションを切り替えることができます: BFQ スケジューラ, nconfig, localmodconfig, 動作中のカーネル設定の利用。
  
−
:これらのパッチはシステムのレスポンスを改善するように作られており、特にデスクトップに向きますが、どのような使用目的でも問題なく使えます。ck パッチには BFS が含まれています。
  
−
:詳しい情報とインストールの方法については [[linux-ck (日本語)|linux-ck]] を読んで下さい。
  
   
  +
; [[カーネル/Arch build system|Arch Build System]]: 既存の {{Pkg|linux}} [[PKGBUILD]] の高い品質と[[Wikipedia:Package management system|パッケージ管理]]の利点を生かします。
−
;{{AUR|linux-eee-ck}}
  
  +
; [[カーネル/伝統的なコンパイル方法|伝統的な方法]]: 手動でソースの tarball をダウンロードし、ホームディレクトリで通常のユーザーとしてコンパイルする必要があります。
−
:Asus Eee PC 701 向けの Linux カーネルとモジュール、Con Kolivas の ck1 パッチセットを使用。
  
   
  +
{{Warning|
−
;{{AUR|linux-fbcondecor}}
  
  +
* カスタムカーネルを使用すると、データの損失など、あらゆる種類の安定性と信頼性の問題が発生する可能性があります。[[バックアップ]]をとることを強くお勧めします。
−
:[[Fbsplash|fbcondecor]] をサポートした Linux カーネルとモジュール。
  
  +
* Arch Linux は [[#公式サポートカーネル]]のみを公式にサポートしています。別のカーネルを使用する場合は、サポートリクエストにその旨を記載してください。}}
   
  +
{{Tip|
−
;{{AUR|linux-mainline}}
  
  +
* システムの速度を上げる最良の方法は、まず、カーネルの設定をアーキテクチャやプロセッサの種類に合わせることです。
−
:メインラインの 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-pax}}
  
−
:セキュリティを高めるための PaX パッチがあてられた Linux カーネルとモジュール。
  
   
  +
リストにあるパッケージの中には、[[非公式ユーザーリポジトリ]]からバイナリパッケージを入手できるものもあります。
−
;{{AUR|linux-ice}}
  
−
:gentoo-sources パッチセットが適用され [[TuxOnIce]] をサポートした Linux カーネルとモジュール。
  
   
  +
=== kernel.org カーネル ===
−
;{{AUR|linux-lqx}}
  
−
:[http://liquorix.net Liquorix] はデスクトップ・マルチメディア・ゲーム用途に Debian 用の設定と ZEN カーネルソースを使ってビルドされたディストロカーネル代替です。Debian Linux ではパフォーマンス向上カーネルとしてよく使われています。Liquorix パッチセットのメンテナである Damentz は ZEN パッチセットの開発者でもあります。
  
   
  +
* {{App|Git|Linus Torvalds の git リポジトリから得たソースを使ってビルドする Linux カーネルとモジュール。|https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git|{{AUR|linux-git}}}}
−
;{{AUR|linux-lts34}}
  
  +
* {{App|Mainline|すべての新機能が導入されるカーネル、2〜3ヶ月ごとにリリースされます。|https://www.kernel.org/|{{AUR|linux-mainline}}}}
−
:Linux 3.4 長期サポート版カーネルとモジュール。
  
  +
*{{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-lts310}}
  
−
:Linux 3.10 長期サポート版カーネルとモジュール。
  
   
  +
* {{App|[[Linux-ck|Ck]]|デスクトップに特に重点を置いてシステムの応答性を向上させるように設計された Con Kolivas (MuQSS scheduler を含む) によるパッチが含まれていますが、どのような使用目的でも問題なく使えます。|http://ck.kolivas.org/|{{AUR|linux-ck}}}}
−
;{{AUR|linux-lts312}}
  
  +
* {{App|Clear|Intel の Clear Linux プロジェクトからのパッチ、パフォーマンスとセキュリティの最適化を提供します。|https://github.com/clearlinux-pkgs/linux|{{AUR|linux-clear}}}}
−
:Linux 3.12 長期サポート版カーネルとモジュール。
  
  +
* {{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}}}}
   
  +
== トラブルシューティング ==
−
;{{AUR|linux-pf}}
  
−
:pf-kernel パッチ [-ck パッチセット (BFS 含む), TuxOnIce, BFQ] と aufs3 が含まれた Linux カーネルとモジュール。
  
   
  +
=== カーネルパニック ===
−
;{{AUR|linux-zen}}
  
−
:[http://zen-kernel.org ZEN Kernel] は毎日の利用のために最高の Linux カーネルを提供するカーネルハッカーのコラボレーションによって生まれました。[https://bbs.archlinux.org/viewtopic.php?id=117157 このリポジトリ]で ZEN カーネルのビルドが得られます。
  
   
  +
Linux カーネルが回復不能な障害状態になると、''カーネルパニック''が発生します。典型的にこの状態はバグのあるハードウェアドライバーが原因で、マシンがデッドロック状態になり、応答しなくなり、再起動が必要になります。デッドロックの直前に、診断メッセージが生成されます。これは、障害が発生したときの''マシン状態''、障害を検出したカーネルの関数までの ''呼び出しトレース''、および現在ロードされているモジュールのリストです。ありがたいことに、カーネルのメインラインバージョン (公式リポジトリで提供されているものなど) を使用してカーネルパニックが発生することはあまりありませんが、発生した場合に備えて対処方法を知る必要があります。
−
;{{AUR|linux-libre}}
  
−
:"バイナリブロブ"が取り除かれた Linux カーネル。
  
   
  +
{{Note|カーネルパニックは、''oops'' または''カーネル oops'' と呼ばれることもあります。パニックと oops は両方とも障害状態の結果として発生するものですが、oops はより一般的なものであり、必ずしもマシンがデッドロックするわけではありません。問題のあるタスクを強制終了して実行を継続することで、カーネルが oops から回復できる場合があります。}}
−
;{{AUR|kernel-netbook}}
  
−
:Eee PC などの Intel Atom N270/N280/N450/N550 を使っているネットブックのための安定したカーネル。外部ハードウェア ({{AUR|broadcom-wl}}) やパッチセット (BFS + TuxOnIce + BFQ optional) が追加されています - Intel GPU においてのみ動作
  
   
  +
{{Tip|回復可能な oops で代わりにパニックを発生させることを強制するには、カーネルパラメータ {{ic|1=oops=panic}} を起動時に渡すか、{{ic|/proc/sys/kernel/panic_on_oops}} に {{ic|1}} を書き込んでください。oops リカバリによってシステムが不安定になり将来のエラーの診断が困難になることを懸念しているのであれば、これは推奨される方法です。}}
−
;{{AUR|linux-lts-tresor}}
  
−
:[https://www1.informatik.uni-erlangen.de/tresor TRESOR] が統合された、安定した LTS Linux カーネルとモジュール。
  
   
  +
==== パニックメッセージの検証 ====
−
;{{AUR|linux-git}}
  
−
:[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git Linus Torvalds の git リポジトリ] から得たソースを使ってビルドする Linux カーネルとモジュール。
  
   
  +
カーネルパニックがブートプロセスの非常に早い段階で発生する場合、コンソール上に "Kernel panic - not syncing:" というメッセージが表示されることがありますが、[[Systemd]] が実行し始めると、通常カーネルメッセージはキャプチャされシステムのログに書き込まれます。しかし、パニックが発生した際には、カーネルによる診断メッセージ出力は''ほとんどの場合''ディスク上のログファイルに書き込まれません。{{ic|system-journald}} がメッセージを取得・記録する前にマシンがデッドロックしてしまうからです。なので、パニックメッセージを検証する唯一の手段は、(''kdump crashkernel'' を設定することなく)パニックの発生時にメッセージをコンソール上で見ることです。以下のカーネルパラメータを渡して起動し、tty1 でパニックの再現を試みてください:
−
;{{AUR|linux-chromebook}}
  
−
:chromebook ハードウェアのサポートが追加された Linux カーネルとパッチ。
  
   
  +
systemd.journald.forward_to_console=1 console=tty1
−
==パッチとパッチセット==
  
   
  +
{{Tip|パニックメッセージが速くスクロールしすぎて検証できない場合、起動時にカーネルパラメータ {{ic|1=pause_on_oops=''秒数''}} を渡してみてください。}}
−
カーネルにパッチをあてる理由は様々です。パフォーマンスを向上させたり reiser4 ファイルシステムのサポートなどメインラインに含まれていない機能を使うため、というのが大多数の理由でしょう。他の理由としては、カーネルの改善がどうやってなされるのか知ってみたいという好奇心もあるかもしれません。
  
   
  +
===== 例: 不良モジュール =====
−
しかしながら、システムのスピードアップにベストな方法はまずカーネルをあなたのシステム、特にアーキテクチャとプロセッサーのタイプに適合させることだと気づくのは重要なことです。速度をアップさせるために、カスタムカーネルの（一般的なアーキテクチャ用の設定を使って）パッケージ済みのバージョンを使うのは推奨されませんし、あまり価値はありません。他の利点は、あなたが持っていない・使っていない物のサポートを含めないことで、カーネルのサイズ（そしてビルド時間）を減らすことができるということです。例えば、新しいカーネルバージョンがリリースされた時、私はいつもカーネルのコンフィグを皮切りに bluetooth, video4linux, 1000Mbit イーサネットといったサポート（マシンに必要ない機能）を削除します。このページではカーネルコンフィグのカスタマイズについては触れませんが、最初のステップとしてカーネルのビルドを行い、それからパッチセットを使ってみるのが推奨です。
  
   
  +
診断メッセージの情報を使って、何のサブシステムやモジュールがパニックを引き起こしているかを推測できます。この例では、とある架空のマシンで起動中にパニックが発生してしまいました。'''太字'''で強調した行に注目してください。
−
Arch のカーネルパッケージのコンフィグファイルを手始めとして使うこともできます。コンフィグファイルは Arch のパッケージのソースファイルに含まれています。例えば {{Pkg|linux}} のは [https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux] にリンクがあります。今現在動かしているカーネルのコンフィグファイルはファイルシステムの {{ic|/proc/config.gz}} に常に存在します。
  
   
  +
{{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}}
   
  +
# パニックを引き起こしたエラーの種類を示しています。この場合、プログラマのバグです。
−
カスタムカーネルパッケージのインストールには Arch Build System (ABS) を使います。カスタムパッケージをビルドしたことがない場合は次の記事を読んで勉強できます: [[Arch Build System (日本語)|Arch Build System]], [[Creating Packages (日本語)|Creating Packages]]。
  
  +
# モジュール ''firewire_core'' 内の ''fw_core_init'' という関数でパニックが発生したことを示しています。
  +
# ''firewire_core'' は最後にロードされたモジュールであることを示しています。
  +
# ''fw_core_init'' 関数を呼んだ関数は ''do_one_initcall'' であったことを示しています。
  +
# この ''oops'' メッセージが実際にカーネルパニックであり、システムがデッドロックしていることを示しています。
   
  +
以上のメッセージにより、''firewire_core'' モジュールがロードされたときの初期ルーチン中にパニックが発生したということを推測できます。(マシンのファームウェアハードウェアは、プログラマのエラーによりこのバージョンのファームウェアドライバモジュールと互換性が無いかもしれないことが推測でき、新しいリリースを待つ必要があることになります。) その間、マシンを再び走らせる最も簡単な方法は、モジュールがロードされないようにすることです。以下の方法のうち1つを取ってください:
−
あなたがカーネルにパッチをあてたりカスタマイズをしたことがないとしても、インストールはそこまで難しいものではなく、また、それぞれのパッチセットの PKGBUILD がフォーラムにはたくさんあります。ただし、すぐ近くのバンドワゴンに飛びつくのではなく、それぞれのパッチセットの効能を調べるところから始めるのを推奨します。そのほうがいきなりカーネルを選ぶよりもやるべきことについて多く学ぶことができるでしょう。
  
   
  +
* モジュールが ''initramfs'' の実行中にロードされる場合、[[カーネルパラメータ]] {{ic|1=rd.blacklist=firewire_core}} を設定して再起動してください。
−
[[#コンパイル]] を見て下さい。
  
  +
* それ以外の場合、カーネルパラメータ {{ic|1=module_blacklist=firewire_core}} を設定して再起動してください。
   
  +
==== 再起動して root シェルに入り問題を修正する ====
−
{{note|新しいカーネルを使うために、あなたのブートローダ (例: GRUB) のブートオプションを変更するのを忘れないで下さい。}}
  
   
  +
{{Out of date|[https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/commit/292cdf8a2f7dd7c6c7d91d2b59617391935c837c initramfs の root アカウントはロックされているため]、{{ic|rd.rescue}} と {{ic|rd.emergency}} は動作しません。}}
−
===主なパッチセット===
  
   
  +
{{Accuracy|{{ic|rd.emergency}} ではキーボードは動作しないため、使用できません。}}
−
まず初めにパッチセットは様々な人によって開発されていることに注意してください。人々の中には linux カーネルの開発に深く関わっている人もいるでしょうし、そうでないひともいるでしょう。開発者のカーネルの理解度はパッチセットの信頼性と安定性に反映されます。
  
   
  +
システムに変更を加えてパニックが起こらないようにするには、root シェルが必要です。パニックが起動時に発生する場合、マシンがデッドロックする前に root シェルに入るための戦略が複数あります:
−
また、パッチセットによっては他のパッチセットとあわせて使うと効果がないものもあります (パッチの名前にそれが示されているかもしれません)。パッチセット（とカーネルアップデート）は'''非常に'''短い間隔でリリースされ、ほとんどの場合それを完全に追いつづける価値はありません。あまり夢中にならないようにしましょう、それを趣味にするなら話は別ですが。
  
   
  +
* カーネルパラメータ {{ic|emergency}} か {{ic|rd.emergency}} か {{ic|-b}} を設定して再起動する。これで、root ファイルシステムがマウントされて {{ic|systemd}} が起動した直後にログインプロンプトが表示されます。
−
ググればもっと多くのパッチセットがあります - そのときはクォーテーションを使うのを覚えておいて下さい (例: {{ic|"-nitro"}})。そうしないと google はあなたが望む検索結果を'''表示しません'''。
  
  +
: {{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#イメージ作成とアクティベーション]] を参照してください。}}
−
{{note|This section is for '''information only''' - clearly no guarantees of stability or reliability are implied by inclusion on this page.}}
  
   
  +
=== リグレッションをデバッグする ===
−
==== -ck ====
  
   
  +
[[一般的なトラブルシューティング#リグレッションをデバッグする]] を参照してください。
−
[[linux-ck (日本語)|Linux-ck]] にはシステムのレスポンスを良くするためのパッチが含まれています。デスクトップ用途に重点が置かれていますが他の環境でも使えます。このパッチは Con Kolivas によって作成・メンテナンスされており、彼のサイトは http://users.on.net/~ckolivas/kernel/ にあります。Con はフルセットを管理していますがパッチを分けて提供もしており、使いたいものだけを追加することが可能です。
  
   
  +
{{AUR|linux-mainline}} を試して、その問題が既に上流で修正されているかどうかを確認してください。ピン留めされたコメントは既にビルドされたカーネルを含むリポジトリにも言及しているので、時間がかかる手動でのビルドは必要ないかもしれません。
−
-ck パッチは http://ck.kolivas.org/patches/3.0/ から入手できます
  
   
  +
最近発生しなかった問題をデバッグするために LTS カーネル ({{Pkg|linux-lts}}) を試してみることも検討する価値があるかもしれません。LTS カーネルの古いバージョンは [[Arch Linux Archive]] で見つけることができます。
−
====-rt====
  
   
  +
それでも問題が解決しないときは、{{AUR|linux-git}} を [[bisect]] してください。そして、[https://bugzilla.kernel.org/ kernel bugzilla] でバグを報告してください。パッチと関係ないことを確認するために、パッチなしの "バニラ"バージョンを試すことが重要です。もしパッチが問題を引き起こすなら、そのパッチの作者に報告してください。
−
このパッチセットは Ingo Molnar 率いるコアデベロッパのグループによってメンテナンスされています。このパッチを使うことでカーネルのほとんど全てをリアルタイム実行できるようになります、ただしコードの非常に小さい領域 ("raw_spinlock critical regions") は除きます。カーネルのスピンロックのほとんどを優先度継承をサポートするミューテックスに置き換え、全ての割り込みとソフトウェア割り込みをカーネルスレッドに移動することでこれを実現しています。
  
   
  +
{{Note|カーネルの bisect は何度も作り直さなければならないので、かなりの時間がかかるかもしれません。}}
−
さらに高精度タイマーも組み入れられています - パッチセットは別々にメンテナンスされています。
  
   
  +
==== より小さなカーネルを構築する ====
−
[as said from the [https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch Real-Time Linux Wiki]]
  
   
  +
[[modprobed-db]] か {{ic|make localmodconfig}} を使って、ローカルシステムに必要なモジュールだけをビルドしたり、によってカーネルビルド時間を短縮したりできます。もちろん、ネットワークの問題をデバッグするために、サウンドドライバなど、無関係なドライバを完全に削除することも可能です。
−
パッチは https://www.kernel.org/pub/linux/kernel/projects/rt/ にあります
  
   
−
====-bld====
 +
== 参照 ==
−
{{Warning|このスケジューラは開発中です。}}
  
−
BLD is best described as a O(1) CPU picking technique. Which is done by reordering CPU runqueues based on runqueue loads. In other words, it keeps the scheduler aware of the load changes, which helps scheduler to keep runqueues in an order. This technique doesn't depend on scheduler ticks. The two most simple things in this technique are: load tracking and runqueue ordering; these are relatively simpler operations. Load tracking will be done whenever a load change happens on the system and based on this load change runqueue will be ordered. So, if we have an ordered runqueue from lowest to highest, then picking the less (or even busiest) runqueue is easy. Scheduler can pick the lowest runqueue without calculation and comparison at the time of placing a task in a runqueue. And while trying to distribute load at sched_exec and sched_fork our best choice is to pick the lowest busiest runqueue of the system. And in this way, system remains balanced without doing any load balancing. At the time of try_to_wake_up picking the idlest runqueue is topmost priority but it has been done as per domain basis to utilize CPU cache properly and it's an area where more concentration is requires.
  
   
  +
* [http://www.kroah.com/lkn/ O'Reilly - Linux Kernel in a Nutshell] (フリーの電子書籍)
−
Google Code ウェブページ: https://code.google.com/p/bld/
  
  +
* [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-02-22|800238}}
−
====-grsecurity====
  
−  
−
[[Grsecurity (日本語)|Grsecurity]] はセキュリティに焦点を置いたパッチセットです。ロールベースアクセス制御など様々なセキュリティに関係する機能を追加し PaX プロジェクトの機能を利用します。デスクトップでも使うことはできますが公開サーバーでの利用が一番意味があるでしょう。アプリケーションによってはこのパッチセットで実装されている追加のセキュリティ対策と互換性がないことがあります。そうした問題が起こる場合は、セキュリティレベルを低くしてみて下さい。
  
−  
−
-grsecurity パッチは https://grsecurity.net から入手できます
  
−  
−
====Tiny-Patches====
  
−
[http://elinux.org/Linux_Tiny Linux Tiny] の目標はメモリやディスクの使用量を減らし、小さなシステムで動作するのを助ける機能を追加することです。組み込みシステムの開発者や 386 など小さい・古いマシンのユーザーを対象にしています。
  
−  
−
メインストリームの Linux カーネルに対するパッチリリースは止まっています。開発者達は少数のパッチに力を注ぎメインラインカーネルにパッチをマージさせることに時間を割くことを選んだようです。
  
−  
−
====-pf====
  
−
{{AUR|linux-pf}} は非公式の Linux カーネルのフォークで、メインラインにマージされていないひと握りの素敵な機能を提供します。既存の Linux フォークやパッチセットには基づいていませんが、必要なパッチが公式にリリースされていない場合に非公式のポートが使われることもあります。
  
−
linux-pf の特徴的なパッチとして TuxOnIce, CK パッチセット (特に BFS), AUFS3, LinuxIMQ, l7 フィルタ, BFQ があります。
  
−  
−
===個々のパッチ===
  
−  
−
以下のパッチはバニラカーネルのビルドに含めたり、他のパッチセットに組み入れることができます。
  
−  
−
====Reiser4====
  
−  
−
[[Reiser4]]
  
−  
−
====fbsplash====
  
−
[[fbsplash]]
  
−  
−
== コンパイル ==
  
−
Arch Linux ではカーネルコンパイルに複数の方法があります。
  
−  
−
=== Arch Build System を使う ===
  
−
[[Arch Build System (日本語)|Arch Build System]] の利用には既存の {{Pkg|linux}} の [[PKGBUILD (日本語)|PKGBUILD]] と[[Wikipedia:ja:パッケージ管理システム|パッケージ管理システム]]を使えるというアドバンテージがあります。PKGBUILD があるので、ソースがダウンロードされた後、ビルドを止めてカーネルを設定することができます。
  
−  
−
[[Kernels/Compilation/Arch Build System (日本語)|Kernels/Compilation/Arch Build System]] を見て下さい。
  
−  
−
=== 伝統的な方法 ===
  
−
手動でソース tarball をダウンロードし、標準ユーザーとして home ディレクトリでビルドを行います。設定を行った後、コンパイル・インストールする方法は2つあります; 伝統的に手動で行うか [[Makepkg (日本語)|makepkg]] + [[pacman (日本語)|pacman]] を使うかです。
  
−  
−
伝統的な方法のメリットは、他の Linux ディストリビューションでもカーネルを動作させることができることです。
  
−  
−
[[Kernels/Compilation/Traditional (日本語)|Kernels/Compilation/Traditional]] を見て下さい。
  
−  
−
===プロプライエタリの NVIDIA ドライバ===
  
−
カスタムカーネルと一緒にプロプライエタリの NVIDIA ドライバを使う方法は [[NVIDIA (日本語)#Alternate install: カスタムカーネル|NVIDIA#Alternate install: カスタムカーネル]] を見て下さい。
  
−  
−
== 参照 ==
  
−
*[http://www.kroah.com/lkn/ O'Reilly - Linux Kernel in a Nutshell] (フリーの電子書籍)
  

2024年3月14日 (木) 00:54時点における最新版

関連記事

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

ノート: カーネルパニックは、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-02-22 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。
「https://wiki.archlinux.jp/index.php?title=カーネル&oldid=36538」から取得