Messages in this thread | | | Date | Tue, 12 Sep 2000 01:41:02 -0700 (PDT) | From | Ion Badulescu <> | Subject | Re: Booting into /bin/bash |
| |
On Tue, 12 Sep 2000, Miquel van Smoorenburg wrote:
> It is a tty, it's just that if you open(2) it, it doesn't become > your _controlling_ tty by default. See drivers/char/tty_io.c (I > think, that's from the top of my head).
Then I guess the kernel doesn't perform the proper setup when it opens /dev/console and then hands it over to init. Indeed, main.c simply opens /dev/console, dup()'s the descriptor twice (for stdout and stderr) and then exec's init.
> You can always force it to become the controlling tty using TIOCSCTTY, > but that is kind of hard in a shell script. But the trick with > reopening stdin/stdout/stderr using /dev/tty1 should work.
I don't want to rely on /dev/tty1. Many of my machines are on serial console, so that would be wrong anyway. The problem is that sometimes there is a problem in the start-up process, and I get a sulogin prompt which I can't even ctrl-d to continue!
Maybe I'll play with main.c and see what happens if I force /dev/console to become the controlling tty for init. Hmm... That could be dangerous for init. Maybe a better idea would be to hack init so that it gives any program started from inittab /dev/console as the controlling tty.
You're the sysvinit maintainer, right? :) What do you think of this idea?
Ion
-- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |