[Techtalk] problem loading a kernel

[Almut Behrens]

On Mon, Sep 03, 2001 at 01:58:06PM -0700, Rajiv Saxena wrote:
> Hi,
> 
> I am trying to load a kernel using a ramdisk.
> But it hangs trying to load the init process.
> 
> Here's the error text:
>
> <snipped boot log>

Hi,

not sure whether you've solved the problem in the meantime... If so,
just consider this as my contribution against the quietness -- even
better if it helps... :)

AFAICT from the boot log you provided, there doesn't seem to be any
problem up to the point where your init is supposed to be started.

The kernel uses the execve() system call to start the init process
or some shell (execve is one of the six exec-functions - the lowest
level one, actually - but the differences are mostly irrelevant here).
Independently of what does go wrong here, you would always get the
same kernel panic message "No init found.". Things that can go wrong
are basically the same things that can go wrong when you try to start
any progam from the commandline. In the most simple case, this could
be that the executable bit isn't set, or that some dynamic libs fail
loading, or that the binary format (e.g. ELF) is not supported, etc.

I assume you do have the executable bit set, and normally the sash
should be linked statically, so there *should* be no issue with
loading libraries... (after all, the "stand alone" aspect is the
main purpose of using the sash). But who knows where you got that
sash from, and if it's been built properly -- so you might want to
be paranoid and check with ldd whether there really aren't any
dependencies.

Another coarse test would be to mount your ramdisk image somewhere,
and do a chroot to that directory (because of absolute paths).
Then, see if you can run your /bin/init (sash) in that chroot-ed
environment.
If that works, this doesn't necessarily mean that it would work at
boot time. OTOH, if that already fails, the kernel will certainly
have the same problem.

Something else to try would be to mess around with the kernel source
and temporarily add a few debug print-statements to yield some more
info about why the execve() fails.
The relevant code fragment is at the end of init/main.c:

  if (execute_command)
          execve(execute_command,argv_init,envp_init);
  execve("/sbin/init",argv_init,envp_init);
  execve("/etc/init",argv_init,envp_init);
  execve("/bin/init",argv_init,envp_init);
  execve("/bin/sh",argv_init,envp_init);
  panic("No init found.  Try passing init= option to kernel.");

Due to the very nature of the exec-functions, they do not return
upon success, so normally the panic statement will never be reached.
If the execve() fails, though, it returns -1 and sets the global
"errno". If all exec attempts fail, execution will "fall through" to
the panic(). Printing out the errno might give you at least some hint
as to what's going wrong. Use printk() instead of the usual printf(),
for example something like:

  if (execute_command)
          execve(execute_command,argv_init,envp_init);
  printk("execve(custom init) failed: errno = %d\n", errno); /* debug */
  execve("/sbin/init",argv_init,envp_init);
  printk("execve(/sbin/init) failed: errno = %d\n", errno);
  execve("/etc/init",argv_init,envp_init);
  printk(... etc. ...);
  execve("/bin/init",argv_init,envp_init);
  execve("/bin/sh",argv_init,envp_init);
  panic("No init found.  Try passing init= option to kernel.");

(in case the symbol errno isn't known, just "#include <linux/errno.h>")
For an interpretation of the errno's you'll get, see "man execve",
"man errno", or take a look at the errno.h header file(s).


> 
> Do I need to have all the libraries in /lib?
> 

Normally, you only need to provide the libs that are actually being
used -- again, use "ldd" to check what your binaries require...

Good luck,

- Almut