Difference between revisions of "Kernel Panics"

From ArchWiki
Jump to: navigation, search
(Start from the installation CD: Deleted section.)
m (redirect to where it was merged)
 
(11 intermediate revisions by one other user not shown)
Line 1: Line 1:
[[Category:System recovery]]
+
#redirect [[General troubleshooting#Kernel panics]]
[[Category:Kernel]]
 
[[cs:Kernel Panics]]
 
[[el:Kernel Panics]]
 
[[es:Kernel Panics]]
 
[[fr:Kernel Panics]]
 
[[it:Kernel Panics]]
 
[[ja:カーネルパニック]]
 
[[ro:Kernel panics]]
 
[[tr:Çekirdek Sorunları]]
 
[[zh-hans:Kernel Panics]]
 
{{out of date|Last '''major''' update to this page was November 2009.}}
 
{{Merge|General troubleshooting|If you remove all the excess verbosity and duplicate instructions, a few paragraphs remain which can go to [[General troubleshooting]]}}
 
A ''kernel panic'' occurs when the Linux kernel enters an unrecoverable failure state. The state typically originates from buggy hardware drivers resulting in the machine being deadlocked, non-responsive, and requiring a reboot. Just prior to deadlock, a diagnostic message is generated, consisting of: the ''machine state'' when the failure ocurred, a ''call trace'' leading to the kernel function that recognized the failure, and a listing of currently loaded modules. Thankfully, kernel panics don't happen very often using ''mainline'' versions of the kernel--such as those supplied by the official repositories--but when they do happen, you need to know how to deal with them.
 
 
{{Note|Kernel panics are sometimes referred to as ''oops'' or ''kernel oops''.  While both panics and oops occur as the result of a failure state, an ''oops'' is more general in that it does not ''necessarily'' result in a deadlocked machine--sometimes the kernel can recover from an oops by killing the offending task and carrying on.}}
 
 
 
{{Tip|Pass the kernel parameter {{ic|1=oops=panic}} at boot or write {{ic|1}} to {{ic|/proc/sys/kernel/panic_on_oops}} to force a recoverable oops to issue a panic instead.  This is advisable is you are concerned about the small chance of system instability resulting from an oops recovery which may make future errors difficult to diagnose.}}
 
 
 
==Option 2: Reinstall kernel==
 
Reinstalling the kernel is probably the best bet when no other major system modifications have taken place recently.
 
 
 
===Mount your partitions===
 
When booted, you are in a minimal but functional live GNU/Linux environment with some basic tools.
 
Now, you have to mount your normal root disk (or partition) to {{ic|/mnt}}.
 
# mount /dev/sdXY /mnt
 
 
 
If you are using legacy IDE drives, then use the command:
 
# mount /dev/hdXY /mnt
 
 
 
If you use a separate boot partition, do not forget to mount it with:
 
# mount /dev/sdXZ /mnt/boot
 
 
 
===Gather your files for later troubleshooting===
 
This is a good point to stop and gather your information onto another drive or partition so that it can be analyzed and/or emailed for outside viewing before the files change again.  Simply create a separate directory on your main partition or mount a USB drive to contain the files.  Then you may copy any files you will need to keep unchanged during the next boot with your new kernel.
 
 
 
===Chroot to your normal root===
 
Now, you will have to chroot to the partition mounted in {{ic|/mnt}}. Newer kernels use an initial ramdisk to set up the kernel environment: when you reinstall a kernel, that initial ramdisk will be regenerated with [[mkinitcpio]]. One of mkinitcpio's features is that it does automatic detection to find out what kernel modules are required for starting up your computer. For this autodetection to work, {{ic|/dev}}, {{ic|/sys}}, and {{ic|/proc}} need to mounted in your chroot; make sure to read [[Change root]].
 
 
 
To chroot to your normal root mounted at {{ic|/mnt}}, run this command:
 
# arch-chroot /mnt /bin/bash
 
 
 
If you do not want to use the [[Bash]] shell, remove {{ic|/bin/bash}} from the {{ic|arch-chroot}} command.
 
 
 
{{Note|You need the {{Pkg|arch-install-scripts}} package in order to use {{ic|arch-chroot}}.}}
 
 
 
===Roll back to previous kernel version===
 
If you keep your downloaded pacman packages, you now can easily roll back. If you did not keep them, you have to [[Downgrading packages#Finding_your_older_version|find a way]]{{Broken section link}} to get a previous kernel version on your system now.
 
 
 
Let us suppose you kept the previous versions. We will now install the last working one.
 
 
 
First, you need to get the kernel details:
 
# find /var/cache/pacman/pkg -name 'linux-4*'
 
 
 
Now, use the kernel details in the command below.
 
 
 
# pacman -U /var/cache/pacman/pkg/linux-4.''xx-x''.pkg.tar.xz
 
(Of course, make sure that you adapt this line to your own kernel version.  You can find the ones you still have in your cache by examining the directory above.)
 
 
 
==Reboot==
 
{{Note|If you choose to do anything else before you reboot, remember that you are still in the chroot environment and will likely have to exit and login again.}}
 
Now is the time to reboot and see if the system modifications have stopped the panic.
 
If reverting to an older kernel works, do not forget to [https://www.archlinux.org/news/ check the arch-newspage] to check what went wrong with the kernel build.  If there is no mention of the problem there, then go to the bug reporting area and search for it there.  If you still do not find it, open a new bug report and attach those files you saved during the troubleshooting step above.
 

Latest revision as of 06:27, 18 October 2017