Boot debugging: Difference between revisions

Revision as of 20:08, 12 December 2015

A lot happens during the boot process, so it is a common time for errors to manifest. There are many methods for diagnosing and fixing boot problems but most of them involve changing the kernel parameters and rebooting the system. Ensure that you are familiar with how to change your kernel parameters.

Console Clearing

If all you want is to be able to see error messages that are already being displayed, you should disable clearing of boot messages.

Debug output

Most kernel messages are hidden during boot. You can see more of these messages by adding different kernel parameters. The simplest ones are:

debug enables debug messages for both the kernel and systemd
ignore_loglevel forces all kernel messages to be printed

Other parameters you can add that might be useful in certain situations are:

earlyprintk=vga,keep prints kernel messages very early in the boot process, in case the kernel would crash before output is shown. You must change vga to efi for EFI systems
log_buf_len=16M allocates a larger (16MB) kernel message buffer, to ensure that debug output is not overwritten

There are also a number of separate debug parameters for enabling debugging in specific subsystems e.g. bootmem_debug, sched_debug. Check the kernel parameter documentation for specific information.

Note: If you cannot scroll back far enough to view the desired boot output, you should increase the size of the scrollback buffer.

Recovery shells

Getting an interactive shell at some stage in the boot process can help you pinpoint exactly where and why something is failing. There are several kernel parameters for doing so, but they all launch a normal shell which you can exit to let the kernel resume what it was doing:

rescue launches a shell shortly after the root filesystem is remounted read/write
emergency launches a shell even earlier, before most filesystems are mounted
init=/bin/sh (as a last resort) changes the init program to a root shell. rescue and emergency both rely on systemd, but this should work even if systemd is broken

Another option is to enable debug-shell.service, which adds a root shell on tty9 (accessible with Ctrl+Alt+F9). Take care to disable the service when done to avoid the security risk of leaving a root shell open on every boot.

@@ Line 45: / Line 45: @@
 == Advanced methods ==
-=== netconsole ===
-{{Merge|netconsole|The main article should have complete information for doing this, and it shouldn't be duplicated here.}}
-[[netconsole]] is a kernel module which sends kernel logs over the network, which is useful for debugging slower computers. The setup process is:
-# Set up another computer (running Arch) to accept syslog requests on a remote port using {{ic|syslog.conf}}
-# View the logs using your {{ic|/var/log/everything.log}} file
-# On the computer you are debugging, add a kernel paramter like {{ic|1=netconsole=514@10.0.0.2/12:34:56:78:9a:bc}} (along with whatever debugging parameters you want)
-# Restart the computer and view the logs
-Netconsole can view even more output than the {{ic|1=earlyprintk=vga}} parameter allows, due to its extensive integration in the kernel. See also the [https://www.kernel.org/doc/Documentation/networking/netconsole.txt netconsole documentation].
 == See also ==