Explaining the “No working init found.” boot hang message

Authors:Andreas Mohr <andi at lisas period de>Cristian Souza <cristianmsbr at gmail period com>

This document provides some high-level reasons for failure(listed roughly in order of execution) to load the init binary.

  1. Unable to mount root FS: Set “debug” kernel parameter (in bootloaderconfig file or CONFIG_CMDLINE) to get more detailed kernel messages.
  2. init binary doesn’t exist on rootfs: Make sure you have the correctroot FS type (androot= kernel parameter points to the correctpartition), required drivers such as storage hardware (such as SCSI orUSB!) and filesystem (ext3, jffs2, etc.) are builtin (alternatively asmodules, to be pre-loaded by an initrd).
  3. Broken console device: Possibly a conflict inconsole=setup–> initial console unavailable. E.g. some serial consoles are unreliabledue to serial IRQ issues (e.g. missing interrupt-based configuration).Try using a differentconsole=device or e.g.netconsole=.
  4. Binary exists but dependencies not available: E.g. required librarydependencies of the init binary such as/lib/ld-linux.so.2 missing orbroken. Usereadelf-d<INIT>|grepNEEDED to find out which librariesare required.
  5. Binary cannot be loaded: Make sure the binary’s architecture matchesyour hardware. E.g. i386 vs. x86_64 mismatch, or trying to load x86 on ARMhardware. In case you tried loading a non-binary file here (shell script?),you should make sure that the script specifies an interpreter in itsshebang header line (#!/...) that is fully working (including itslibrary dependencies). And before tackling scripts, better first test asimple non-script binary such as/bin/sh and confirm its successfulexecution. To find out more, add codetoinit/main.c to displaykernel_execve()s return values.

Please extend this explanation whenever you find new failure causes(after all loading the init binary is a CRITICAL and hard transition stepwhich needs to be made as painless as possible), then submit a patch to LKML.Further TODOs:

  • Implement the variousrun_init_process() invocations via a struct arraywhich can then store thekernel_execve() result value and on failurelog it all by iterating overall results (very important usability fix).
  • Try to make the implementation itself more helpful in general, e.g. byproviding additional error messages at affected places.