Messages in this thread | | | Date | Tue, 20 Jun 2006 10:02:23 +1000 | Subject | Re: emergency or init=/bin/sh mode and terminal signals | From | David Luyer <> |
| |
On 20/6/06 8:09 AM, "Samuel Thibault" <samuel.thibault@ens-lyon.org> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |