On Sunday 27 June 2010 00:40, Christian Ruppert wrote: > >>>>>>>> I try to setup busybox properly for my initrd although I don't get it > >>>>>>>> working with "job control". > >>>>>>>> I thought that console=... would help (kernel cmdline) but it > >>>>>>>> doesn't. > >>>>>>>> > >>>>>>>> It works so far (at least CTRL+C) if I use openvt -s but that is no > >>>>>>>> solution for me. > >>>>>>>> I use my own /init script which later calls "exec /bin/sh" to enter a > >>>>>>>> rescue shell but CTRL+C etc. isn't working. :( > >>>>>>> > >>>>>>> Does this answer your question? > >>>>>>> > >>>>>>> http://busybox.net/FAQ.html#job_control > >>>>>> > >>>>>> Not really because how can I run the shell in a real console there? > >>>>>> I have no ttySX at all and other console= values doesn't seem to work. > >>>>> > >>>>> So you do not know what is your tty? > >>>> I do.. I'll rephrase it: > >>>> I don't have a serial cable connected or anything else so I can't test > >>>> different console= parameter. > >>> > >>> No one said that you need to. > >>> > >>> http://busybox.net/FAQ.html#job_control says: > >>> > >>> "Your should run your shell on a normal tty such as tty1 or ttyS0 and > >>> everything > >>> will work perfectly". > >>> > >>> It does not say "set your console= kernel parameter to tty1 or ttyS0". > >>> > >>> Please try running "sh </dev/tty1 >/dev/tty1 2>/dev/tty1" > >> > >> Still the same... > >> "sh: can't access tty; job control turned off" > > > > Ok, now try > > > > setsid sh -c 'exec sh </dev/tty1 >/dev/tty1 2>/dev/tty1' > > That works, thanks! :) > One should add it to the FAQ :P
Updated: Why do I keep getting "sh: can't access tty; job control turned off" errors? Why doesn't Control-C work within my shell? Job control will be turned off since your shell can not obtain a controlling terminal. This typically happens when you run your shell on /dev/console. The kernel will not provide a controlling terminal on the /dev/console device. Your should run your shell on a normal tty such as tty1 or ttyS0 and everything will work. Example: you booted into your machine with init=/bin/sh and got "sh: can't access tty" error because sh has its stdio opened to /dev/console. You want to reopen stdio to, say, /dev/tty1 and thus acquire a controlling tty. # Let's try this: exec </dev/tty1 >/dev/tty1 2>&1 # No, doesn't work: even if opening /dev/tty1 gave sh the ctty, # sh wouldn't know it - it checks for ctty just once at startup. # Let's try re-execing sh: exec </dev/tty1 >/dev/tty1 2>&1 exec sh # Got "sh: can't access tty" again. Why? # The reason is somewhat obscure: kernel starts process with PID=1 # (in this case, shell) with SID=0 and PGID=0, not with SID=1 and PGID=1 # as you'd expect. IOW: our sh is not a session leader, and therefore # cannot acquire ctty by opening /dev/tty1 (or any other tty). # Let's try making us a session leader: exec setsid sh exec </dev/tty1 >/dev/tty1 2>&1 exec sh # Yes, this worked! # This can be combined into one command, # but need to be careful and perform these operations # in the correct order: # 1. make ourself session leader, # 2. open /dev/tty1 and thus acquire a ctty, # 3. re-execute the shell, allowing it to notice that it has ctty: exec setsid sh -c 'exec sh </dev/tty1 >/dev/tty1 2>&1' If you REALLY want your shell to run on /dev/console, then you can hack your kernel (if you are into that sortof thing) by changing drivers/char/tty_io.c to change the lines where it sets "noctty = 1;" to instead set it to "0". I recommend you instead run your shell on a real console. -- vda _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox