https://www.kernel.org/doc/html/latest/admin-guide/init.html
Explaining the dreaded “No init found.” boot hang message Explain the dreaded "No init found." Boot hang message.
OK, so you’ve got this pretty unintuitive message (currently located in init/main.c) and are wondering what the H*** went wrong. Some high-level reasons for failure (listed roughly in order of execution) to load the init binary are:
OK, you've received this rather non-intuitive message (currently located in init / main.c) and you're wondering what H *** went wrong. There are several high-level reasons why I failed to load the init binary (this list is roughly in order of execution):
A. Unable to mount root FS B. init binary doesn’t exist on rootfs C. broken console device D. binary exists but dependencies not available E. binary cannot be loaded
A. Could not mount root FS. B. The init binary did not exist in rootfs. C. console device is corrupted D. binary exists, but the ones it depends on are not valid E. could not load binary.
Detailed explanations:
I will explain the details.
A. Set “debug” kernel parameter (in bootloader config file or CONFIG_CMDLINE) to get more detailed kernel messages.
Set the kernel parameter to "debug" to get a more detailed kernel message (you can do this in the bootloader config file or in CONFIG_CMDLINE)
B. make sure you have the correct root FS type (and root= kernel parameter points to the correct partition), required drivers such as storage hardware (such as SCSI or USB!) and filesystem (ext3, jffs2 etc.) are builtin (alternatively as modules, to be pre-loaded by an initrd)
Must be the correct root FS type (and root = kernel parameter points to the correct location), have storage hardware (SCSI, USB, etc.), and have a built-in filesystem (ext3, jffs2, etc.) (or Make sure that it is pre-loaded with initrd as a module).
C. Possibly a conflict in console= setup –> initial console unavailable. E.g. some serial consoles are unreliable due to serial IRQ issues (e.g. missing interrupt-based configuration). Try using a different console= device or e.g. netconsole=.
Probably the console that conflicts with console = setup –> initial is not available. For example, due to serial IRQ issues (for example, interrupt-based configurations do not exist), some serial consoles are unreliable. Use another console = device, for example netconsole =.
D. e.g. required library dependencies of the init binary such as /lib/ld-linux.so.2 missing or broken. Use readelf -d
|grep NEEDED to find out which libraries are required.
For example, the library required by init binary, such as /lib/ld-linux.so.2, may not exist or may be corrupted. Use readelf -d
E. make sure the binary’s architecture matches your hardware. E.g. i386 vs. x86_64 mismatch, or trying to load x86 on ARM hardware. In case you tried loading a non-binary file here (shell script?), you should make sure that the script specifies an interpreter in its shebang header line (#!/...) that is fully working (including its library dependencies). And before tackling scripts, better first test a simple non-script binary such as /bin/sh and confirm its successful execution. To find out more, add code to init/main.c to display kernel_execve()s return values.
Make sure the E. binary architecture matches your hardware. For example, there may be an inconsistency between i386 and x86_64, or you may be trying to load x86 on ARM hardware. If you are trying to load a non-binary file (shell script?), Specify an interpreter where the script is fully functional (including library dependencies) on its shebang header line (#! / ...) You need to make sure that you are. Also, before working on the script, it's a good idea to first test it with a simple non-script like / bin / sh to make sure it can be run. To see the details, add the code in init / main.c and display the return value of kernel_execve ().
Please extend this explanation whenever you find new failure causes (after all loading the init binary is a CRITICAL and hard transition step which needs to be made as painless as possible), then submit patch to LKML. Further TODOs:
Extend this description if you find a new cause of failure. (Loading the entire init binary is important and hard transition stepd, so it should be as simple as possible). Then send the patch to LKML. Other TODO:
・ Implement the various run_init_process () invocations via a struct array which can then store the kernel_execve () result value and on failure log it all by iterating over all results (very important usability fix).
Various run_init_process () calls are implemented via a struct array. This allows you to save the return value of kernel_execve () and log it all by repeating it with all the results in case of failure (very important and easy to use).
・ Try to make the implementation itself more helpful in general, e.g. by providing additional error messages at affected places.
• In general, try to make the implementation itself more useful. For example, providing additional error messages where affected.
Andreas Mohr ＜andi at lisas period de＞
Originally, it is a part of the Linux Kernel source code, so it will be treated as GPLv2 (recognition that it should be).
https://www.kernel.org/doc/html/latest/index.html
Licensing documentation
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing
Recommended Posts