On 06/27/2010 02:34 AM, Denys Vlasenko wrote: > 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. > >
+1 Thanks! :) -- Regards, Christian Ruppert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox