You are not logged in.
Okay, in times of old it was possible to pass the kernel an argument "init=/some/path/to/an/executable" in order to make it run something other than init. Nowadays, the kernel assumes the next thing in the chain is going to be kinit, so it passes it a special argument. Unfortunately, this argument will upset almost any other program.
Is there some way to give kinit the location of the next program to run (normally /sbin/init, I think) after early userspace? If not, is there some way to stop the kernel from passing the special argument?
Cheers.
Offline
Uhm, that looks like stupid kinit bug. It simply passes all options to the new init (in this case to /bin/bash). bash doesn't like that and quits, which results in "attempting to kill init". I'll see what we can do about that.
Offline
Right, cheers. I had a look in the kinit source code and you're correct. In fact, the code contains the traditional list order of programs to run as init - including /bin/sh as a last resort. However, it will always pass arguments to /bin/sh that will make it crash. So much for testing! So does the kernel not touch init=foo now, or does it just end up not evaluating it if you're using an image as part of the boot sequence? I am confused. Is there any documentation that explains all of this in detail?
As for the bug, I guess I won't bother reporting it if you're sorting it out.
Offline