> On Thu, Nov 12, 1998 at 08:39:53PM +0100, Miquel van Smoorenburg wrote:
>
> > 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).
Alas yes. I wish you would try this stuff before you argue.
The exec command overwrites the parent, which used to be bash, with
the new image of init. It maintains the same PID, 1, which is why
it works. And this is not supposition. It is supposed to work that
way and it does work that way.
> >
> > 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.
>
For the commands necessary to fix a disk, the fact that Ctrl-C doesn't
work is of no consequence.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.127 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
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/