Difference between revisions of "Kernel Panics"

From ArchWiki
Jump to: navigation, search
(Add section "Definition" & "What To Do")
m (Roll back to previous kernel version: fixed url)
(39 intermediate revisions by 19 users not shown)
Line 1: Line 1:
[[Category: System recovery (English)]]
+
[[Category:System recovery]]
[[Category:HOWTOs (English)]]
+
[[Category:Kernel]]
[[Category:Kernel (English)]]
+
[[cs:Kernel Panics]]
 
+
[[el:Kernel Panics]]
{{i18n_links_start}}
+
[[es:Kernel Panics]]
{{i18n_entry|Česky|:Kernel Panics (Česky)}}
+
[[fr:Kernel Panics]]
{{i18n_entry|English|:Kernel Panics}}
+
[[it:Kernel Panics]]
{{i18n_entry|Español|:Kernel Panics (Español)}}
+
[[ja:Kernel Panics]]
{{i18n_entry|Italiano|:Kernel Panics (Italiano)}}
+
[[ro:Kernel panics]]
{{i18n_entry|简体中文|:Kernel Panics (简体中文)}}
+
[[tr:Çekirdek_Sorunları]]
{{i18n_entry|Ελληνικά|:Kernel Panics (Ελληνικά)}}
+
[[zh-CN:Kernel Panics]]
{{i18n_entry|Türkçe|:Çekirdek Hataları}}
+
{{out of date|Last '''major''' update to this page was November 2009.}}
{{i18n_links_end}}
+
This page describes how to repair a computer whose kernel panics at boot. This has to do with the very basic OS kernel and the first part of the boot routine.  (For issues regarding graphical interface problems or program freeze-ups, etc., save yourself some wasted effort and time, and please look elsewhere.)
 
+
This page describes how to repair a computer whose kernel panics at boot.
+
  
 
==Definition==
 
==Definition==
A decent definition of Kernel Panic comes to us from Wikipedia, which states in part; "A kernel panic is an action taken by an operating system upon detecting an internal fatal error from which it cannot safely recover; the term is largely specific to Unix and Unix-like systems. The equivalent in Microsoft Windows operating systems is the Blue Screen of Death." Read more by following this link: [http://en.wikipedia.org/wiki/Kernel_panic Kernal Panic]
+
A decent definition of Kernel Panic comes to us from Wikipedia, which states in part; "A kernel panic is an action taken by an operating system upon detecting an internal fatal error from which it cannot safely recover; the term is largely specific to Unix and Unix-like systems. The equivalent in Microsoft Windows operating systems is the Blue Screen of Death."
 +
{{Wikipedia|Kernel panic}}
  
 
==What To Do==
 
==What To Do==
Basically, the problem is that the operating system doesn't start correctly.  Various behavior may be expressed, such as that one may get the computer to freeze, or the operating system may give an error message of some sort or one may not go to the place they were expecting (Command prompt, Desktop or whathaveyou).  This will require some basic troubleshooting from the command line, if you can boot to it, or from a boot disk if it will get you a commmand prompt or your favorite interface.
+
Basically, the problem is that the operating system doesn't start correctly.  Various behavior may be expressed, such as that one may get the computer to freeze, or the operating system may give an error message of some sort or one may not go to the place they were expecting (Command prompt, Desktop or whathaveyou).  This will require some basic troubleshooting from the command line, if you can boot to it, or from a boot disk if it will get you a command prompt or your favorite interface.
  
 
==Troubleshooting==
 
==Troubleshooting==
To make troubleshooting easier, ensure that the kernel is not in quiet mode. Remove 'quiet' from the kernel line in GRUB if it is. Upon boot, check the output immediately before the panic and decide whether there is any useful information. There are probably too many causes for a kernel panic to keep well-documented in this wiki. Make sure that your system's configuration in /boot is correct and that none of the computer's hardware is faulty - it is good idea to run memtest from the Arch install/rescue CD or another utility (red entries are bad). If you believe the configuration in /boot may be erroneous, try option 1. If you believe the kernel panic is the fault of the kernel itself, follow option 2 in order to install an earlier kernel.
+
To make troubleshooting easier, ensure that the kernel is not in quiet mode. Remove 'quiet' from the kernel line in GRUB, if it is found there. Upon boot, check the output immediately before the panic, and decide whether there is any useful information. There are probably too many causes for a kernel panic to keep well-documented in this wiki. Make sure that your system's configuration in /boot is correct, and that none of the computer's hardware is faulty - it is good idea to run memtest from the Arch install/rescue CD or another utility (red entries are bad). If you believe the configuration in /boot may be erroneous, try Option 1 to repair your bootloader setup. If you believe the kernel panic is the fault of the kernel itself, follow Option 2 in order to reinstall the existing version or an earlier kernel.
  
 
==Option 1: Check bootloader configuration==
 
==Option 1: Check bootloader configuration==
Another possibility is an error in the bootloader's configuration (e.g. <tt>/boot/grub/menu.lst</tt>). For example, repartitioning hard drives can change partitions' order. GRUB users may recall whether repartitioning has occurred recently and make sure the ''root'' and ''kernel'' lines match up with the new partitioning scheme. And examine the file for typos and extraneous characters. An extra space, or character in the wrong place will cause a kernel panic.
+
Another possibility is an error in the [[Boot Loader#Configuration files|bootloader's configuration]]. For example, repartitioning hard drives can change partitions' order. GRUB users may recall whether repartitioning has occurred recently and make sure the ''root'' and ''kernel'' lines match up with the new partitioning scheme. And examine the file for typos and extraneous characters. An extra space, or a character in the wrong place will cause a kernel panic.
  
 
==Option 2: Reinstall kernel==
 
==Option 2: Reinstall kernel==
Line 31: Line 30:
  
 
===Start from the installation CD===
 
===Start from the installation CD===
The first step is booting the installation CD. When started, type arch, like you would when installing arch.
+
The first step is booting the installation CD. Once booted, do not select to login with "arch", like you would when installing arch.  Instead, you'll first want to login with "root".
  # arch
+
  # root
  
===Chroot to your normal root===
+
===Mount your partitions===
 
When booted, you are in a minimal but functional live GNU/Linux environment with some basic tools.
 
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 to /mnt.
+
Now, you have to mount your normal root disk (or partition) to /mnt.
 
  # mount /dev/sdXY /mnt
 
  # mount /dev/sdXY /mnt
If you use a boot partition, don't forget to mount it
+
If you are using legacy IDE setup, 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
 
  # mount /dev/sdXZ /mnt/boot
  
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 autodetection to find out what kernel modules are required for starting up your computer. For this autodetection to work, /dev, /sys and /proc need to mounted in your chroot:
+
===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.
  
# mount -t proc none /mnt/proc
+
===Chroot to your normal root===
# mount -t sysfs none /mnt/sys
+
Now, you will have to chroot to the partition mounted in /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 autodetection to find out what kernel modules are required for starting up your computer. For this autodetection to work, /dev, /sys and /proc need to mounted in your chroot, make sure to read [[Change Root]].
# mount --bind /dev /mnt/dev
+
 
+
Now, we will chroot to this disk:
+
# chroot /mnt
+
  
 
===Roll back to previous kernel version===
 
===Roll back to previous kernel version===
If you keep your downloaded pacman packages, you now can easily roll back. If you didn't keep them, you have to find a way to get a previous kernel version on your system now.
+
If you keep your downloaded pacman packages, you now can easily roll back. If you didn't keep them, you have to [[Downgrading_Packages#Finding_your_older_version|find a way]] to get a previous kernel version on your system now.
 +
 
 +
Let's 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-3*'
  
Let's suppose you keep the previous versions. We will now install the last working one.
+
Now use the kernel details in the command below.
# pacman -U /var/cache/pacman/pkg/kernel26-2.6.23.''xx-x''.pkg.tar.gz
+
Of course, make sure that you adapt this line to your own kernel version.
+
  
Otherwise, check the install CD for a package. For example, the version 2008.06 i686 CD contains addons/core-pkgs/kernel26-2.6.25.6-1-i686.pkg.tar.gz.
+
# pacman -U /var/cache/pacman/pkg/linux-3.''xx-x''.pkg.tar.gz
 +
(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==
 
==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.
 
Now is the time to reboot and see if the system modifications have stopped the panic.
If reverting to an older kernel works, don't forget to check the arch-newspage to check what went wrong with the kernel build.
+
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.

Revision as of 11:40, 19 August 2013

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: Last major update to this page was November 2009. (Discuss in Talk:Kernel Panics#)

This page describes how to repair a computer whose kernel panics at boot. This has to do with the very basic OS kernel and the first part of the boot routine. (For issues regarding graphical interface problems or program freeze-ups, etc., save yourself some wasted effort and time, and please look elsewhere.)

Definition

A decent definition of Kernel Panic comes to us from Wikipedia, which states in part; "A kernel panic is an action taken by an operating system upon detecting an internal fatal error from which it cannot safely recover; the term is largely specific to Unix and Unix-like systems. The equivalent in Microsoft Windows operating systems is the Blue Screen of Death." Template:Wikipedia

What To Do

Basically, the problem is that the operating system doesn't start correctly. Various behavior may be expressed, such as that one may get the computer to freeze, or the operating system may give an error message of some sort or one may not go to the place they were expecting (Command prompt, Desktop or whathaveyou). This will require some basic troubleshooting from the command line, if you can boot to it, or from a boot disk if it will get you a command prompt or your favorite interface.

Troubleshooting

To make troubleshooting easier, ensure that the kernel is not in quiet mode. Remove 'quiet' from the kernel line in GRUB, if it is found there. Upon boot, check the output immediately before the panic, and decide whether there is any useful information. There are probably too many causes for a kernel panic to keep well-documented in this wiki. Make sure that your system's configuration in /boot is correct, and that none of the computer's hardware is faulty - it is good idea to run memtest from the Arch install/rescue CD or another utility (red entries are bad). If you believe the configuration in /boot may be erroneous, try Option 1 to repair your bootloader setup. If you believe the kernel panic is the fault of the kernel itself, follow Option 2 in order to reinstall the existing version or an earlier kernel.

Option 1: Check bootloader configuration

Another possibility is an error in the bootloader's configuration. For example, repartitioning hard drives can change partitions' order. GRUB users may recall whether repartitioning has occurred recently and make sure the root and kernel lines match up with the new partitioning scheme. And examine the file for typos and extraneous characters. An extra space, or a character in the wrong place will cause a kernel panic.

Option 2: Reinstall kernel

Reinstalling the kernel is probably the best bet when no other major system modifications have taken place recently.

Start from the installation CD

The first step is booting the installation CD. Once booted, do not select to login with "arch", like you would when installing arch. Instead, you'll first want to login with "root".

# root

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 /mnt.

# mount /dev/sdXY /mnt

If you are using legacy IDE setup, 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 /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 autodetection to find out what kernel modules are required for starting up your computer. For this autodetection to work, /dev, /sys and /proc need to mounted in your chroot, make sure to read Change Root.

Roll back to previous kernel version

If you keep your downloaded pacman packages, you now can easily roll back. If you didn't keep them, you have to find a way to get a previous kernel version on your system now.

Let's 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-3*'

Now use the kernel details in the command below.

# pacman -U /var/cache/pacman/pkg/linux-3.xx-x.pkg.tar.gz

(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 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.