This page has been converted from the Fedora Project Wiki and cleaned up for publishing here on the Fedora Docs Portal, but it has not yet been reviewed for technical accuracy. This means any information on this page may be outdated or inaccurate. Reviews for technical accuracy are greatly appreciated. If you want to help, see the README file in the source repository for instructions.
The kernel, like any software, has bugs. It’s a large, complex project and it can be difficult to troubleshoot problems. This document covers some basic troubleshooting techniques to help narrow down the root cause of an issue.
Sometimes the kernel fails to boot. Depending on where the problem is in the boot process, there may or may not be any output. Some good first steps are:
quiet(enable more log messages) and
rhgb(disable graphical boot) from the boot flags. If the text output is too fast to read, add
boot_delay=1000(the number of milliseconds to delay in between printk during boot). You can use a camera to take pictures of the output.
Booting with vga=791 (or even just vga=1 if the video card won’t support 791) will put the framebuffer into high resolution mode to get more lines of text on screen, allowing more context for bug analysis.
initcall_debugparameter, which traces the initcalls as they are executed.
If you get no output at all from the kernel, booting with
earlyprintk=vgacan sometimes yield something of interest.
Checking whether or not the CapsLock key (or NumLock or ScrollLock) causes the light on the keyboard to change state can be used as an indication of whether or not the kernel has hung completely, or if there is something else going on.
The SysRq magic keys may still work. You may need to add
sysrq_always_enabled=1to the kernel boot command line. See the wiki article on SysRq on usage details.
nmi_watchdog=1on the kernel command line will cause a panic when an NMI watchdog timeout occurs.
When reporting an issue with the kernel you should always attach the kernel
logs, usually collected with the
dmesg command. For some types of issues,
you may need to collect more logs.
Information for collecting logs is documented at the libinput website.
If the problem you’ve encountered isn’t present in older versions of the
kernel, it is very helpful to use
git-bisect to find the commit that
introduced the problem. For a general overview of
git-bisect, see its
documentation. An outline on how to bisect
the kernel is included in the
documentation. This guide contains Fedora-specific details.
Bisecting is a time-consuming task, but it’s very straightforward and is often the best way to find the cause of a problem. If you’re really interested in getting the problem you’re seeing fixed, bisecting will speed up the process considerably in most cases.
Find the newest version you can that works. This will be the initial "good" version. The first version you find that doesn’t work will be the initial "bad" version.
Install the build-custom-kernel.adoc#get-the-dependencies required to build the kernel.
.configfile. Assuming you’ve got both the good and bad kernel installed, the config for both will be in
Start a new
git bisect start.
Mark the newest version that works as "good" with
git bisect good <tag>. For example:
git bisect good v4.16.8.
Mark the first version that does not work as "bad" with
git bisect bad <tag>. For example:
git bisect bad v4.17.
build-custom-kernel.adoc#building-the-kernel. Sometimes commits cannot be built. If this happens, skip the commit with
git bisect skip.
Reboot into the new kernel and test to see if it works.
If the new kernel works, mark it as good with
git bisect good. Otherwise, mark it as bad with
git bisect bad.
Repeat the previous five steps until you’ve found the commit that introduced the problem.
v4.15) new configuration options will be added and removed as you bisect. It’s usually safe to select the default.