> In article <cistron.Pine.LNX.3.95.981112110352.4114A-100000@chaos.analogic.com>,
> Richard B. Johnson <root@chaos.analogic.com> wrote:
> >At the LILO prompt hit ALT
> >Then at the boot prompt..
> > linux init=/bin/bash
> >
> >Once you are through, do `exec /sbin/init`. This will startup
> >init, still with pid 1, and you are through (unless you need to
> >sort out junk in /lost+found).
>
> Alas not. If you pass init=/what/ever, the kernel starts an
> internal pseudo init and starts the /what/ever as a child (usually
> it has PID 8 or so).
>
> Perhaps a new command is needed .. init= and shell= or so.
The problem is that current kernels start init, be it /{sbin,bin,etc}/init
or whatever was passed as init= argument as PID 1. But PID 1 has several
special properties like the priviledge of ignoring any signal it wants to
ignore or adopting any orphaned process. One of the nervragging funnies
with that is that that bash will ignore signals like sent from <CTRL>-C.
2.0 did had this a bit luckier, it only tried to run init as PID 1. The
other things is that of course a system without a real init process is
somewhat wrecked.
Other things which has been changed from 2.0 is that the kernel no longer
tries the traditional UNIX V7 style system initialialisation via /etc/rc
which at times was convenient for machines with a lean special purpose
setup; 2.0 also tried to run /bin/sh or a command line supplied command
in an endless loop. I personally prefer the 2.0 behaviour but apparently
Linus decieded otherwise.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/