ブートデバッグ - 版の履歴

Kusakata: 一般的なトラブルシューティング#起動時の問題への転送ページ

2016-12-05T16:10:16Z

← 古い版		2016年12月6日 (火) 01:10時点における版
1行目:		1行目:
			#redirect[[一般的なトラブルシューティング#起動時の問題]]
	[[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]

2015年12月22日 (火) 13:20にKusakataによる

2015-12-22T13:20:33Z

差分を表示

2015年11月23日 (月) 11:04にKusakataによる

2015-11-23T11:04:30Z

← 古い版		2015年11月23日 (月) 20:04時点における版
2行目:		2行目:
	[[Category:システムリカバリ]]		[[Category:システムリカバリ]]
	[[en:Boot debugging]]		[[en:Boot debugging]]
	[[it:Boot ~~Debugging~~]]		[[it:Boot debugging]]
	{{Related articles start}}		{{Related articles start}}
	{{Related\|Arch ブートプロセス}}		{{Related\|Arch ブートプロセス}}
77行目:		77行目:

	=== netconsole ===		=== netconsole ===
			[https://www.kernel.org/doc/Documentation/networking/netconsole.txt デバッグに関するカーネルドキュメント] を読むと、カーネルに組み込んでモジュールとしてロードできる [[netconsole]] を知ることができます。古いノートパソコンやシンクライアントなど、動作が遅いコンピュータをデバッグするときは、netconsole エントリを[[カーネルパラメータ]]に記述すると役に立つでしょう。簡単に使うことができます:
	If you read through the [https://www.kernel.org/doc/Documentation/networking/netconsole.txt kernel documentation regarding debugging], you will read about [[netconsole]], which can be compiled into your kernel or loaded at runtime as a module. Having a netconsole entry in your [[kernel parameters]] is most excellent for debugging slower computers like old laptops or thin-clients. It is easy to use:
	# Set up a 2nd computer (running Arch) to accept syslog requests on a remote port, which is one line in {{ic\|syslog.conf}}.		# Set up a 2nd computer (running Arch) to accept syslog requests on a remote port, which is one line in {{ic\|syslog.conf}}.
	# Then you could use a log-color-parser like ccze to view all syslog logs, or just tail your {{ic\|/var/log/everything.log}} file.		# Then you could use a log-color-parser like ccze to view all syslog logs, or just tail your {{ic\|/var/log/everything.log}} file.
	# ~~On your laptop, boot up and add~~ {{ic\|1=netconsole=514@10.0.0.2/12:34:56:78:9a:bc debug ignore_loglevel}} ~~into [[kernel parameters]].~~		# ノートパソコンを起動して、[[カーネルパラメータ]]に {{ic\|1=netconsole=514@10.0.0.2/12:34:56:78:9a:bc debug ignore_loglevel}} を追加してください。
	# You will start seeing as much logging as you want on your syslog system. This logging lets you view even earlier log output than is available with the {{ic\|1=earlyprintk=vga}} kernel parameter, as netconsole is used by kernel hackers and developers, so it is very powerful.		# You will start seeing as much logging as you want on your syslog system. This logging lets you view even earlier log output than is available with the {{ic\|1=earlyprintk=vga}} kernel parameter, as netconsole is used by kernel hackers and developers, so it is very powerful.

140行目:		140行目:

	Afterwards, unmount and reboot.		Afterwards, unmount and reboot.

			=== シングルユーザーモード ===

			デーモンによるエラーや、fstab の記述が間違っている、またはディスプレイマネージャや Xorg に問題が発生していて、起動できない場合、シングルユーザー[[systemd#ターゲット\|ランレベル]]を使うことで問題を修正できることがあります。シングルユーザーモードでは起動後に root シェルだけを表示します。Arch は systemd を使っているため、カーネルパラメータに {{ic\|1=systemd.unit=rescue.target}} を追加することでシングルユーザーモードにできます。何らかの理由でこのパラメータが使えない場合 (例: rescue ターゲットが他の問題があるターゲットに依存している)、カーネルパラメータに {{ic\|1=init=/bin/sh}} を追加することで root シェルを起動できます。

	==参照==		==参照==

2015年8月9日 (日) 08:03にKusakataによる

2015-08-09T08:03:20Z

← 古い版		2015年8月9日 (日) 17:03時点における版
37行目:		37行目:
	カーネルパラメータの説明:		カーネルパラメータの説明:
	* {{ic\|earlyprintk}} パラメータはメッセージを ''vga'' スクリーンや ''EFI'' フレームバッファに ''early'' ''printing'' するようにカーネルを設定します。		* {{ic\|earlyprintk}} パラメータはメッセージを ''vga'' スクリーンや ''EFI'' フレームバッファに ''early'' ''printing'' するようにカーネルを設定します。
			* {{ic\|keep}} パラメータは通常時ブートプロセスで隠れてしまうログを表示させます。
	* The {{ic\|keep}} parameter just lets it stay on the screen longer. This will let you see logs that normally are hidden due to the boot-up process.
	* {{ic\|1=log_buf_len=10M}} はログバッファの長さを 10MB に変更します。		* {{ic\|1=log_buf_len=10M}} はログバッファの長さを 10MB に変更します。
	* {{ic\|print_fatal_signals}} によって fatal signal を全て表示します。		* {{ic\|print_fatal_signals}} によって fatal signal を全て表示します。
	* ~~With the last one,~~ {{ic\|sched_debug}}, ~~you can look up in the very excellent kernel documentation on~~ [https://www.kernel.org/doc/Documentation/kernel-parameters.txt ~~kernel~~ ~~parameters].~~		* 最後の {{ic\|sched_debug}} についてはカーネルドキュメントの [https://www.kernel.org/doc/Documentation/kernel-parameters.txt カーネルパラメータ] に詳しい説明があります。

	=== Insane Debug ===		=== Insane Debug ===
			上記のデバッグカーネルパラメータは大量のデバッグ情報を表示するようになります。システムを最大化して裏で何が起こっているのか知るのには極めて効果的です。しかしながら、さらに強力な決定打が存在します。環境変数と、起動時のモジュールパラメータを設定します。
	The first few debugging kernel parameters turn on really verbose debugging. This kind of debugging is absolutely critical if you want to max out your system or just learn more about what is going on behind the scenes. But there is a final trick that is my favorite, which is the ability to set both environment variables and, more importantly, module parameters at boot.

			以下が真の insane デバッグをするための[[カーネルパラメータ]]です。実際に使用するときは GRUB のエントリに一行で記述します。ほとんどのデバイスでデバッグレベルを絶対最大値まで上げられます。マシンは TI-89 電卓よりも遅くなります ([[ブートパフォーマンスの向上]]を参照)。
	As an example, here is some truly insane debugging [[kernel parameters]]. Note that the actual GRUB entry is all on one line. This turns on many devices to be at the absolute max debug level. The machine may be slower than a TI-89 calculator (See [[Improve boot performance]]).

	rootwait ignore_loglevel debug debug_locks_verbose=1 sched_debug initcall_debug		rootwait ignore_loglevel debug debug_locks_verbose=1 sched_debug initcall_debug

2015年8月9日 (日) 04:56にKusakataによる

2015-08-09T04:56:37Z

← 古い版		2015年8月9日 (日) 13:56時点における版
60行目:		60行目:
	[[カーネルモジュール]]を見て下さい。		[[カーネルモジュール]]を見て下さい。

	=== ~~Break~~ ~~into Init~~ ===		=== Init に割り込む ===
	For instance, if you add {{ic\|1=break=y}} to your kernel command line, init will pause early in the [[Arch ~~boot process~~\|boot process]] (after loading modules) and launch an interactive sh shell which can be used for troubleshooting purposes. Normal boot continues after logging out. This is very similar to the shell that shows up if your computer gets turned off before it is able to shutdown properly. But using this parameter lets you enter into this mode differently at will.		For instance, if you add {{ic\|1=break=y}} to your kernel command line, init will pause early in the [[Arch ブートプロセス\|boot process]] (after loading modules) and launch an interactive sh shell which can be used for troubleshooting purposes. Normal boot continues after logging out. This is very similar to the shell that shows up if your computer gets turned off before it is able to shutdown properly. But using this parameter lets you enter into this mode differently at will.

	=== init のデバッグ ===		=== init のデバッグ ===
	The awesome parameter {{ic\|1=udev.~~log_priority~~=8}} does the same thing as editing the file {{ic\|/etc/udev/udev.conf}} except it executes earlier, turning on debugging output for [[udev]]. If you want to know your hardware, that is the key parameter right there. Another trick is if you change the {{ic\|/etc/udev/udev.conf}} to be verbose, then you can make your initramfs image include that file to turn on verbose udev debugging by adding it to your {{ic\|/etc/mkinitcpio.conf}} like:		The awesome parameter {{ic\|1=udev.log-priority=8}} does the same thing as editing the file {{ic\|/etc/udev/udev.conf}} except it executes earlier, turning on debugging output for [[udev]]. If you want to know your hardware, that is the key parameter right there. Another trick is if you change the {{ic\|/etc/udev/udev.conf}} to be verbose, then you can make your initramfs image include that file to turn on verbose udev debugging by adding it to your {{ic\|/etc/mkinitcpio.conf}} like:
	FILES="/etc/modprobe.d/modprobe.conf /etc/udev/udev.conf"		FILES="/etc/modprobe.d/modprobe.conf /etc/udev/udev.conf"

70行目:		70行目:
	# mkinitcpio -p linux		# mkinitcpio -p linux

	Debugging [[udev]] is important because the initramfs performs a [[Change ~~root~~\|root change]] at the end of its run to usually launch a program like {{ic\|/sbin/init}} as part of a chroot, and unless the new file system has a valid {{ic\|/dev}} directory, udev must be initialized before invoking chroot in order to provide {{ic\|/dev/console}}.		Debugging [[udev]] is important because the initramfs performs a [[Change Root\|root change]] at the end of its run to usually launch a program like {{ic\|/sbin/init}} as part of a chroot, and unless the new file system has a valid {{ic\|/dev}} directory, udev must be initialized before invoking chroot in order to provide {{ic\|/dev/console}}.

	exec chroot . /sbin/init <dev/console >dev/console 2>&1		exec chroot . /sbin/init <dev/console >dev/console 2>&1
103行目:		103行目:

	== トラブルシューティング ==		== トラブルシューティング ==
	=== ~~Output cut off~~ ===		=== 出力が途切れる ===
			==== 解像度の変更時に出力が消える ====
	==== Cut off when switching resolution ====
			解像度が変更されるときに起動出力が消えてしまう場合、デバッグのために [[KMS#モードセッティングを無効にする\|KMS を無効化]]することができます。
	If the first part of your boot output disappears when the resolution changes you can try to [[KMS#Disabling_modesetting\|disable KMS]] for debugging.

	==== ~~Scrolling limited~~ ====		==== スクロールができない ====
			起動時の出力が4または5ページに限られており、上記のデバッグパラメータを使うためにもっと表示させたい場合、[[カーネルパラメータ]]に以下のアイテムを追加します:
	If your boot output is limited to 4 or 5 pages and you need more so you can use the debug parameters above, add the following item to your [[kernel parameters]]
	fbcon=scrollback:512k		fbcon=scrollback:512k

			詳しくは[[スクロールバックバッファ]]を参照。
	You can read more about this in [[Scrollback buffer]].

	=== ~~Repairing with~~ Arch ~~live~~ CD ===		=== Arch ライブ CD で修復 ===
			GRUB がカーネルを起動できなくなったり、initramfs が壊れた場合、[https://www.archlinuxjp.org/download/ Arch ライブ CD] を使って安全にシステムを起動することができます。修復が修正したら、壊れたシステムをアンマウントして、再起動してください。
	In case grub is unable to boot your kernel, or if your initramfs is broken, you can boot into a safe system using an [https://www.archlinux.org/download/ Arch live CD]. Once finished with repairs, unmount the broken system, and reboot.

			==== 壊れたシステムのマウントと chroot ====
	==== Mounting and chrooting a broken system ====
	Once booted and at a console prompt, use the following to mount and repair your broken system (where {{ic\|/dev/sda3}} is {{ic\|/}} and {{ic\|/dev/sda1}} is {{ic\|/boot}}):		Once booted and at a console prompt, use the following to mount and repair your broken system (where {{ic\|/dev/sda3}} is {{ic\|/}} and {{ic\|/dev/sda1}} is {{ic\|/boot}}):

133行目:		133行目:
	Turn on networking.		Turn on networking.

	==== ~~Reinstalling~~ ~~with pacman~~ ====		==== pacman で再インストール ====
	The author uses pacman in a chrooted broken system to reinstall the kernel, GRUB, initramfs, udev, and any other packages that may be broken and/or needed to get the system up and running.		The author uses pacman in a chrooted broken system to reinstall the kernel, GRUB, initramfs, udev, and any other packages that may be broken and/or needed to get the system up and running.

2015年3月24日 (火) 10:38にKusakataによる

2015-03-24T10:38:23Z

← 古い版		2015年3月24日 (火) 19:38時点における版
19行目:		19行目:
	== デバッグレベル ==		== デバッグレベル ==
	=== Light Debug ===		=== Light Debug ===
			コンソールで詳細なメッセージを見るための一番簡単な方法はブートローダーのエントリの kernel 行に {{ic\|verbose}} を追加してから起動することです。
	A quick way to see more verbose messages on your console is to boot up your bootloader entry after appending {{ic\|verbose}} to the kernel line.

	=== Medium Debug ===		=== Medium Debug ===
			kernel 行に {{ic\|debug}} カーネルパラメータを追加することでデフォルト状態に比べて多くのデバッグ情報を得ることができます。
	Adding the {{ic\|debug}} kernel parameter to your kernel line is recognized by a lot of Linux internals and enables quite a bit of debugging compared to the default.

	=== Heavy Debug ===		=== Heavy Debug ===
			さらに効果的なカーネルパラメータとして {{ic\|ignore_loglevel}} があり、ログレベルを全て無視して、システムの内部的なログレベルが最大レベルにまで引き上げられます。
	An even more impressive kernel parameter is the {{ic\|ignore_loglevel}}, which causes the system to ignore any loglevel and keeps the internal loglevel at the maximum debugging level, basically rendering dmesg unable to lower the debug level.

	=== Extreme Debug ===		=== Extreme Debug ===
			"Heavy Debug" でも大量の出力がなされますが、[[カーネルパラメータ]]を加えることでさらに倍以上のログを出力できます:
	If the "Heavy Debug" seemed like a lot of output, that is about half of the logging that occurs with [[kernel parameters]]:
	debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 earlyprintk=vga,keep sched_debug		debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 earlyprintk=vga,keep sched_debug

			EFI 環境の場合:
	Or for EFI systems

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

			カーネルパラメータの説明:
	This does a couple things:
			* {{ic\|earlyprintk}} パラメータはメッセージを ''vga'' スクリーンや ''EFI'' フレームバッファに ''early'' ''printing'' するようにカーネルを設定します。
	* It uses the {{ic\|earlyprintk}} parameter to setup your kernel for ''early'' ''printing'' of messages to your ''vga'' screen or ''EFI'' framebuffer.
	* The {{ic\|keep}} parameter just lets it stay on the screen longer. This will let you see logs that normally are hidden due to the boot-up process.		* The {{ic\|keep}} parameter just lets it stay on the screen longer. This will let you see logs that normally are hidden due to the boot-up process.
	* {{ic\|1=log_buf_len=10M}} ~~changes~~ ~~the~~ ~~log buffer length to 10MB~~		* {{ic\|1=log_buf_len=10M}} はログバッファの長さを 10MB に変更します。
	* ~~Instructs that any fatal signals be printed with~~ {{ic\|print_fatal_signals}}		* {{ic\|print_fatal_signals}} によって fatal signal を全て表示します。
	* With the last one, {{ic\|sched_debug}}, you can look up in the very excellent kernel documentation on [https://www.kernel.org/doc/Documentation/kernel-parameters.txt kernel parameters].		* With the last one, {{ic\|sched_debug}}, you can look up in the very excellent kernel documentation on [https://www.kernel.org/doc/Documentation/kernel-parameters.txt kernel parameters].

54行目:		54行目:
	show_lapic=all hpet=verbose lmb=debug pause_on_oops=5 panic=10 sysrq_always_enabled		show_lapic=all hpet=verbose lmb=debug pause_on_oops=5 panic=10 sysrq_always_enabled

	A couple key items are {{ic\|sysrq_always_enabled}} which forces on the SysRq magic, which really is a lifesaver when debugging at this level, as your machine will freeze/stop-responding sometimes, and it is nice to use SysRq to kill all tasks, change the log level, unmount all file systems, or do a hard reboot. Another key parameter is {{ic\|initcall_debug}}, which debugs the init process in excruciating detail, which can be very useful at times. The last parameter I find very useful is {{ic\|1=udev.~~log_priority~~=8}} to turn on [[udev]] logging.		A couple key items are {{ic\|sysrq_always_enabled}} which forces on the SysRq magic, which really is a lifesaver when debugging at this level, as your machine will freeze/stop-responding sometimes, and it is nice to use SysRq to kill all tasks, change the log level, unmount all file systems, or do a hard reboot. Another key parameter is {{ic\|initcall_debug}}, which debugs the init process in excruciating detail, which can be very useful at times. The last parameter I find very useful is {{ic\|1=udev.log-priority=8}} to turn on [[udev]] logging.

	== デバッグの方法 ==		== デバッグの方法 ==

Kusakata: ページの作成:「Category:ブートプロセス Category:システムリカバリ en:Boot debugging it:Boot Debugging {{Related articles start}} {{Related|Arch ブート...」

2015-02-14T09:28:40Z

ページの作成:「Category:ブートプロセス Category:システムリカバリ en:Boot debugging it:Boot Debugging {{Related articles start}} {{Related|Arch ブート...」

新規ページ

[[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 ===
A quick way to see more verbose messages on your console is to boot up your bootloader entry after appending {{ic|verbose}} to the kernel line.

=== Medium Debug ===
Adding the {{ic|debug}} kernel parameter to your kernel line is recognized by a lot of Linux internals and enables quite a bit of debugging compared to the default.

=== Heavy Debug ===
An even more impressive kernel parameter is the {{ic|ignore_loglevel}}, which causes the system to ignore any loglevel and keeps the internal loglevel at the maximum debugging level, basically rendering dmesg unable to lower the debug level.

=== Extreme Debug ===
If the "Heavy Debug" seemed like a lot of output, that is about half of the logging that occurs with [[kernel parameters]]:
debug ignore_loglevel log_buf_len=10M print_fatal_signals=1 LOGLEVEL=8 earlyprintk=vga,keep sched_debug

Or for EFI systems

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

This does a couple things:
* It uses the {{ic|earlyprintk}} parameter to setup your kernel for ''early'' ''printing'' of messages to your ''vga'' screen or ''EFI'' framebuffer.
* The {{ic|keep}} parameter just lets it stay on the screen longer. This will let you see logs that normally are hidden due to the boot-up process.
* {{ic|1=log_buf_len=10M}} changes the log buffer length to 10MB
* Instructs that any fatal signals be printed with {{ic|print_fatal_signals}}
* With the last one, {{ic|sched_debug}}, you can look up in the very excellent kernel documentation on [https://www.kernel.org/doc/Documentation/kernel-parameters.txt kernel parameters].

=== Insane Debug ===
The first few debugging kernel parameters turn on really verbose debugging. This kind of debugging is absolutely critical if you want to max out your system or just learn more about what is going on behind the scenes. But there is a final trick that is my favorite, which is the ability to set both environment variables and, more importantly, module parameters at boot.

As an example, here is some truly insane debugging [[kernel parameters]]. Note that the actual GRUB entry is all on one line. This turns on many devices to be at the absolute max debug level. The machine may be slower than a TI-89 calculator (See [[Improve boot performance]]).

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

A couple key items are {{ic|sysrq_always_enabled}} which forces on the SysRq magic, which really is a lifesaver when debugging at this level, as your machine will freeze/stop-responding sometimes, and it is nice to use SysRq to kill all tasks, change the log level, unmount all file systems, or do a hard reboot. Another key parameter is {{ic|initcall_debug}}, which debugs the init process in excruciating detail, which can be very useful at times. The last parameter I find very useful is {{ic|1=udev.log_priority=8}} to turn on [[udev]] logging.

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

=== Break into Init ===
For instance, if you add {{ic|1=break=y}} to your kernel command line, init will pause early in the [[Arch boot process|boot process]] (after loading modules) and launch an interactive sh shell which can be used for troubleshooting purposes. Normal boot continues after logging out. This is very similar to the shell that shows up if your computer gets turned off before it is able to shutdown properly. But using this parameter lets you enter into this mode differently at will.

=== init のデバッグ ===
The awesome parameter {{ic|1=udev.log_priority=8}} does the same thing as editing the file {{ic|/etc/udev/udev.conf}} except it executes earlier, turning on debugging output for [[udev]]. If you want to know your hardware, that is the key parameter right there. Another trick is if you change the {{ic|/etc/udev/udev.conf}} to be verbose, then you can make your initramfs image include that file to turn on verbose udev debugging by adding it to your {{ic|/etc/mkinitcpio.conf}} like:
FILES="/etc/modprobe.d/modprobe.conf /etc/udev/udev.conf"

which, on Arch, is as easy as
# mkinitcpio -p linux

Debugging [[udev]] is important because the initramfs performs a [[Change root|root change]] at the end of its run to usually launch a program like {{ic|/sbin/init}} as part of a chroot, and unless the new file system has a valid {{ic|/dev}} directory, udev must be initialized before invoking chroot in order to provide {{ic|/dev/console}}.

exec chroot . /sbin/init <dev/console >dev/console 2>&1

So basically, you are not able to view the logs that are generated before {{ic|/dev/console}} is initialized by udev or by a special initramfs you compiled yourself. One method the kernel developers use to be able to still get the log messages generated before {{ic|/dev/console}} is available, is to provide an alternative console that you can enable or disable from GRUB.

=== netconsole ===
If you read through the [https://www.kernel.org/doc/Documentation/networking/netconsole.txt kernel documentation regarding debugging], you will read about [[netconsole]], which can be compiled into your kernel or loaded at runtime as a module. Having a netconsole entry in your [[kernel parameters]] is most excellent for debugging slower computers like old laptops or thin-clients. It is easy to use:
# Set up a 2nd computer (running Arch) to accept syslog requests on a remote port, which is one line in {{ic|syslog.conf}}.
# Then you could use a log-color-parser like ccze to view all syslog logs, or just tail your {{ic|/var/log/everything.log}} file.
# On your laptop, boot up and add {{ic|1=netconsole=514@10.0.0.2/12:34:56:78:9a:bc debug ignore_loglevel}} into [[kernel parameters]].
# You will start seeing as much logging as you want on your syslog system. This logging lets you view even earlier log output than is available with the {{ic|1=earlyprintk=vga}} kernel parameter, as netconsole is used by kernel hackers and developers, so it is very powerful.

=== cmdline をハイジャック ===
If you do not have access to GRUB or the kernel boot-time command line, like on a server or virtual machine, as long as you have root permissions, you can still enable this kind of simplistic verbose logging using a neat hack. While you cannot modify the {{ic|/proc/cmdline}} even as root, you can place your own cmdline file on top of {{ic|/proc/cmdline}}, so that accessing {{ic|/proc/cmdline}} actually accesses your file instead.

For example, if I {{ic|cat /proc/cmdline}}, I have the following:

root=/dev/disk/by-label/ROOT ro console=tty1 logo.nologo quiet

So I use a simple ''sed'' command to replace {{ic|quiet}} with {{ic|verbose}} like:

sed '/root=/s/ quiet/ verbose/g' /proc/cmdline > /root/cmdline

Then I bind mount {{ic|/root/cmdline}} so that it becomes {{ic|/proc/cmdline}}, using the {{ic|-n}} option to mount, so that this mount will not be recorded in the system's mtab.

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

Now if I {{ic|cat /proc/cmdline}}, I have the following:

root=/dev/disk/by-label/ROOT ro console=tty1 logo.nologo verbose

== トラブルシューティング ==
=== Output cut off ===
==== Cut off when switching resolution ====
If the first part of your boot output disappears when the resolution changes you can try to [[KMS#Disabling_modesetting|disable KMS]] for debugging.

==== Scrolling limited ====
If your boot output is limited to 4 or 5 pages and you need more so you can use the debug parameters above, add the following item to your [[kernel parameters]]
fbcon=scrollback:512k

You can read more about this in [[Scrollback buffer]].

=== Repairing with Arch live CD ===
In case grub is unable to boot your kernel, or if your initramfs is broken, you can boot into a safe system using an [https://www.archlinux.org/download/ Arch live CD]. Once finished with repairs, unmount the broken system, and reboot.

==== Mounting and chrooting a broken system ====
Once booted and at a console prompt, use the following to mount and repair your broken system (where {{ic|/dev/sda3}} is {{ic|/}} and {{ic|/dev/sda1}} is {{ic|/boot}}):

First, create the mount point, and mount your root {{ic|/}} file system to it; then, {{ic|cd}} into it.
# mkdir /mnt/arch
# mount /dev/sda3 /mnt/arch
# cd /mnt/arch
Now, create the proc, sysfs, and dev file systems
# mount -t proc proc proc/
# mount -t sysfs sys sys/
# mount -o bind /dev dev/
Next, mount the boot partition if you use one.
# mount /dev/sda1 boot/
Finally, chroot into {{ic|/mnt/arch}} which will become {{ic|/}}.
# chroot .
Turn on networking.

==== Reinstalling with pacman ====
The author uses pacman in a chrooted broken system to reinstall the kernel, GRUB, initramfs, udev, and any other packages that may be broken and/or needed to get the system up and running.

This will reinstall the kernel and initramfs so check that {{ic|/etc/mkinitcpio.conf}} is correct or remove the file entirely and re-install mkinitcpio.
# pacman -Syyu mkinitcpio linux udev

Afterwards, unmount and reboot.

==参照==
* [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
* GRUB2 公式マニュアル - https://www.gnu.org/software/grub/manual/grub.html
* Ubuntu wiki page for GRUB2 - https://help.ubuntu.com/community/Grub2
* GRUB2 wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting
* 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]