init drops to non-1 pid

[Erik Andersen <andersen@codepoet.org>]

This is in fact a kernel thing and the kernel has been this way for a _long_
time.  You are obviously running dbootstrap as an initrd.  When the kernel runs
an initrd, the init process is still sleeping in kernel space, and the process
executing user space stuff is just another kernel thread, and <em>will not be
pid 1</em>.  If you look in the kernel's init/main.c you will see the last
function in start_kernel() is rest_init() which calls

    kernel_thread(init, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGNAL);

which is where pid 1 gets claimed.  It just sits there sleeping in kernel space
for a while.  Later on, after some unpredictable number of other kernel threads
have started, and before the init process (pid 1) calls exec and moves itself
into user space, we see yet another kernel thread getting started:

    pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD);

and do_linuxrc() calls exec, which moves this process into user space with some
pid that is never going to be pid 1.  It is from within this kernel thread that
initrds run, and in this case busybox init is being executed.  There is nothing
that busybox can do about the broken way that initrds are run except cope, I do
have BB_FEATURE_LINUXRC which causes busybox to never assume init is pid 1 and
cope with several other ugly things.  I disabled that in my last busybox update since the boot floppies are not running as initrds.   

Al Viro is fixing things so that in the future initrds and all the evil they
involve, will be going away -- but that will be for 2.5.x...  So for now, if
any part of the boot floppies assume that init=pid 1 then those things will
simply need to be fixed.  Or we need to not use initrds (which is the case with
other architecures).

So I have to wonder, why is your bootloader and kernel set to run things as an
initrd?  Your kernel should have CONFIG_BLK_DEV_INITRD disabled, and/or your
bootloader should set root=/dev/ram0.   This will cause the bootloader to set
up the kernel ramdisk, but then, instead of the kernel running things within
the initrd abomination, it will run from a normal filesystem that just happens
to be the ramdisk set up by the bootloader....

I'd prefer it if we can avoid re-enabling the BB_FEATURE_LINUXRC option.  Can
sparc and its boot method cope what I describe above?

 -Erik

--
Erik B. Andersen   email:  andersee@debian.org, formerly of Lineo
--This message was written using 73% post-consumer electrons--