mirros/rockchip-kernel
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: admin-guide: Clarify sentences

Browse Source 
Changes to make the text more formal and organized. The reasons are now cited and described at the same time.
Minor grammatical problems have also been fixed.

Signed-off-by: Cristian Souza <cristianmsbr@gmail.com>
Link: https://lore.kernel.org/r/20200411010201.GA22706@darkstar
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Cristian Souza
2020-04-10 22:02:01 -03:00
committed by Jonathan Corbet
parent d8e8ff1fe3
commit 7dbffd3f84
1 changed files with 33 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

70
Documentation/admin-guide/init.rst
View File

@@ -1,52 +1,48 @@
Explaining the dreaded "No init found." boot hang message Explaining the "No working init found." boot hang message
========================================================= =========================================================
:Authors: Andreas Mohr <andi at lisas period de>
Cristian Souza <cristianmsbr at gmail period com>
OK, so you've got this pretty unintuitive message (currently located This document provides some high-level reasons for failure
in init/main.c) and are wondering what the H*** went wrong. (listed roughly in order of execution) to load the init binary.
Some high-level reasons for failure (listed roughly in order of execution)
to load the init binary are:
A) Unable to mount root FS 1) **Unable to mount root FS**: Set "debug" kernel parameter (in bootloader
B) init binary doesn't exist on rootfs config file or CONFIG_CMDLINE) to get more detailed kernel messages.
C) broken console device
D) binary exists but dependencies not available
E) binary cannot be loaded
Detailed explanations: 2) **init binary doesn't exist on rootfs**: 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).
A) Set "debug" kernel parameter (in bootloader config file or CONFIG_CMDLINE) 3) **Broken console device**: Possibly a conflict in ``console= setup``
to get more detailed kernel messages. --> initial console unavailable. E.g. some serial consoles are unreliable
B) make sure you have the correct root FS type due to serial IRQ issues (e.g. missing interrupt-based configuration).
(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)
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=``. Try using a different ``console= device`` or e.g. ``netconsole=``.
D) e.g. required library dependencies of the init binary such as
``/lib/ld-linux.so.2`` missing or broken. Use 4) **Binary exists but dependencies not available**: E.g. required library
``readelf -d <INIT>|grep NEEDED`` to find out which libraries are required. dependencies of the init binary such as ``/lib/ld-linux.so.2`` missing or
E) make sure the binary's architecture matches your hardware. broken. Use ``readelf -d <INIT>|grep NEEDED`` to find out which libraries
E.g. i386 vs. x86_64 mismatch, or trying to load x86 on ARM hardware. are required.
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 5) **Binary cannot be loaded**: Make sure the binary's architecture matches
header line (``#!/...``) that is fully working (including its library your hardware. E.g. i386 vs. x86_64 mismatch, or trying to load x86 on ARM
dependencies). And before tackling scripts, better first test a simple hardware. In case you tried loading a non-binary file here (shell script?),
non-script binary such as ``/bin/sh`` and confirm its successful execution. you should make sure that the script specifies an interpreter in its
To find out more, add code ``to init/main.c`` to display kernel_execve()s shebang header line (``#!/...``) that is fully working (including its
return values. 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.
Please extend this explanation whenever you find new failure causes Please extend this explanation whenever you find new failure causes
(after all loading the init binary is a CRITICAL and hard transition step (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. which needs to be made as painless as possible), then submit a patch to LKML.
Further TODOs: Further TODOs:
- Implement the various ``run_init_process()`` invocations via a struct array - Implement the various ``run_init_process()`` invocations via a struct array
which can then store the ``kernel_execve()`` result value and on failure which can then store the ``kernel_execve()`` result value and on failure
log it all by iterating over **all** results (very important usability fix). log it all by iterating over **all** results (very important usability fix).
- try to make the implementation itself more helpful in general, - Try to make the implementation itself more helpful in general, e.g. by
e.g. by providing additional error messages at affected places. providing additional error messages at affected places.
Andreas Mohr <andi at lisas period de>