Kernel re-compilation is a great challenge for many Linux enthusiasts. I believe that many Linux users often have a misunderstanding about the kernel. They think that common users cannot adjust the kernel. In fact, this recognition is not comprehensive in actual situations. It should be said that kernel re-compilation has a certain depth and complexity, and is also easy to fail the configuration work. Next, I will share my experiences with you so that you can avoid detours.
If you pay attention to the authoritative Linux reference tool books, you will find that many original books describe kernel recompilation as an important chapter. This article will introduce to readers not how to re-compile the Linux kernel step by step, but to collect and sort out several of the most common faults and solutions in the Linux Kernel re-compilation, if you encounter a similar fault during kernel compilation, this article will help you.
Linux Kernel re-compilation Common Faults
Before introducing common Linux kernel recompilation faults, let's assume that we have configured the Linux kernel according to the steps in the reference tool book.
Linux Kernel recompilation usually involves many steps. If you are lucky, the Linux kernel can be re-compiled successfully at one time. If the system prompts an error message when the computer or kernel is started after compilation is complete, the five most likely to appear are: 1. the kernel cannot be started; 2. exception I/O error; 3. slow kernel response; 4. the kernel cannot be compiled correctly. 5. the system restarts again.
Fault Analysis and Solution
The kernel cannot be started.
When we re-create the Linux kernel, we mainly choose the devices and services that the user needs or does not need to use in the system. Starting from the 2.0 kernel, Linux introduced a brand new design feature to the kernel and provided a compromise solution: components can be dynamically and at any time transferred to and called out the kernel. For example, we have to restart the system after modifying/etc/lilo. conf. If your kernel cannot be started and the following information is displayed on the screen:
Warning: unable to open an initial console Kernel panic:
No init found. Try passing init = option to kernel
The biggest possible cause of this error is that we did not provide the parameter correctly to "root =" in/etc/lilo. conf. For example, if there is a configuration method such as root = dev/hdc5 in a Linux system, this is incorrect. The correct one should be root =/dev/hdc5, don't underestimate that there is only one more "/", which is an important parameter provided to the root user. If no "/" is available, the Linux kernel cannot determine where the root node should be started. Many friends often ignore this small detail and cause kernel boot failure. The following shows a correct configuration list for/etc/lilo. conf for your reference only.
/Etc/lilo. conf example
―――――――――――
Boot =/dev/hdc5
Map =/boot/map
Prompt
Timeout = 50
Image =/boot/vmlinuz-2.2.2-1
Label = Linux
Root =/dev/hdc5
Inirtd =/boot/initrd-2.2.2-1.img
Read-only
Other =/dev/hda1
Label = dos
Table =/dev/hda
Abnormal I/O Error
If you re-create a Linux kernel and it can be started correctly, but when using the new kernel, the system often crashes or crashes. It is very likely that I/O problems occur. I/O exceptions not only cause frequent and inexplicable system faults, but also cause the Linux kernel to be downgraded, resulting in a serious decline in the entire system.
The cause of the exception I/O error is that the user did not execute the "make dep clean" step at the end of the Linux kernel compilation. In general, we do not include the "make dep clean" step when saving "menuconfig" or "xconfig" in the Kernel configuration option. Therefore, it is recommended that you check whether the "make dep clean" step has been performed when saving the Kernel configuration option after the configuration.
Slow kernel response
At present, many computers use high-speed CPU and large-capacity memory. Sometimes, after a new kernel is created, the system is much slower than the reflection speed before the kernel is configured. This is probably because you have selected too many options in "menuconfig" or "xconfig" when modifying the Kernel configuration options. This not only makes the computer spend more time compiling the new kernel, but also makes the system occupy too much memory during work. Because a lot of memory is occupied by useless options, this causes the system to run slowly. The solution is very simple. Try to select the options we need. Those useless and too complex options do not need to be modified. Sometimes the default parameters will be better.
The kernel cannot be compiled.
When you enter "make bzImage modules" and press the Input key, the kernel cannot be compiled or other strange phenomena occur. In this case, the best way is to restart the system and then use the "rpm-e" command to remove the Kernel configuration tool Kernel configuration tools. Then re-install the tool (use the "rpm-I" or "rpm-Uvh" command to install it). If the tool can be correctly installed, the problem will be much simpler, at this time, re-configure the kernel and re-compile it. If you still cannot compile the kernel, check whether the hardware device is faulty.