ブートデバッグ

提供: ArchWiki
2015年11月23日 (月) 20:04時点におけるKusakata (トーク | 投稿記録)による版
ナビゲーションに移動 検索に移動

関連記事

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

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

デバッグレベル

Light Debug

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

Medium Debug

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

Heavy Debug

さらに効果的なカーネルパラメータとして 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

カーネルパラメータの説明:

  • earlyprintk パラメータはメッセージを vga スクリーンや EFI フレームバッファに early printing するようにカーネルを設定します。
  • keep パラメータは通常時ブートプロセスで隠れてしまうログを表示させます。
  • log_buf_len=10M はログバッファの長さを 10MB に変更します。
  • print_fatal_signals によって fatal signal を全て表示します。
  • 最後の sched_debug についてはカーネルドキュメントの カーネルパラメータ に詳しい説明があります。

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

A couple key items are 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 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 udev.log-priority=8 to turn on udev logging.

デバッグの方法

モジュールパラメータ

カーネルモジュールを見て下さい。

Init に割り込む

For instance, if you add break=y to your kernel command line, init will pause early in the 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 udev.log-priority=8 does the same thing as editing the file /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 /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 /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 root change at the end of its run to usually launch a program like /sbin/init as part of a chroot, and unless the new file system has a valid /dev directory, udev must be initialized before invoking chroot in order to provide /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 /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 /dev/console is available, is to provide an alternative console that you can enable or disable from GRUB.

netconsole

デバッグに関するカーネルドキュメント を読むと、カーネルに組み込んでモジュールとしてロードできる netconsole を知ることができます。古いノートパソコンやシンクライアントなど、動作が遅いコンピュータをデバッグするときは、netconsole エントリをカーネルパラメータに記述すると役に立つでしょう。簡単に使うことができます:

  1. Set up a 2nd computer (running Arch) to accept syslog requests on a remote port, which is one line in syslog.conf.
  2. Then you could use a log-color-parser like ccze to view all syslog logs, or just tail your /var/log/everything.log file.
  3. ノートパソコンを起動して、カーネルパラメータに netconsole=514@10.0.0.2/12:34:56:78:9a:bc debug ignore_loglevel を追加してください。
  4. 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 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 /proc/cmdline even as root, you can place your own cmdline file on top of /proc/cmdline, so that accessing /proc/cmdline actually accesses your file instead.

For example, if I 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 quiet with verbose like: 

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

Then I bind mount /root/cmdline so that it becomes /proc/cmdline, using the -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 cat /proc/cmdline, I have the following: 

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

トラブルシューティング

出力が途切れる

解像度の変更時に出力が消える

解像度が変更されるときに起動出力が消えてしまう場合、デバッグのために KMS を無効化することができます。

スクロールができない

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

fbcon=scrollback:512k

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

Arch ライブ CD で修復

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

壊れたシステムのマウントと chroot

Once booted and at a console prompt, use the following to mount and repair your broken system (where /dev/sda3 is / and /dev/sda1 is /boot):

First, create the mount point, and mount your root / file system to it; then, 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 /mnt/arch which will become /. 

# chroot .

Turn on networking.

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 /etc/mkinitcpio.conf is correct or remove the file entirely and re-install mkinitcpio. 

# pacman -Syyu mkinitcpio linux udev

Afterwards, unmount and reboot.

シングルユーザーモード

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

参照

「https://wiki.archlinux.jp/index.php?title=ブートデバッグ&oldid=4118」から取得