ブートデバッグのソースを表示

[[Category:ブートプロセス]]
[[Category:システムリカバリ]]
[[en:Boot debugging]]
[[it:Boot debugging]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|ブートローダー}}
{{Related|Netconsole}}
{{Related|カーネルモジュール}}
{{Related|mkinitcpio}}
{{Related|Kernel Mode Setting}}
{{Related|systemd}}
{{Related articles end}}

様々なデバッグ出力のレベルで既存のシステムを簡単に出来るように、カーネルはあらゆる高度な設定を行うための便利な手段を用意しています [https://www.kernel.org/doc/Documentation/kernel-parameters.txt]。ブートローダーの設定にエントリを追加するだけで、とても簡単に複数のレベルのデバッグを作成することが可能です。電源やハードウェアの問題によって、後で問題が起こった時に、手数を減らすことができ、また、システムについて習熟したいと思った時にデバッグ出力に勝るものはありません。

まず、[[カーネルパラメータ]]の記事を読んでブートローダーにカーネルパラメータを追加する方法を見て下さい。

== デバッグレベル ==
=== Light Debug ===
コンソールで詳細なメッセージを見るための一番簡単な方法はブートローダーのエントリの kernel 行に {{ic|verbose}} を追加してから起動することです。

=== Medium Debug ===
kernel 行に {{ic|debug}} カーネルパラメータを追加することでデフォルト状態に比べて多くのデバッグ情報を得ることができます。

=== Heavy Debug ===
さらに効果的なカーネルパラメータとして {{ic|ignore_loglevel}} があり、ログレベルを全て無視して、システムの内部的なログレベルが最大レベルにまで引き上げられます。

=== Extreme Debug ===
"Heavy Debug" でも大量の出力がなされますが、[[カーネルパラメータ]]を加えることでさらに倍以上のログを出力できます:
 debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 earlyprintk=vga,keep sched_debug

EFI 環境の場合:

 debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 earlyprintk=efi,keep sched_debug

カーネルパラメータの説明:
* {{ic|earlyprintk}} パラメータはメッセージを ''vga'' スクリーンや ''EFI'' フレームバッファに ''early'' ''printing'' するようにカーネルを設定します。
* {{ic|keep}} パラメータは通常時ブートプロセスで隠れてしまうログを表示させます。
* {{ic|1=log_buf_len=10M}} はログバッファの長さを 10MB に変更します。
* {{ic|print_fatal_signals}} によって fatal signal を全て表示します。
* 最後の {{ic|sched_debug}} についてはカーネルドキュメントの [https://www.kernel.org/doc/Documentation/kernel-parameters.txt カーネルパラメータ] に詳しい説明があります。

=== Insane Debug ===
上記のデバッグカーネルパラメータは大量のデバッグ情報を表示するようになります。システムを最大化して裏で何が起こっているのか知るのには極めて効果的です。しかしながら、さらに強力な決定打が存在します。環境変数と、起動時のモジュールパラメータを設定します。

以下が真の insane デバッグをするための[[カーネルパラメータ]]です。実際に使用するときは GRUB のエントリに一行で記述します。ほとんどのデバイスでデバッグレベルを絶対最大値まで上げられます。マシンは TI-89 電卓よりも遅くなります ([[ブートパフォーマンスの向上]]を参照)。

 rootwait ignore_loglevel debug debug_locks_verbose=1 sched_debug initcall_debug 
 mminit_loglevel=4 udev.log_priority=8 loglevel=8 earlyprintk=vga,keep log_buf_len=10M
 print_fatal_signals=1 apm.debug=Y i8042.debug=Y drm.debug=1 scsi_logging_level=1
 usbserial.debug=Y option.debug=Y pl2303.debug=Y firewire_ohci.debug=1 hid.debug=1
 pci_hotplug.debug=Y pci_hotplug.debug_acpi=Y shpchp.shpchp_debug=Y apic=debug
 show_lapic=all hpet=verbose lmb=debug pause_on_oops=5 panic=10 sysrq_always_enabled

== デバッグの方法 ==
=== モジュールパラメータ ===
[[カーネルモジュール]]を見て下さい。

=== netconsole ===
[https://www.kernel.org/doc/Documentation/networking/netconsole.txt デバッグに関するカーネルドキュメント] を読むと、カーネルに組み込んでモジュールとしてロードできる [[netconsole]] を知ることができます。古いノートパソコンやシンクライアントなど、動作が遅いコンピュータをデバッグするときは、netconsole エントリを[[カーネルパラメータ]]に記述すると役に立つでしょう。簡単に使うことができます:
# {{ic|syslog.conf}} を使ってリモートホストの syslog リクエストを受け入れるように (Arch が動作する) 他のコンピュータを設定。
# {{ic|/var/log/everything.log}} ファイルでログを確認。
# デバッグするコンピュータに、{{ic|1=netconsole=514@10.0.0.2/12:34:56:78:9a:bc}} のようなカーネルパラメータを追加 (デバッグしたいパラメータも追加してください)。
# コンピュータを再起動してログを確認する。

=== cmdline をハイジャック ===
ブートローダーにアクセスすることすらできない場合でも、(root 権限があれば) カーネルパラメータを変更してデバッグを有効にできる可能性があります。その方法とは、カーネルパラメータが保存されている {{ic|/proc/cmdline}} を上書きすることです。{{ic|/proc/cmdline}} は root でも書き込むことができないので、バインドマウントを使ってパスをマスクすることでハイジャックします。

まず、使用したいカーネルパラメータを記述したファイルを作成してください:

{{hc|/root/cmdline|2=root=/dev/disk/by-label/ROOT ro console=tty1 logo.nologo debug}}

次に、バインドマウントを使ってパラメータを上書きします:

 # mount -n --bind -o ro /root/cmdline /proc/cmdline

{{ic|-n}} オプションは {{ic|/etc/mtab}} へのマウントの追加をスキップするため、root が読み取り専用でマウントされていても機能します。{{ic|cat /proc/cmdline}} を実行することでカーネルパラメータが変更されたか確認できます。

== トラブルシューティング ==
=== 出力が途切れる ===
==== 解像度の変更時に出力が消える ====
解像度が変更されるときに起動出力が消えてしまう場合、デバッグのために [[KMS#モードセッティングを無効にする|KMS を無効化]]することができます。

==== スクロールができない ====
起動時の出力が4または5ページに限られており、上記のデバッグパラメータを使うためにもっと表示させたい場合、[[カーネルパラメータ]]に以下のアイテムを追加します:
 fbcon=scrollback:512k 

詳しくは[[スクロールバックバッファ]]を参照。

=== Arch ライブ CD で修復 ===
GRUB がカーネルを起動できなくなったり、initramfs が壊れた場合、[https://www.archlinuxjp.org/download/ Arch ライブ CD] を使って安全にシステムを起動することができます。修復が修正したら、壊れたシステムをアンマウントして、再起動してください。

== リカバリシェル ==

デーモンによるエラーや、fstab の記述が間違っている、またはディスプレイマネージャや Xorg に問題が発生していて、起動できない場合、シングルユーザー[[systemd#ターゲット|ランレベル]]を使うことで問題を修正できることがあります。シングルユーザーモードでは起動後に root シェルだけを表示します。リカバリシェルを起動するカーネルパラメータは複数存在しますが、どれも {{ic|exit}} で通常シェルに戻り、カーネルが元の状態に復帰します:
* {{ic|rescue}} は root ファイルシステムが読み書きできる状態で再マウントされたすぐ後にシェルを起動します。
* {{ic|emergency}} は更に早く、ファイルシステムがマウントされる前にシェルを起動します。
* (何らかの理由で上記のパラメータが使えない場合) {{ic|1=init=/bin/sh}} は init プログラムを root シェルに変えます。{{ic|rescue}} と {{ic|emergency}} はどちらも [[systemd]] に依存しますが、{{ic|1=init=/bin/sh}} はたとえ ''systemd'' が壊れても使えます。

また、{{ic|debug-shell.service}} を[[有効化]]することで {{ic|tty9}} に root シェルを追加することもできます (Ctrl+Alt+F9 でアクセス可能)。root シェルが開きっぱなしになっているとセキュリティ上危険なので、修復が終わったらサービスは無効化してください。

==参照==
* [http://www.memtest.org/ Memtest86+]
* [http://wiki.ultimatebootcd.com/index.php?title=Tools List of Tools for UBCD] - Can be added to custom menu.lst like memtest
* Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]
* [https://fedoraproject.org/wiki/QA/Sysrq QA/Sysrq] - Using sysrq
* systemd ドキュメント: [http://freedesktop.org/wiki/Software/systemd/Debugging#Debug_Logging_to_a_Serial_Console Debug Logging to a Serial Console]
* [https://lesswatts.org/projects/acpi/debug.php How to Isolate Linux ACPI Issues]