Tips to effectively deal with Linux kernel panic

Thanks to netizen 墢一雨音 for the contribution

There is a reason for writing this article. In order to configure a completely silent boot, I performed improper mkinitcpio operations on Linux running on my work computer because I ignored a logic error in the mkinitcpio.conf file. This causes mkinitcpio to produce a new kernel file, but this kernel file does not work properly. When restarting, the kernel startup aborts in the Panic state.

Generally, when the new kernel does not work properly, you can temporarily start the system by using the fallback version of the initramfs kernel file, or even directly overwrite the fallback version to roll back the changes, but this time, mkinitcpio is running at the same time The vmlinuz kernel file has been modified, and vmlinuz does not have a fallback version. For ordinary users, they can directly reinstall the system; however, the author's workstation environment configuration is quite complicated, which means that in addition to the possible loss of my working files, I also need to spend a lot of extra time to reconfigure the development environment.

Note: The "repair" of this tutorial refers to "attempting to roll back devastating human changes", so it cannot be used to recover from unknown kernel crashes.

1. Boot from LiveCD and view the disk

Based on the experience accumulated during my part-time Linux server operation and maintenance period, I immediately thought that I could use LiveCD to boot to obtain a temporary Linux environment for repairing the kernel.

The author is using the 64-bit version of Arch Linux, so I booted from the LiveCD of Arch Linux. After correctly entering the built-in root user of LiveCD, we need to check the device name of our main hard disk. Execute fdisk -l. In my case, the device file corresponding to my main hard disk and the partition mounted to the root directory is /dev/sdb2.

2. chroot to the system root directory on the hard disk

To chroot to the system root directory on the hard disk and be able to normally call the system components on the hard disk to make changes to the system on the hard disk, we must first manually mount the root partition on the hard disk. Execute (my device file is /dev/sdb2):

mount /dev/sdb2 /mnt

Don’t rush yet. At this time, although you can enter the bash of the main system on the hard disk by chrooting to /mnt, you can hardly complete any complex tasks correctly because there are still some important directories that are not mounted. We execute the instructions to mount the proc directory, /sys directory, /dev directory and /run directory respectively. Enter /mnt and execute respectively:

mount -t proc proc proc/

mount --rbind /sys sys/

mount --rbind /dev dev/

mount --rbind /run run/

The functions of these directories are:

proc directory: Virtual, Procfs format file system, used to store process status files (under Linux, these files appear to be text files on the surface, but are actually file mappings of the process status) );

/sys directory: For Arch Linux, this is a virtual file system in Sysfs format similar to the proc directory, used to store device files connected to the system; for traditional Unix and Unix-like, it Is a soft link pointing to the kernel code tree;

/dev directory: stores device files, for example, your hard disk is /dev/sdXY;

/run directory: stores part of the system information after the latest startup;

After mounting these things, we can chroot to the root directory of our main hard disk:

chroot /mnt

Regret medicine. For me, I only needed to modify the mkinitcpio.conf file and re-execute the mkinitcpio operation to regenerate the correct kernel file. Generally, if the kernel panic is caused by incorrectly modifying the configuration, this environment can solve most problems.

3. Some skills

1. Many configuration files have correct versions or templates for the system in the LiveCD. If you don’t remember what they look like normally, you can refer to them;

2. For Arch Linux, you can directly use the pacstrap command to manage software packages on the /mnt mount point without chrooting to /mnt;

3. It can be operated under two ttys, so that after chrooting to /mnt, files can still be transferred from the LiveCD file system to /mnt.

This tutorial should be available for most Linux distributions, and I hope it will be helpful to some Linux users.

related suggestion:

How to configure dual graphics cards in Linux system?

The above is the detailed content of Tips to effectively deal with Linux kernel panic. For more information, please follow other related articles on the PHP Chinese website!