On 20/6/06 8:09 AM, "Samuel Thibault" <[email protected]> wrote:
> linux-os (Dick Johnson), le Mon 19 Jun 2006 07:37:02 -0400, a écrit :
>> You can't allow some terminal input to affect init. It has been the
>> de facto standard in Unix, that the only time one should have a
>> controlling terminal is after somebody logs in and owns something to
>> control.
>
> Ok. The following still makes sense, doesn't it? (i.e. set a session for
> the emergency shell)
>
> --- linux-2.6.17-orig/init/main.c 2006-06-18 19:22:40.000000000 +0200
> +++ linux-2.6.17-perso/init/main.c 2006-06-20 00:07:07.000000000 +0200
> @@ -729,6 +729,11 @@
> run_init_process("/sbin/init");
> run_init_process("/etc/init");
> run_init_process("/bin/init");
> +
> + /* Set a session for the shell. */
> + sys_setsid();
> + sys_ioctl(0, TIOCSCTTY, 1);
> +
> run_init_process("/bin/sh");
>
> panic("No init found. Try passing init= option to kernel.");
What if people are booting via /bin/sh and then setting up
their custom chroot's and init(s), and don't want these init(s) to
be part of a session?
It is also particularly possible for an embedded system to start
up via /bin/sh running /etc/profile rather than using an init type
program.
Also, the above doesn't help people specifying "init=/bin/sh" on the
command line (as per the original post subject). The real solution
is for them to specify a different init= or run/exec something to set
up their tty and session once logged in.
David.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
