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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎コンパイル: 翻訳を修正)
90行目: 90行目:
 
* {{App|Xanmod|高性能ワークステーション、ゲーミングデスクトップ、メディアセンターなどで最大限に活用されることを目指し、より強固で応答性の高い、スムーズなデスクトップ体験を提供するために構築されています。このカーネルは、MuQSS またはタスクタイプスケジューラ、BFQ I/O スケジューラ、UKSM リアルタイムメモリーデータ重複排除、[https://github.com/google/bbr TCP BBR] 輻輳制御、x86_64 高度命令セットサポート、および他のデフォルト値を変更しています。|https://xanmod.org/|{{AUR|linux-xanmod}}, {{AUR|linux-xanmod-tt}}}}
  
* {{App|Xanmod|高性能ワークステーション、ゲーミングデスクトップ、メディアセンターなどで最大限に活用されることを目指し、より強固で応答性の高い、スムーズなデスクトップ体験を提供するために構築されています。このカーネルは、MuQSS またはタスクタイプスケジューラ、BFQ I/O スケジューラ、UKSM リアルタイムメモリーデータ重複排除、[https://github.com/google/bbr TCP BBR] 輻輳制御、x86_64 高度命令セットサポート、および他のデフォルト値を変更しています。|https://xanmod.org/|{{AUR|linux-xanmod}}, {{AUR|linux-xanmod-tt}}}}
   
−
== リグレッション デバッグ ==
 +
== トラブルシューティング ==
  +
  +
=== カーネルパニック ===
  +
  +
Linux カーネルが回復不能な障害状態になると、''カーネルパニック''が発生します。この状態は通常、バグのあるハードウェアドライバーが原因で、マシンがデッドロック状態になり、応答しなくなり、再起動が必要になります。デッドロックの直前に、診断メッセージが生成されます。これは、障害が発生したときの''マシン状態''、障害を認識したカーネル機能につながる''呼び出しトレース''、および現在ロードされているモジュールのリストです。ありがたいことに、カーネルのメインラインバージョン(公式リポジトリで提供されているものなど)を使用してカーネルパニックが発生することはあまりありませんが、発生した場合は、対処方法を知る必要があります。
  +
  +
{{Note|カーネルパニックは、''oops'' または''カーネル oops'' と呼ばれることもあります。障害状態の結果としてパニックと oops の両方が発生しますが、oops はより一般的なものであり、必ずしもデッドロックされたマシンになるわけではありません。カーネルは、問題のあるタスクを強制終了して実行することで oops から回復できる場合があります。}}
  +
  +
{{Tip|回復可能な oops で代わりにパニックを発生させることを強制するには、カーネルパラメータ {{ic|1=oops=panic}} を起動時に渡すか、{{ic|/proc/sys/kernel/panic_on_oops}} に {{ic|1}} を書き込んでください。oops リカバリによってシステムが不安定になり将来のエラーの診断が困難になることを懸念しているのであれば、これは推奨される方法です。}}
  +
  +
==== パニックメッセージの検証 ====
  +
  +
カーネルパニックがブートプロセスの非常に早い段階で発生する場合、コンソール上に "Kernel panic - not syncing:" というメッセージが表示されることがありますが、[[Systemd]] が実行し始めると、通常カーネルメッセージはキャプチャされシステムのログに書き込まれます。しかし、パニックが発生した際には、カーネルによる診断メッセージ出力は''ほとんどの場合''ディスク上のログファイルに書き込まれません。{{ic|system-journald}} がメッセージを取得・記録する前にマシンがデッドロックしてしまうからです。なので、パニックメッセージを検証する唯一の手段は、(''kdump crashkernel'' を設定することなく)パニックの発生時にメッセージをコンソール上で見ることです。以下のカーネルパラメータを渡して起動し、tty1 でパニックの再現を試みてください:
  +
  +
systemd.journald.forward_to_console=1 console=tty1
  +
  +
{{Tip|パニックメッセージが速くスクロールしすぎて検証できない場合、起動時にカーネルパラメータ {{ic|1=pause_on_oops=''seconds''}} を渡してみてください。}}
  +
  +
===== 例: 不良モジュール =====
  +
  +
診断メッセージの情報を使って、何のサブシステムやモジュールがパニックを引き起こしているかを推測できます。この例では、とある架空のマシンで起動中にパニックが発生してしまいました。'''太字'''で強調した行に注目してください。
  +
  +
{{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}}
  +
  +
# パニックを引き起こしたエラーの種類を示しています。この場合、プログラマのバグです。
  +
# モジュール ''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|1=module_blacklist=firewire_core}} を設定して再起動してください。
  +
  +
==== 再起動して root シェルに入り問題を修正する ====
  +
  +
{{Out of date|[https://github.com/archlinux/svntogit-packages/commit/776743d220cbb56e9abca2cc8bcef3a0ab7c8d0a initramfs の root アカウントはロックされているため]、{{ic|rd.rescue}} と {{ic|rd.emergency}} は動作しません。}}
  +
  +
{{Accuracy|{{ic|rd.emergency}} ではキーボードは動作しないため、使用できません。}}
  +
  +
システムに変更を加えてパニックが起こらないようにするには、root シェルが必要です。パニックが起動時に発生する場合、マシンがデッドロックする前に root シェルに入るための戦略が複数あります:
  +
  +
* カーネルパラメータ {{ic|emergency}} か {{ic|rd.emergency}} か {{ic|-b}} を設定して再起動する。これで、root ファイルシステムがマウントされて {{ic|systemd}} が起動した直後にログインプロンプトが表示されます。
  +
: {{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#イメージ作成とアクティベーション]] を見てください。}}
  +
  +
=== リグレッション デバッグ ===
   
 
[[一般的なトラブルシューティング#リグレッション デバッグ]] を参照してください。
  
[[一般的なトラブルシューティング#リグレッション デバッグ]] を参照してください。
   
−
{{AUR|linux-mainline}} を試して、その問題が既に上流で修正されているかどうかを確認してください。stickied コメントは既にビルドされたカーネルを含むリポジトリにも言及しているので、時間がかかる手動でのビルドは必要ないかもしれません。
 +
{{AUR|linux-mainline}} を試して、その問題が既に上流で修正されているかどうかを確認してください。ピン留めされたコメントは既にビルドされたカーネルを含むリポジトリにも言及しているので、時間がかかる手動でのビルドは必要ないかもしれません。
   
 
最近発生しなかった問題をデバッグするために LTS カーネル ({{Pkg|linux-lts}}) を試してみることも検討する価値があるかもしれません。LTS カーネルの古いバージョンは [[Arch Linux Archive]] で見つけることができます。
  
最近発生しなかった問題をデバッグするために LTS カーネル ({{Pkg|linux-lts}}) を試してみることも検討する価値があるかもしれません。LTS カーネルの古いバージョンは [[Arch Linux Archive]] で見つけることができます。
   
−
それでも問題が解決しないときは、[https://wiki.archlinux.org/title/Bisecting_bugs_with_Git bisect] をしてください。{{AUR|linux-git}} 、[https://bugzilla.kernel.org/ kernel bugzilla] でバグを報告してください。パッチと関係ないことを確認するために、パッチなしの ''バニラ'' バージョンを試すことが重要です。もしパッチが問題を引き起こすなら、そのパッチの作者に報告してください。
 +
それでも問題が解決しないときは、{{AUR|linux-git}} を [[bisect]] してください。そして、[https://bugzilla.kernel.org/ kernel bugzilla] でバグを報告してください。パッチと関係ないことを確認するために、パッチなしの「バニラ」バージョンを試すことが重要です。もしパッチが問題を引き起こすなら、そのパッチの作者に報告してください。
   
−
{{Note|Bisecting the kernel は何度も作り直さなければならないので、かなりの時間がかかるかもしれません。}}
 +
{{Note|カーネルの bisect は何度も作り直さなければならないので、かなりの時間がかかるかもしれません。}}
   
 
== 参照 ==
  
== 参照 ==

2022年7月26日 (火) 06:55時点における版

関連記事

Wikipedia より:

カーネルは、階層型に設計されたオペレーティングシステム (OS) の中核となる部分である。アプリケーションとハードウェアレベルでの実際のデータ処理との間の架け橋である。システムのリソースを管理し、ハードウェアとソフトウェアコンポーネントのやりとりを管理する。

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

カーネルパッケージはファイルシステム上の /boot/ に インストール されます。カーネルで起動できるようにするには、ブートローダー を適切に設定する必要があります。

公式サポートカーネル

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

  • Stable — Vanilla 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
  • Zen Kernel — カーネルハッカーの共同作業により、日常的なシステムに最適な Linux カーネルです。より詳細な情報は https://liquorix.net (Zen をベースにした Debian 用のカーネルバイナリを提供) で見ることができます。
https://github.com/zen-kernel/zen-kernel || linux-zen

コンパイル

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

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

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

kernel.org カーネル

  • Git — Linus Torvalds の git リポジトリから得たソースを使ってビルドする Linux カーネルとモジュール。
https://git.kernel.org/cgit/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
  • Longterm 4.9 — 長期サポート (LTS) Linux 4.9 カーネルとモジュール。
https://www.kernel.org/ || linux-lts49AUR
  • Longterm 4.14 — 長期サポート (LTS) Linux 4.14 カーネルとモジュール。
https://www.kernel.org/ || linux-lts414AUR
  • 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

非公式カーネル

  • Aufs — aufs 対応の linux カーネルとモジュール。Docker を使用する際に有用。
http://aufs.sourceforge.net/ || linux-aufsAUR
  • Ck — デスクトップに特に重点を置いてシステムの応答性を向上させるように設計された Con Kolivas (MuQSS scheduler を含む) によるパッチが含まれていますが、どのような使用目的でも問題なく使えます
http://ck.kolivas.org/ || linux-ckAUR
  • GalliumOS — Linux カーネルと Chromebook 用の GalliumOS パッチを備えたモジュール。
https://github.com/GalliumOS/linux || linux-galliumosAUR
https://www.fsfla.org/ikiwiki/selibre/linux-libre/ || linux-libreAUR
  • Liquorix — Debian をターゲットとした設定と Zen カーネルソースを使用して構築されたカーネル代替品。デスクトップ、マルチメディア、ゲームなどのワークロード向けに設計されており、Debian Linux の性能代替カーネルとしてよく利用されます。Liquorix パッチセットのメンテナである Damentz は、同様に Zen パッチセットの開発者でもあります。
https://liquorix.net || linux-lqxAUR
  • linux-clear — Intel の Clear Linux プロジェクトからのパッチ、パフォーマンスとセキュリティの最適化を提供します。
https://github.com/clearlinux-pkgs/linux || linux-clearAUR
  • linux-lqx — Liquorix はデスクトップ・マルチメディア・ゲーム用途に Debian 用の設定と ZEN カーネルソースを使ってビルドされたディストロカーネル代替です。Debian Linux ではパフォーマンス向上カーネルとしてよく使われています。Liquorix パッチセットのメンテナである Damentz は ZEN パッチセットの開発者でもあります。
https://liquorix.net || linux-lqxAUR
  • MultiPath TCP — に対応する Linux カーネルとモジュール。
https://multipath-tcp.org/ || linux-mptcpAUR
  • pf-kernel — カーネルメインラインにマージされない、ほんの少しの素晴らしい機能を提供します。カーネルエンジニアによって管理されています。新しいカーネルのための含まれるパッチのポートが公式にリリースされていない場合、パッチセットは新しいカーネルへのパッチポートを提供し、サポートします。linux-pf の現在の代表的なパッチは、PDS CPU スケジューラと UKSM です。
https://gitlab.com/post-factum/pf-kernel/wikis/README || パッケージ:
  • Realtime kernel — IngoMolnar が 率いるコア開発者の小グループによって維持されています。このパッチを使用すると、コードのいくつかの非常に小さな領域（raw_spinlock クリティカル領域）を除いて、ほぼすべてのカーネルをプリエンプトできます。これは、ほとんどのカーネルスピンロックを優先度継承をサポートするミューテックスに置き換え、すべての割り込みとソフトウェア割り込みをカーネルスレッドに移動することによって行われます。
https://wiki.linuxfoundation.org/realtime/start || linux-rtAUR, linux-rt-ltsAUR
  • VFIO — Alex Williamson によって作成されたいくつかのパッチ（acs オーバーライドおよび i915）により、一部のマシンで KVM を使用して PCI パススルーを実行できるようになります。
https://lwn.net/Articles/499240/ || linux-vfioAUR, linux-vfio-ltsAUR
  • Xanmod — 高性能ワークステーション、ゲーミングデスクトップ、メディアセンターなどで最大限に活用されることを目指し、より強固で応答性の高い、スムーズなデスクトップ体験を提供するために構築されています。このカーネルは、MuQSS またはタスクタイプスケジューラ、BFQ I/O スケジューラ、UKSM リアルタイムメモリーデータ重複排除、TCP BBR 輻輳制御、x86_64 高度命令セットサポート、および他のデフォルト値を変更しています。
https://xanmod.org/ || linux-xanmodAUR, linux-xanmod-ttAUR

トラブルシューティング

カーネルパニック

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=seconds を渡してみてください。
例: 不良モジュール

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

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 は何度も作り直さなければならないので、かなりの時間がかかるかもしれません。

参照

「https://wiki.archlinux.jp/index.php?title=カーネル&oldid=26597」から取得