From: Rob L. <ro...@la...> - 2005-09-23 16:35:45
|
I'm the strange guy using UML via the stdio console, ala: ./linux rootfstype=hostfs MEM=48m rw init=/bin/sh LD_ASSUME_KERNEL=2.4.1 And it would be very nice if ctrl-c would work with that. I tried commenting out the "!noctty &&" test in line 1872, but it didn't make any difference. Anybody see an obvious way to make /dev/console a controlling TTY? Rob |
From: Blaisorblade <bla...@ya...> - 2005-09-23 18:19:30
|
On Friday 23 September 2005 18:35, Rob Landley wrote: > I'm the strange guy using UML via the stdio console, ala: > > ./linux rootfstype=hostfs MEM=48m rw init=/bin/sh Ah, init=/bin/sh, that's why you have /dev/console. I feared somebody again using /dev/console in inittab. > LD_ASSUME_KERNEL=2.4.1 > And it would be very nice if ctrl-c would work with that. I tried > commenting out the "!noctty &&" test in line 1872, but it didn't make any > difference. > Anybody see an obvious way to make /dev/console a controlling TTY? Guess that /dev/console is not a TTY, so that it not possible. I mean, you'd have to patch (uselessly) the very TTY core layer. Or make Linux use /dev/tty0 instead of /dev/console when starting init - which is simpler. There is maybe even a console= switch What about something like init="kludgy script which calls, say, a mixture of setsid, <> /dev/tty0, open(1) and such stuff to make sh start? Maybe sh doesn't even need that, but login(8) needs setsid. I never remember the exact combination, however. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com |
From: Rob L. <ro...@la...> - 2005-09-23 18:31:58
|
On Friday 23 September 2005 11:35, Rob Landley wrote: > I'm the strange guy using UML via the stdio console, ala: > > ./linux rootfstype=hostfs MEM=48m rw init=/bin/sh LD_ASSUME_KERNEL=2.4.1 > > And it would be very nice if ctrl-c would work with that. I tried > commenting out the "!noctty &&" test in line 1872, Of drivers/char/tty_io.c, that is > but it didn't make any > difference. > > Anybody see an obvious way to make /dev/console a controlling TTY? > > Rob Rob |
From: Henrik N. <um...@hn...> - 2005-09-23 18:56:39
|
On Fri, 23 Sep 2005, Rob Landley wrote: >> Anybody see an obvious way to make /dev/console a controlling TTY? The user-space process who wants it as a controlling tty needs to run ioctl(0, TIOCSCTTY, (void *) 1); You should also take care to set up the termios parameters correctly. At http://marasystems.com/download/ctty/ you can find a little tool we use in embedded systems making /dev/console a controlling TTY. We use from inittab in the main console entries (single and console). ls:S:wait:ctty ash sh:0123456:respawn:ctty console (console is our console command line program) Regards Henrik |
From: Rob L. <ro...@la...> - 2005-09-24 14:44:05
|
On Friday 23 September 2005 13:56, Henrik Nordstrom wrote: > On Fri, 23 Sep 2005, Rob Landley wrote: > >> Anybody see an obvious way to make /dev/console a controlling TTY? > > The user-space process who wants it as a controlling tty needs to run > > ioctl(0, TIOCSCTTY, (void *) 1); > > You should also take care to set up the termios parameters correctly. > > At http://marasystems.com/download/ctty/ you can find a little tool we use > in embedded systems making /dev/console a controlling TTY. We use from > inittab in the main console entries (single and console). So I fire up UML: ./linux rootfstype=hostfs rw init=/bin/sh LD_ASSUME_KERNEL=2.4.1 And I run the above program "./ctty /bin/sh" And I get: sh-3.00# ./ctty /bin/sh idr_remove called for id=5 which is not allocated. 08b77930: [<080fe55f>] sub_remove+0xef/0x100 08b77990: [<080fe59f>] idr_remove+0x2f/0xc0 08b779b0: [<08107282>] release_dev+0x5d2/0x6f0 08b77a30: [<08106745>] init_dev+0x1b5/0x5b0 08b77a80: [<081074ec>] tty_open+0x14c/0x370 08b77a90: [<080b38bf>] cdev_get+0xf/0x20 08b77aa0: [<080b3a8f>] exact_lock+0xf/0x20 08b77ab0: [<08111130>] kobj_lookup+0xe0/0xf0 08b77ad8: [<081073a0>] tty_open+0x0/0x370 08b77ae0: [<080b398e>] chrdev_open+0x9e/0x120 08b77af0: [<08061757>] buffer_op+0x47/0x80 08b77af4: [<08061590>] do_buffer_op+0x0/0x180 08b77b10: [<080a971a>] dentry_open+0x10a/0x190 08b77b2c: [<080ec008>] empty_dir+0x18/0x330 08b77b30: [<080a9608>] filp_open+0x68/0x70 08b77b74: [<080ec000>] empty_dir+0x10/0x330 08b77b90: [<080a9949>] sys_open+0x49/0x90 08b77bb0: [<08061067>] execute_syscall_skas+0xd7/0xe0 08b77bb4: [<080ec008>] empty_dir+0x18/0x330 08b77bd0: [<0805bc55>] change_signals+0x65/0x90 08b77be4: [<080ec008>] empty_dir+0x18/0x330 08b77c04: [<080ec008>] empty_dir+0x18/0x330 08b77c40: [<08061091>] handle_syscall+0x21/0x40 08b77c50: [<0805fb18>] handle_trap+0x28/0x130 08b77c80: [<08060164>] userspace+0x1c4/0x220 08b77cd0: [<080612f4>] force_flush_all_skas+0x44/0x50 08b77cf0: [<08060bf1>] fork_handler+0xc1/0xe0 sh-3.00# Which is not too surprising because I get an error like that most of the time when I start UML anyway. (I've mentioned it here before, still no idea what it is.) So it's a shell just like the one I had before: Ctrl-C is still being ignored. Right, so exit out of that into the first UML shell, and then type "reset". (The standard reset(1) command.) And I get a hang. The screen clears but I never get my prompt back, and although hitting enter moves the cursor down the screen nothing I type makes any difference (including ctrl-c). Anybody else tried this? Rob |
From: Henrik N. <um...@hn...> - 2005-09-23 18:48:16
|
On Fri, 23 Sep 2005, Rob Landley wrote: > I'm the strange guy using UML via the stdio console, ala: > > ./linux rootfstype=hostfs MEM=48m rw init=/bin/sh LD_ASSUME_KERNEL=2.4.1 > > And it would be very nice if ctrl-c would work with that. I tried commenting > out the "!noctty &&" test in line 1872, but it didn't make any difference. > > Anybody see an obvious way to make /dev/console a controlling TTY? The stdin given by the kernel to init is not a controlling TTY as this would be disasterous (imagine someone sending breaks during the boot sequence, breaking various init tasks or even init itself...), but any init related process (but only one) can claim it as the controlling TTY and will then be given signals. This is not unique to UML but applies to all architectures. There is nothing wrong with using /dev/console instead of a "real" tty. /dev/console is no more than an alias for the first console tty. But you won't get it as a controlling TTY unless explicitly asked for. Regards Henrik |
From: Blaisorblade <bla...@ya...> - 2005-09-23 18:54:40
|
On Friday 23 September 2005 20:47, Henrik Nordstrom wrote: > On Fri, 23 Sep 2005, Rob Landley wrote: > > I'm the strange guy using UML via the stdio console, ala: > > ./linux rootfstype=hostfs MEM=48m rw init=/bin/sh LD_ASSUME_KERNEL=2.4.1 > > And it would be very nice if ctrl-c would work with that. I tried > > commenting out the "!noctty &&" test in line 1872, but it didn't make any > > difference. > > Anybody see an obvious way to make /dev/console a controlling TTY? > The stdin given by the kernel to init is not a controlling TTY as this > would be disasterous (imagine someone sending breaks during the boot > sequence, breaking various init tasks or even init itself...), but any > init related process (but only one) can claim it as the controlling TTY > and will then be given signals. > > This is not unique to UML but applies to all architectures. > There is nothing wrong with using /dev/console instead of a "real" tty. > /dev/console is no more than an alias for the first console tty. Ahhh.. > But you > won't get it as a controlling TTY unless explicitly asked for. How? Anyway, Henrik, thanks for your enlightenment. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Blaisorblade <bla...@ya...> - 2005-09-23 19:10:24
|
On Friday 23 September 2005 20:56, Henrik Nordstrom wrote: > On Fri, 23 Sep 2005, Rob Landley wrote: > >> Anybody see an obvious way to make /dev/console a controlling TTY? > > The user-space process who wants it as a controlling tty needs to run > > ioctl(0, TIOCSCTTY, (void *) 1); > > You should also take care to set up the termios parameters correctly. > > At http://marasystems.com/download/ctty/ you can find a little tool we use > in embedded systems making /dev/console a controlling TTY. We use from > inittab in the main console entries (single and console). > > ls:S:wait:ctty ash > sh:0123456:respawn:ctty console > (console is our console command line program) So in this case he should use init=/sbin/ctty sh, right? > Regards > Henrik -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Henrik N. <um...@hn...> - 2005-09-23 20:31:54
|
On Fri, 23 Sep 2005, Blaisorblade wrote: > So in this case he should use init=/sbin/ctty sh, right? But you can't.. init= takes a single path to the binary to use, no arguments. But it's trivial to modify ctty to autmatically start a shell for you. Regards Henrik |
From: Rob L. <ro...@la...> - 2005-09-24 13:51:42
|
On Friday 23 September 2005 12:50, Blaisorblade wrote: > On Friday 23 September 2005 18:35, Rob Landley wrote: > > I'm the strange guy using UML via the stdio console, ala: > > > > ./linux rootfstype=hostfs MEM=48m rw init=/bin/sh > > Ah, init=/bin/sh, that's why you have /dev/console. Yup. Very useful thing to do with UML, I've found. (That or init=/some/shell/script.sh, although it has the nasty habit of falling back to /sbin/init if that file is not found...) Unfortunately, when you do wrap a shell script, ctrl-c won't get you out. > I feared somebody again using /dev/console in inittab. Nope, trying to wrap a shell script in a UML instance so I can build and link against a libc with more recent kernel headers than the kernel the parent system is running. (Otherwise I get segfaults when the libc tries to do things the parent kernel doesn't support.) P.S. The failure case i reported earlier (where 2.6.11 works but 2.6.13.1 doesn't) involves building the busybox "install" command against uclibc. That seems to be what's failing. I'm still trying to narrow down the reproduction case to something small enough to attach to the list, but it's been a busy week...) > > LD_ASSUME_KERNEL=2.4.1 > > > > And it would be very nice if ctrl-c would work with that. I tried > > commenting out the "!noctty &&" test in line 1872, but it didn't make any > > difference. > > > > Anybody see an obvious way to make /dev/console a controlling TTY? > > Guess that /dev/console is not a TTY, so that it not possible. I mean, > you'd have to patch (uselessly) the very TTY core layer. Well, actually the test on line 1872 of drivers/char/tty_io.c does in fact seem to be trying to determine what should and shouldn't be a tty. It _seems_ like that code is trying to figure out what is and isn't a controlling tty: if (!noctty && current->signal->leader && !current->signal->tty && tty->session == 0) { task_lock(current); current->signal->tty = tty; task_unlock(current); current->signal->tty_old_pgrp = 0; tty->session = current->signal->session; tty->pgrp = process_group(current); } The first test is the one I commented out, and I guess one of the next 3 tests is still blocking it... > Or make Linux use /dev/tty0 instead of /dev/console when starting init - > which is simpler. There is maybe even a console= switch There is indeed a console= switch, but I haven't found a way to get it to do anything useful. (when I use console=/dev/tty0 it immediately exits with no error message. Same for console=4,1. Strangely, console=tty0 boots, but seems to be a NOP.) > What about something like init="kludgy script which calls, say, a mixture > of setsid, <> /dev/tty0, open(1) and such stuff to make sh start? Given enough effort I can workaround the problem instead of fixing it, sure. > Maybe sh doesn't even need that, but login(8) needs setsid. I never > remember the exact combination, however. The necessary magic is in the busybox init.c, but I don't see how it applies here... Rob |
From: Blaisorblade <bla...@ya...> - 2005-09-24 14:16:40
|
On Friday 23 September 2005 21:08, Rob Landley wrote: > On Friday 23 September 2005 12:50, Blaisorblade wrote: > > On Friday 23 September 2005 18:35, Rob Landley wrote: > > > I'm the strange guy using UML via the stdio console, ala: > > > ./linux rootfstype=hostfs MEM=48m rw init=/bin/sh > > Ah, init=/bin/sh, that's why you have /dev/console. > Yup. Very useful thing to do with UML, I've found. (That or > init=/some/shell/script.sh, although it has the nasty habit of falling back > to /sbin/init if that file is not found...) > Unfortunately, when you do wrap a shell script, ctrl-c won't get you out. > > I feared somebody again using /dev/console in inittab. > Nope, trying to wrap a shell script in a UML instance so I can build and > link against a libc with more recent kernel headers than the kernel the > parent system is running. (Otherwise I get segfaults when the libc tries > to do things the parent kernel doesn't support.) > P.S. The failure case i reported earlier (where 2.6.11 works but 2.6.13.1 > doesn't) involves building the busybox "install" command against uclibc. > That seems to be what's failing. I'm still trying to narrow down the > reproduction case to something small enough to attach to the list, but it's > been a busy week...) > > > > LD_ASSUME_KERNEL=2.4.1 > > > > > > And it would be very nice if ctrl-c would work with that. I tried > > > commenting out the "!noctty &&" test in line 1872, but it didn't make > > > any difference. > > > > > > Anybody see an obvious way to make /dev/console a controlling TTY? > > > > Guess that /dev/console is not a TTY, so that it not possible. I mean, > > you'd have to patch (uselessly) the very TTY core layer. > The first test is the one I commented out, and I guess one of the next 3 > tests is still blocking it... > > Or make Linux use /dev/tty0 instead of /dev/console when starting init - > > which is simpler. There is maybe even a console= switch > There is indeed a console= switch, but I haven't found a way to get it to > do anything useful. (when I use console=/dev/tty0 it immediately exits > with no error message. it doesn't expect a /dev/ in front of it. > Same for console=4,1. Strangely, console=tty0 > boots, but seems to be a NOP.) Given what Henrik said about console being a wrapper of tty0, I expect that you could do console=tty1 and have things go there, but /dev/console would still behave like /dev/console (i.e. it doesn't become a controlling terminal unless requested, to avoid Ctrl-C on init scripts). Using Henrik's ctty is the proper solution. > > Maybe sh doesn't even need that, but login(8) needs setsid. I never > > remember the exact combination, however. > The necessary magic is in the busybox init.c, but I don't see how it > applies here... Well, I remember something as "/bin/bash <> /dev/tty8" doesn't work without the magic, and you need to do more or less this. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Henrik N. <um...@hn...> - 2005-09-25 12:50:01
|
On Fri, 23 Sep 2005, Rob Landley wrote: > There is indeed a console= switch, but I haven't found a way to get it to do > anything useful. (when I use console=/dev/tty0 it immediately exits with no > error message. Same for console=4,1. Strangely, console=tty0 boots, but > seems to be a NOP.) See Documentation/serial-console.txt and Documentation/devices.txt for details on how the console= option and /dev/console works. In short console= tells the kernel where to log messages. Can be specified multiple times if you want the kernel to report messages on more than one tty. If none is specified the kernel probes all the available tty drivers in a predefined order, usually tty0 (vt), ttyS0 (first serial port), lp. The first found console driver is then linked to /dev/console for userspace to attach to, and given as stdin/out/err to init. Note: tty0 is a magic vt device linked to the current foreground virtual terminal, not one specific terminal. This should only be used in singleuser mode as it competes with the real ttyX for the same virtual terminal. The ctty program mentioned has only been truly tested from inittab. Does not seem to work proper when used as init= so it's probably missing some process group thing or similar. Did work when executed interactively from a init=/bin/sh shell however. To be honest it skips quite many steps in the terminal initialization compared to how getty etc opens their terminal. Regards Henrik |
From: Rob L. <ro...@la...> - 2005-09-25 15:34:58
|
On Sunday 25 September 2005 07:49, Henrik Nordstrom wrote: > The ctty program mentioned has only been truly tested from inittab. Does > not seem to work proper when used as init= so it's probably missing some > process group thing or similar. Did work when executed interactively from > a init=/bin/sh shell however. I tried it. I did the following: ./linux rootfstype=hostfs rw init=/bin/sh LD_ASSUME_KERNEL=2.4.1 #/path/to/ctty /bin/sh And although it did give me a nested shell invocation, it made no difference that I could see as far as ctrl-c went. > To be honest it skips quite many steps in > the terminal initialization compared to how getty etc opens their > terminal. It's obviously a quick hack or it wouldn't segfault when you ran it with no arguments. I don't hold that against it. The thing is, all the various invocation methods you've mentioned are attempts to give a controlling tty to something _other_ than /dev/console. The various virtual terminals, for instance. I haven't figured out how to get those to attach to fd:0,fd:1 so that I have ctrl-c working on stdio of the UML instance, so getting ctrl-c working on them doesn't help me. (I could just use init.) I can fiddle around and create an initramfs to do all sorts of complicated things if necessary, and probably will, but it would be nice if there was an easy solution... > Regards > Henrik Rob |
From: Blaisorblade <bla...@ya...> - 2005-09-24 14:07:54
|
On Friday 23 September 2005 22:31, Henrik Nordstrom wrote: > On Fri, 23 Sep 2005, Blaisorblade wrote: > > So in this case he should use init=/sbin/ctty sh, right? > > But you can't.. init= takes a single path to the binary to use, no > arguments. init= doesn't take argument, yes, but IIRC unhandled arguments are automatically passed to init, like unhandled assignment are passed in env. vars. Or not? > But it's trivial to modify ctty to autmatically start a shell > for you. Yes, indeed. > Regards > Henrik -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Rob L. <ro...@la...> - 2005-09-24 17:37:53
|
On Saturday 24 September 2005 09:03, Blaisorblade wrote: > On Friday 23 September 2005 22:31, Henrik Nordstrom wrote: > > On Fri, 23 Sep 2005, Blaisorblade wrote: > > > So in this case he should use init=/sbin/ctty sh, right? > > > > But you can't.. init= takes a single path to the binary to use, no > > arguments. > > init= doesn't take argument, yes, but IIRC unhandled arguments are > automatically passed to init, like unhandled assignment are passed in env. > vars. Or not? Unhandled name=value arguments are used to set environment variables, and rather a lot of arguments are intercepted as kernel flags. Even if whatever was left was sent to init, I'd feel a little funny about trusting it. (This is more a job for initramfs.) But the more fundamental problem is that I tried ctty from the pid 1 command shell in the UML instance, and it didn't make any difference I could spot. Rob |
From: Henrik N. <um...@hn...> - 2005-09-24 23:14:43
|
On Sat, 24 Sep 2005, Blaisorblade wrote: > init= doesn't take argument, yes, but IIRC unhandled arguments are > automatically passed to init, like unhandled assignment are passed in env. > vars. Or not? Right. Seems to work just fine even if somewhat confusing... sh init=/bin/ctty or init=/bin/ctty sh is the same thing.. Regards Henrik |
From: Rob L. <ro...@la...> - 2005-09-25 00:10:50
|
On Saturday 24 September 2005 18:14, Henrik Nordstrom wrote: > On Sat, 24 Sep 2005, Blaisorblade wrote: > > init= doesn't take argument, yes, but IIRC unhandled arguments are > > automatically passed to init, like unhandled assignment are passed in > > env. vars. Or not? > > Right. Seems to work just fine even if somewhat confusing... > > sh init=/bin/ctty > or > init=/bin/ctty sh > > is the same thing.. > > Regards > Henrik But does ctty give you a controlling terminal on that sh? I just tried it again (./linux rootfstype=hostfs rw LD_ASSUME_KERNEL=2.4.1 init=/path/to/ctty /bin/sh) and it didn't still give me a controlling terminal. I.E. this isn't a solution for me because in the context I care about, it doesn't work. Rob |